Add option to run tests in separate parser instances

[eborden]

I am testing a bevy of async code that relies on a global configuration. I know global state is evil, but this is state that would not change in production, but must change in testing to account for various configurations. Since the resulting code is async it squashes the global config down to the last configuration made. I'm currently getting around this issue with the following bash script:

#/bind/bash
find -name "*.spec.js" | xargs -l1 jasmine-node

There are other ways to get around this, but being able to run each spec in its own parser instance would be a nice option.

[tebriel]

I can't think of any other ways to get around it, if you'd like to take a stab at writing the code I'd be happy to review it for merge...

[davidposin]

A few ideas:

1. You can try using afterEach and beforeEach to reinstate the configuration each time.
2. Load the configuration into the test itself and attach it to process
3. Put code into the script files to run only in certain environments, then use the uglify's mangle option to remove those blocks from production.
4. Crazy option: Have a master process launch each spec into a seperate child thread and close the master once all children report done. <-- Not recommended but sounds fun

I would need a little more detail to advise beyond the above

[tebriel]

:+1: the first one is what we do at my job.

[eborden]

@Lastalas I had considered after/beforeEach, but it just seems like a hulking mass of cruft to introduce. The others I'm not quite sure about, attaching to process seems like an interesting idea. The specs live here if you want to take a look: https://github.com/eborden/promiscuous/tree/master/spec

[davidposin]

if you use the --config option on the command line, you can add variables to the sandbox that are accessible via process.env