Is it possible to test for reentrancy within remix IDE? if so, could someone provide an example of how-to.
Solidity and Remix – Testing for Reentrancy Attacks
contract-debuggingcontract-designcontract-developmentremixsolidity
Related Solutions
There should be no problem to test your contracts in Remix, but I think you will loose features offered by Truffle, like automatic clean-room environment preparation. To answer you question about DeployableContract.sol:
There will be no truffle in the picture at all, so 'DeployableContract.sol' is irrelevant. You will have to manage instantiation of your contracts manually, with
contract TestTodoList {
TodoList todolist = new TodoList();
...
if you want new instance of TodoList for each test (probably the case) or
contract TestTodoList {
TodoList todolist;
function TodoList(address addr) public {
todoList = TodoList(addr);
}
...
if you are running test against some existing instance.
I have tried your code in Remix.
First, it complains about library deployment error. If you copy Assert.sol from github into browser (and change import import "./Assert.sol"
) you can work around this problem.
Next, it complains about a constructor having to be payable. I am not quite sure what this error means exactly in this context. Maybe others can elaborate. Hope this helps.
You can add breakpoints in your code to use when debugging your smart contract. You can do this by clicking on the line number of where you want to set your breakpoint.
In this example, I set my breakpoint at line 24
when the constructor is called.
There are several ways to debug your contract. You can click on the Debugger tab and insert a block number or transaction hash and press the play button to go through the steps. But what I like to do is to run a method I want to test and then press the Debug
button in the console. That will load up the correct transaction hash.
In this example, I put a breakpoint when the constructor is called, initialized my contract in the Run tab, and then pressed the Debug
button in the console.
You can see that the debugger stopped inside my constructor. You can use the buttons under the slider to step in, step back, step over, step out, etc. The buttons under that allow you to navigate through your breakpoints.
The transaction slider allows you to quickly maneuver around code as it goes through that specific transaction.
One thing that I like to do when a transaction fails for whatever reason is move the slider to the very end. This will most likely be where your code stopped and could be the cause of the failure.
You'll also notice as you go through the transaction that you'll be able to see the values of state variables and local variables, which will be helpful when you're debugging your code.
Best Answer
Here is a classic example of a reentrancy attack. You can see how it works by looking at how the Attacker contract's attack function interacts with the Victim's withdraw function, the functions used by the Victim to send Ether, and how the Attacker's fallback function repeatedly calls the Victim's withdraw function.
You can test this in Remix by deploying the Victim contract and then the Attacker contract with the Victim's address as input.
After calling the attack function, you can verify the repeating withdraws by the events logged.
You can use a similar method as the attack function to test other contracts who have a similar pattern as the Victim's withdraw function.