Ray Cohen

What about `(hooks, test, module) => ` which maintains the meaning of "hooks". Invocations like `test.module()` and `q.beforeEach()` make me feel like clarity is being lost

Am I reading your suggestion to mean that the following, which currently works, would not be valid in QUnit 3.0? ``` QUnit.module('example', function (hooks) { this.abc = 123; hooks.beforeEach(function ()...

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...

when using nested modules to override variables from a parent module, using lexical scope doesn't always have the desired behavior. Many tests we write have the pattern where a top-level...

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...

:thumbsup:

Looks like sinon does not currently allow the `sinon.expose(target)` target to receive **successful** assertion information, only failures: https://github.com/sinonjs/sinon/blob/6c4753ef243880f5cdf1ea9c88b569780f9dc013/lib/sinon/assert.js#L94-L104 So QUnit will not know when things pass, only when they fail.

@lukemelia I am fine handing over maintenance to movable. That said I have a few thoughts- First, I think it would be worth addressing the yarn v2 compatibility issue _without_...

this looks pretty good. do you think you could add a test for it?

Thanks. We run the tests against multiple versions of ember and they've been failing for a while on newer versions. If you do get around to adding a test, I'll...