Support resetting accounts after each test

Issue

Good tests should always start from a clean slate, and not depend on the results of previous tests. Currently the test network is reset before each Contract suite, and it seems there is no way to reset programmatically in tests or with some configuration.

Steps to Reproduce

• Create a test file with a Contract block
• Add multiple It(...) tests which assume a blank slate and make changes to accounts ether balances (etc)
• Observe that all but the first test will fail, as the state is not blank anymore

Expected Behavior

A setting or globally available function would allow for resetting of accounts, when the developer needs to start from a blank slate more regularly

Potential solution

I’ve had a read of how truffle works, and played with a solution like the following:

https://github.com/trufflesuite/truffle-core/blob/develop/lib/test.js#L218

	  global.resetState = function() {
		runner.resetState(function() { console.log("State Reset By Test")  })
	  }
          // OR
	  global.resetState = function() {
		runner.initialize(function(err) { 
			err 
			? console.log('Failed Resetting State') 
			: console.log("State Reset By Test")  }
		)
	  }

Unfortunately this doesn’t seem to actually work, but providing a working reset method or helpers class in the global scope would open up a lot of doors for developers.

[cgewecke]

@Nick-Lucas Thanks, this makes sense and is nicely expressed. In practice what people often do is manage their own contract instantiation in a beforeEach block. Example:

contract('SimpleContract', function(accounts){
   let simpleContract;

   beforeEach(async function(){
     simpleContract = await SimpleContract.new();
   });

Are there use cases where the strategy above isn’t adequate?

[gnidan]

Hey @ejwessel, nope, no progress yet on this specifically. Cursèd Stalebot is now disabled so we won’t risk this issue getting lost to history again.

As for position on this: I’d say no, Tim probably feels the same way as he used to, and I agree with him. But! Definitely we could support this as a configuration option.

Not sure about team bandwidth to work on this in the near-term, so I’m going to slap the “help wanted” label on this issue. If anyone wants to work on a PR, I’d love to see the addition of configuration options to customize this revert behavior. Might be worth syncing up before starting work, though. If anyone’s interested, let me know!