You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 7, 2018. It is now read-only.
I've identified why it's only running once. buster-test-cli/lib/runners/node.js has a descriptiveRequire function that require files. As expected, require'ing a file loads it into node.js' cache so every call to the same module would return the same module without executing the code in that module more than once.
Is this testing to be expected? It looks like it should actually be run for every time it's defined in a group. An example of why this should be the case is when I have an extension that has different options for each group.
I don't know how the browser env would respond to this though.
Blowing away node require cache is possible but I think it'll be hard to control. Do we blow away all the cache for every module required by the one test file? If require('buster') occurs in the test, then it could cause some problems, right?
What if we mapped out test file paths with testCase objects to reuse the testCase objects?
We'll blow the entire require cache between each configuration group. I don't think this will cause any problems, and it will maintain the expected behavior of running each individual test configuration in isolation.
Hey guys,
I don't know if this is expected or an issue. Tests clearly defined in multiple groups in the config file are only run once.
Something like:
I've identified why it's only running once. buster-test-cli/lib/runners/node.js has a descriptiveRequire function that require files. As expected, require'ing a file loads it into node.js' cache so every call to the same module would return the same module without executing the code in that module more than once.
Is this testing to be expected? It looks like it should actually be run for every time it's defined in a group. An example of why this should be the case is when I have an extension that has different options for each group.
@cjohansen Said this was a bug.
The text was updated successfully, but these errors were encountered: