Hi @Jshanks21
Sorry you had this issue.
Are you able to share your test and contract so that I can try to reproduce?
2 Likes
No worries @abcoathup. Sorry for not responding sooner. I just pushed my changes to GitHub. This link should take you directly to the test file. I left a comment next to the line canceling out the error. It’s on line 19. You’ll want to comment this out or remove it to reproduce the error.
Thanks for taking a look!
2 Likes
Hi @Jshanks21,
I wasn’t able to reproduce on my system:
node v10.19.0
npm 6.14.1
operating system: WSL on Windows 10
Would you mind sharing what your configuration is?
I have line 19 commented
//this.timeout(0); // Prevents 2000ms timeout error
I am not reproducing the error:
$ npm run test
> crowdsale@1.0.0 test /c/Users/andre/Documents/projects/forum/crowdsale
> npx mocha --exit --recursive test
MyCrowdsale
crowdsale
âś“ tracks the token name (54ms)
âś“ tracks the rate
âś“ tracks the wallet
âś“ tracks the token
minted crowdsale
âś“ mints tokens after purchase (155ms)
accepting payments
âś“ accept payments (199ms)
6 passing (3s)
2 Likes
No problem @abcoathup:
node v10.16.3
npm 6.13.1
operating system: Windows 10
Commenting line 19
Here’s the error I get:
But it passes when I stop commenting line 19:
1 Like
Hi @Jshanks21,
The default timeout in mocha is 2000ms.
The first run of beforeEach I get a duration (ms) ~1200
The beforeEach is deploying a token and a smart contract so takes a little bit of time.
I reproduced by adding a sleep await new Promise(r => setTimeout(r, 2000));
As you have done, you can disable timeouts using this.timeout(0) or you could increase the timeout.
https://mochajs.org/#suite-level
As an aside, I use Windows Subsystem for Linux, and I would recommend using WSL (I haven't tried WSL2 yet). So much of the ecosystem is unix based, so I run into far fewer issues using WSL.
3 Likes
Thank you @abcoathup! I assumed it had something to do with my tests exceeding the built-in time limit. I also just assumed it was because my computer is too slow 
.
I was actually just reading about a different issue in this thread where you recommended WSL too. I’ll definitely check it out.
I wanted to contribute to the OpenZeppelin repo, so I was going through some of the name changes and cleanup issues in the upcoming release. But I encountered the “file import callback not supported” when trying to compile in order to run tests. Would using WSL be the best solution for this?
1 Like
Hi @Jshanks21,
Great to hear that you want to contribute to OpenZeppelin Contracts. I would encourage using WSL (I am yet to try WSL2), as you face far fewer issues. The Microsoft documentation recommends using Windows Subsystem for Linux (for production): https://docs.microsoft.com/en-us/windows/nodejs/setup-on-windows#use-windows-subsystem-for-linux-for-production.
1 Like
Good to know. I’ll go through that and see if it helps with the issue. Seems like a good idea aside from the immediate issue I’m encountering though.
1 Like
Let me know how you get on. You could always write up the process to get a Windows development environment setup 
1 Like
I should be able to do that. I’ll definitely be adding it to my My Coding Journey when I do it anyway. I’ll just try to be more conscious of tracking each step.
1 Like
Hi @Jshanks21, I have a small follow up question to help us understand the underlying issue better. Was the timeout happening consistently or only sometimes?
1 Like
Hi @frangio, the timeout was consistent. Anytime I ran the tests without this.timeout(0); at the beginning of the tests, I received the error message above.
I appreciate any additional feedback on this.
P.S. I have not tried using WSL yet to see if it fixes the issue. Plan to try it within the next couple days.
2 Likes
The first run of beforeEach I got a duration (ms) ~1200 so on a different setup (e.g. native Windows) I could see this being over the default timeout of 2000ms.
That’s interesting. Do you know which statements took longer? I tried to run this on my own computer but for some reason it doesn’t work.
1 Like
@frangio
The first run in the beforeEach of the test deploying the token takes the longest:
// MyCrowdsale.test.js
...
beforeEach(async function () {
// Token config
this.name = "OZToken";
this.symbol = "OZT";
this.decimals = 18;
start = Date.now();
// Deploy Token
this.token = await OZToken.new(
this.name,
this.symbol,
this.decimals
);
end = Date.now();
...
Test run
$ npm test
> crowdsale@1.0.0 test /c/Users/andre/Documents/projects/forum/crowdsale
> npx mocha --exit --recursive test
MyCrowdsale
crowdsale
Deploy token: 1043ms
Deploy crowdsale: 90ms
Add minter: 77ms
âś“ tracks the token name (55ms)
Deploy token: 141ms
Deploy crowdsale: 88ms
Add minter: 57ms
âś“ tracks the rate
Deploy token: 116ms
Deploy crowdsale: 76ms
Add minter: 56ms
âś“ tracks the wallet
Deploy token: 111ms
Deploy crowdsale: 78ms
Add minter: 55ms
âś“ tracks the token
minted crowdsale
Deploy token: 114ms
Deploy crowdsale: 80ms
Add minter: 58ms
âś“ mints tokens after purchase (208ms)
accepting payments
Deploy token: 109ms
Deploy crowdsale: 76ms
Add minter: 58ms
âś“ accept payments (230ms)
6 passing (3s)
1 Like
Oh thank you this is super interesting. The delay is then caused by the startup time of the ganache node that Test Environment spins up.
2 Likes