Ganache startup time can trigger mocha timeout

[frangio]

The first test in a mocha test suite can time out when it interacts with test-env's ganache node, since it will have to wait until the node has fully spun up.

See this thread in the forum for more info: https://forum.openzeppelin.com/t/openzeppelin-test-environment-timeout-exceeding-2000ms/2406/14

Obviously the best way to fix this would be to reduce the startup time and this is something we would appreciate anyway. Other measures we can take is detecting that mocha is running and automatically increasing the timeout for the first test that hits the node, but I'm not sure how feasible this is. Lastly for now we can document this as something that can come up.

[abcoathup]

Timeout occurring when using ganache-fork:
https://forum.openzeppelin.com/t/tests-are-failing-using-ganache-fork-with-openzeppelin-test-environment-with-a-timeout-error/2704

[frangio]

An idea. The problem is that the first transaction sent in the first test will wait until the node has spun up. We can work around this by allowing the users to wait for the node to be ready outside of that first test. For example if the user is running into Mocha timeouts, we can suggest to add the following:

before(async function () {
  this.timeout(none); // however this is done
  await provider.ready;
});

(This provider.ready property is somewhat related to #36.)

[ylv-io]

@frangio that brings us back to the whole design discussion. We import test-env in a sync way so users can access accounts and other properties instantly. But if we have to await before running tests then it makes sense to await for accounts as well await getAccounts. Advantage of this approach would be extracting accounts from Ethereum node rather passing them. It could enable us to support other nodes beyond Ganace. WDYT?

[frangio]

It's not only about it being instant, it's about the accounts being available in the top level context, without having to do dirty tricks with let accounts; and assigning it in a before block. I think we should keep the current design in that regard, and the ability to wait for readiness is only optional in case users run into the timeout problem.

[frangio]

My proposal is basically a workaround though. It would be nicer to do something more automatic, if we can figure it out.