Prevent modules from leaking testEnvironment to parent modules

[chriskrycho]

Today, modules' testEnvironment is leaked to any parent module. This makes it impossible for callers to rely on garbage collection of items attached to the module context, which in turn makes it impossible to test against memory leaks from the code under test. Accordingly, this PR makes two changes:

• [x] Add failing tests which assert that the this of an inner module is not reference-equal to the test of its parent module.
• [ ] Update module environment handling not to leak, matching the behavior of tests.

[linux-foundation-easycla[bot]]

• :x: - login: @chriskrycho / name: Chris Krycho . The commit (2f60388e7da62565548a6921d5218e47cb30f339) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[chriskrycho]

This was a mistaken understanding of the intent here; sorry for the noise!

[Krinkle]

@chriskrycho No problem! Two related thoughts come to mind:

QUnit also supports the, sometimes perceived as more modern, way of sharing values between test cases and between different parent modules, through lexical scope rather than a "this" object.

The "nested" module scope approach (https://api.qunitjs.com/QUnit/module/) is very similar in terms inherence and shadowing, so it's not exactly attractive for being different or better. But, in my experience JS developers tend to be less surprised by how values are shared through lexical scopes, and e.g. less surprised by a module that has let foo; in the parent scope, and then beforeEach() setting foo = …, compared to only a beforeEach that assignsthis.foo = …; and having to guess whether and how that might be inherited or copied etc.

I believe for Ember, some properties are set automatically through automation, so that might be a reason to stick with the "this" object. No pressure of any kind. Both are supported and work perfectly fine.

There's a proposal on the roadmap to apply more inheritence to the "this" object during before() callbacks QUnit 3. If you have ny thoughts on that, I'd love to hear it, over at https://github.com/qunitjs/qunit/issues/1328.