Separate module options from test environment

Related:

• https://github.com/jquery/qunit/issues/894#issuecomment-158127790
• https://github.com/jquery/qunit/pull/919/files#r51184320
• https://github.com/jquery/qunit/pull/800#issuecomment-139293379

Note that there are two ways to set before/after hooks (which are currently the only module options): as properties on an options object, and as methods on the argument passed to a callback. Exposing environment procedurally is easy (e.g., a writable environment property on the callback argument), but the declarative side makes backcompat tough. I’m not particularly thrilled with the thought of adding a fourth parameter, though… we could instead look for an environment property on the second argument, using it exclusively when present (technically backwards incompatible, but on the same scale as #919) and otherwise generating warnings whenever there’s any non-before non-after property. All of which, of course, is assuming that keeping the declarative/procedural duality is valuable, about which I’m not fully persuaded but am inclined to keep for now (in part since the procedural interface is so new).

For example, all of these would generate the same environment for their tests:

QUnit.module(name, {
    beforeEach: function() {…},
    environment: { preserved: true },  // new
    ignored: true
});

// Define tests
…

QUnit.module(name, function( hooks ) {
    hooks.environment = { preserved: true };  // new
    hooks.beforeEach(function() {…});

    // Define tests
    …
});

QUnit.module(name, {
    beforeEach: function() {…},
    // For compat with current QUnit (if no environment is defined).
    preserved: true
});

// Define tests
…

But the last would issue warnings about deprecated options/environment mixing.

I’m not in love with this, but it’s the best I’ve got. Other suggestions welcome.

[raycohen]

Thanks @Krinkle that is reassuring. I have found that lexical scoping can run into issues with nested modules depending on where you reassign, while using the this test environment is less easily be impacted by what happens in sibling modules. I might open another issue to discuss this since it’s not really on topic with this thread.

[raycohen]

Ok, I see how hooks.before is accomplishing the same thing. I didn’t have a good understanding of when before ran in nested modules.

One other concern I had with the lexical version is the possibility for “leaks” - i.e. that inserting/deleting/re-ordering nested modules that run before another nested module that does not itself set a lexical variable could impact it. Example: http://jsfiddle.net/v94pze5k/ - granted the developer will see this error at dev time (or via CI) but understanding why a leaky breakage like this happened in a large test file can be a lot of work.

As for the options object, we don’t use that form, so I have no concerns with deprecating that behavior.