Test teardown sequencing issue with the setupEngine helper.

[brettburley]

Since incorporating the fix in #875 to properly clean up engine instances, I've run into another issue with some of our engines. The symptoms are tests that fail with one of these two failures:

Error: Assertion Failed: calling set on destroyed object

Error: Can not call .lookup after the owner has been destroyed

These happen when the component under test has a willDestroy or similar hook that attempts to use the engine (e.g. service lookup) or set an attribute on another engine-owned object.

It appears that this is because of how the rendering context is set up using the setupEngine helper, which renders the component under test as an outlet in a view that is owned by the dummy app:
https://github.com/emberjs/ember-test-helpers/blob/master/addon/addon-test-support/%40ember/test-helpers/setup-rendering-context.ts#L260

As a result, with the patch from #876, the order in which the objects are destroyed at the end of the test from the destroy(context) callback in teardownContext is:

1. Destroy engine & it's container.
2. Destroy application & it's container (which is rendering the test case).

As a result, even though the component being tested isn't destroyed (since it's rendering is managed by the parent application), the engine has already been destroyed, so the component can't do anything requiring the engine container, e.g. looking up services.

I think the right sequence of teardown when an engine is in use would be:

1. Destroy the testing view (i.e. the component under test).
2. Destroy the engine.
3. Destroy the application.

I am able to simulate this by invoking clearRender() in an after hook in my tests, and this does in fact resolve the issue by first un-rendering the component before the engine is destroyed via teardownContext.

[SergeAstapov]

Thank you for the detailed explanation @brettburley!

Before reading last sentence, was thinking about using clearRender(), so appears we both think in the same direction.

[brettburley]

Ha! I was considering introducing the clearRender() call to the setupRenderingTest helper in ember-qunit as an afterEach hook. However, it seems to trigger failures in many of our test suites that have blur handlers on inputs and end the test with a focused input... Chrome has a long-time bug where the blur event is incorrectly fired on DOM removal: https://issues.chromium.org/issues/41484175, and that triggers the tracked property assertion failure as reported in emberjs/ember.js#19010.

It seems like clearRender() removes the DOM before destroying the component instance. When the view is destroyed through the teardownContext destroy chain, destroy is invoked first on the component which removes the event handlers before the DOM is removed.