Mocha seems to reuse required modules in multiple files. Test fail if some states were modified in previous proccessed files.

[Vikas]

Hello

Mocha running with multiple files seems not to cleanup after one file is done. Required modules are not reinitialised, but reused.

If I have fixtures and modify them then it seems that the fixtures are keeping new state for tests in next file. I expected mocha would reload required files, so fixtures for example are in initial state, since I'm requiring them again in the next test/file.

Thanks

Vikas

[Wil Moore]

If I have fixtures and modify them then it seems that the fixtures are keeping new state for tests in next file. I expected mocha would reload required files, so fixtures for example are in initial state, since I'm requiring them again in the next test/file.

If you copy the fixture data in the `beforeEach`, all is well.

[Vikas]

On Saturday, November 17, 2012 7:22:15 AM UTC+1, Wil Moore wrote:

If I have fixtures and modify them then it seems that the fixtures are keeping new state for tests in next file. I expected mocha would reload required files, so fixtures for example are in initial state, since I'm requiring them again in the next test/file.

 

If you copy the fixture data in the `beforeEach`, all is well.

Is this a question?

My solution for the fixture was like this

getFixtures = function () {

  fixtureHash = {

    "whitelist": [1]

  }

  return fixtureHash;

}

 

now every time in need the fixture I simply recreate the dataset I need. 

But that doesn't work for my app. It won't recreate it somehow keeps part of the previous state or doesn't emit Events.

So the other issue is: for example, when calling init function of the app in 'before' or 'beforeEach' it will run the init, but events emitted are not received inside the app or in mocha when second test is running.

[Domenic Denicola]

It sounds like there’s some misunderstanding of more fundamental issues here. In particular, Node.js’s require never executes a file more than once. Given that, why would you expect Mocha to do so? Do you expect it to spin up a separate Node.js process for each test file?

[Vikas]

On Monday, November 19, 2012 2:43:13 PM UTC+1, Domenic Denicola wrote:

It sounds like there’s some misunderstanding of more fundamental issues here. In particular, Node.js’s require never executes a file more than once.

I'm pretty sure that counts also for many other platforms as well.

 

Given that, why would you expect Mocha to do so? Do you expect it to spin up a separate Node.js process for each test file?

Yes I expected to have a new process or something, which is not influenced by previous tests. I expect mocha to do so, because that is the only way to have an isolated test and it wouldn't matter which test runs first.

The only solution I see is a batch or something like that, which calls tests I want to separate. Otherwise dig into mocha and see if these problem can be solved.

[Domenic Denicola]

From: moc...@googlegroups.com [moc...@googlegroups.com] on behalf of Vikas [vikas....@gmail.com]
Sent: Monday, November 19, 2012 11:58

>> Given that, why would you expect Mocha to do so? Do you expect it to spin up a separate Node.js process for each test file?

> Yes I expected to have a new process or something, which is not influenced by previous tests. I expect mocha to do so, because that is the only way to have an isolated test and it wouldn't matter which test runs first.

That's not the only way: the other way is to actually write your tests in an isolated fashion, as you are advised to by most canonical sources on unit testing. Indeed, such state-resetting is the entire purpose of things like `afterEach`.

Having used unit testing frameworks in both C# and JavaScript, I have never seen one that spins up a separate process per test file (or, as you seem to be suggesting, per test). The overhead involved would probably destroy the speed of your test runs!

That said, maybe in Ruby or Python communities such practices are common, and they've found a way around the overhead. I have no experience with them.

[Tj]

Yeah if you're relying on process level state you're doing fixtures and/or libs wrong

Sent from my iPhone

[Wil Moore III]

Yes I expected to have a new process or something, which is not influenced by previous tests. I expect mocha to do so, because that is the only way to have an isolated test and it wouldn't matter which test runs first.

There are some testing frameworks that sort of hand-hold you through this (see phpUnit's processIsolation: http://www.phpunit.de/manual/3.7/en/appendixes.configuration.html); however, this doesn't come without caveats. Just do a google search on "+phpunit +processIsolation" and see how unpredictable that can be, not to mention, slow. This is also why many PHP frameworks maintain their own extensions to PHPUnit so they can reset global state (bad magic) and such. This just masks the underlying problem of code not being written with isolation in mind.

The only solution I see is a batch or something like that, which calls tests I want to separate. Otherwise dig into mocha and see if these problem can be solved.

Actually, just be aware that handing over an object provides a reference (not a copy). If you mean to provide a copy, make a copy, then provide the copy. In other words, modify your `getFixtures` helper to make and return a copy of `fixtureHash`.