Make QUnit.config.beforeEach/afterEach functions rather than setters

[JamesMGreene]

As I discussed with the rest of the QUnit core team in Chicago, I think that QUnit.config.{beforeEach|afterEach} should be changed to be functions rather than setters.

This is beneficial in the following ways:

1. Allows consumers to easily supply more than one beforeEach/afterEach callback.
2. Allow plugins such as custom assertions that currently have to use hacky hooks via the QUnit.testStart/QUnit.testDone logging callbacks to achieve global beforeEach/afterEach behavior to get a proper extension point with access to the correct Test and Assert contexts rather than needing to rely on QUnit.config.current. Clear evidence of this can be seen in the JamesMGreene/qunit-assert-step @ qunit-assert-step.js#L21-L26.
3. Will be required for API consistency-sake anyway [in v2.x] if my forthcoming PR proposal for Issue Allow nested suites (modules) #543 (nested suites) is accepted.

[JamesMGreene]

P.S. I still also recommend that we move them to QUnit.beforeEach/QUnit.afterEach as well but that isn't a requirement.

[JamesMGreene]

@jzaefferer @Krinkle @leobalter @scottgonzalez @gibson042 et al: Discussion needed here.

[jzaefferer]

1. Allows consumers to easily supply more than one beforeEach/afterEach callback

The motivation for having a setter was to force global setup/teardown code into a single location.

1. [qunit-assert-step]

That's an interesting example, though it reminds me of the arguments for API changes to accomodate qunit-composite. I would like to find solutions for these, but I don't think they should have a high priority over general API usage.

In this particular case, a expectSteps(5) (or hijacking assert.expect) might avoid the issue.

1. [nested suites]

I still don't find the given examples convincing. But then I've never used a test framework with nesting myself. The one time I helped debugging something in a nested testsuite involved Jasmine and CoffeeScript and was more an issue of implicit scoping in CoffeeScript...

[leobalter]

The motivation for having a setter was to force global setup/teardown code into a single location.

And I agree to keep it as it is for this reason.

Nested suites can totally replace the need to have it with a different syntax.

[JamesMGreene]

[qunit-assert-step]

That's an interesting example, though it reminds me of the arguments for API changes to accomodate qunit-composite. I would like to find solutions for these, but I don't think they should have a high priority over general API usage.

I think they're different arguments. The qunit-composite arguments were more of a nice-to-have/strawman upgrade, whereas the qunit-assert-step one is really a case of a custom assertion being forced to "do things wrong".

However, I have since thought of at least one other workaround that actually feels more correct to me anyway: checking for this.test.steps === undefined and setting it to 0 during the first time assert.step is called in each test. Generally speaking, the inclusion of a custom assertion plugin shouldn't really be forcibly changing your test metadata unless it is actually also used within a test.

[JamesMGreene]

@leobalter: Can you clarify this comment a bit?

Nested suites can totally replace the need to have it with a different syntax.

I think it means that you're acknowledging that the future/potential nested suites feature may need to change this syntax/decision or add an additional mechanism.

If that's at least acknowledged, I'm OK with closing this for now, though I can guarantee that nested suites will require just such a mechanism. 😕

[leobalter]

IMO, with nested suites it won't be necessary to have the global before/afterEach hooks, so changing anything on them (global hooks) won't affect nested which seems to be the long and best sollution.

The global hooks are interesting while we don't have the nested hooks implemented.

[JamesMGreene]

Right, I was just hoping to kill 2 birds with 1 stone by consolidating the associated beforeEach/afterEach APIs now instead of introducing another set of them (or consolidating them) later.

The way users choose to write their tests (linear modules vs. nested suites) would determine if the handlers they configure would operate on the global level or within suite contexts.

[jzaefferer]

So can we close this or not?

[JamesMGreene]

I recommend reviewing the new PR #670 first as it leverages this concept.

[jzaefferer]

I did just did. That's definitely helpful, but I still don't think we can have that block 1.16 / 2.0. In that regard, turning around again, I'd rather not ship the global hooks now (remove them in master), instead of having to deprecate them soonish.

I suspect that the effort of removing them and bringing them back later is rather small, since we can keep the infrastructure changes we made.

[jzaefferer]

@JamesMGreene @leobalter @Krinkle what do you think?

[JamesMGreene]

I would recommend one of the following:

1. We compromise and change the global hooks to functions but still leave them on QUnit.config instead of QUnit.
2. We leave it as-is, don't document it, and mark it in the code as "EXPERIMENTAL". This allows folks like Ember to still leverage the feature now while acknowledging that it may change in the near future.

[Krinkle]

They should either be properties in config for a single callback, or functions on QUnit (essentially becoming an item in an array of event handlers). Pick one :)

[jzaefferer]

We discussed this again during the meeting. Still have no consensus on the API. Will drop it for now to revisit it along with nested suites later.