Proposal: switching to template-driven component integration tests

[ef4]

Now that we have {integration: true } capability in TestModule, what do people think about merging the functionality from my new TestModuleForIntegration directly into TestModuleForComponent when integration: true?

This would let us get rid of the separate TestModuleForIntegration name entirely, which I agree is not a great name.

To keep the API understandable, I would suggest that component unit tests keep their existing API but component integration tests would be expected to move to the new template-driven API, with deprecation warnings on the old way.

[dgeb]

I think that a template-driven integration test that's not exclusive to a particular component has its place. This provides a way to test integration of multiple components and/or views outside of the context of an application.

[dgeb]

I suppose I'm proposing that TestModuleForIntegration become TestModuleForTemplate (or something similar) and provide a general sandbox for testing an ad-hoc template.

This sandbox could be an an integration test by default, but have the option of having an isolated container as well.

In this way, the unit vs. integration split remains defined simply by its isolation.

[ef4]

That sounds good. I still think we need a better name -- moduleForTemplate isn't quite right either, because the module doesn't exist to test any particular template. That's more of an implementation detail of the tests themselves.

Maybe we can solve that by dropping the moduleFor naming pattern, which works for particular subjects moduleFor('my-subject') and not so well for this other generic pattern which doesn't require a single subject.

What about templateTestModule?

[dgeb]

templateTestModule is an improvement. And I'd be glad to move away from the stilted moduleFor naming pattern altogether. Luckily, it's easy to change as it's encapsulated by ember-mocha and ember-qunit.

[ef4]

I'm thinking ahead to what we name it in those too. That's what motivated this issue, because I was about to submit PRs to those projects to expose this new thing.

[dgeb]

Indeed - that's the more important naming question. Hmmmm....

[ef4]

After much thought and discussion, I propose this solution:

1. Instead of making a new kind of test-module, we fold this new capability into test-module-for-component.
2. test-module-for-component changes to using integration: true by default, and the presence of an explicit needs option switches it back into unit test mode. We could also offer unit: true and/or integration:false if we want clearer synonyms.
3. In integration mode, component tests use the style that's currently present in test-module-for-integration. The existing style (render() with no template, subject(), etc) throws deprecation errors. People can upgrade gracefully by just ensuring their existing tests have a needs option (or integration:false or unit:true, depending on which of those we decide to support), which will trigger the existing unit test behavior.
4. We will want to change the blueprint generators in ember-qunit and ember-mocha to be able to generate both component integration tests (the default) and component unit tests. They would go into different paths (tests/integration/components/foo vs tests/unit/components/foo) and have slightly different boilerplate (the presence or absence of needs).

[eccegordo]

This is fortuitous! I have been struggling a lot with trying to setup component tests that are sensible.

When services, models and other things that ultimately a component depends upon to work, it is a real bear to setup.

How about something like

sandboxForComponent(app, component, dependencies)

The idea here is that your "sandbox" represents a very custom micro app that has everything stubbed and ready for use for testing a component.

app =
would be the sandbox itself with a real-ish application container and registry. One could in theory pass different or multiple app sandboxes into different test files.

component =
would be the explicit component under test

dependencies =
whatever you might subsume under needs, e.g. models, controllers, views, other components, etc.

It would be nice to be able to set these up as part of test configuration or else inline in a specific component test.

[rwjblue]

Closing as @ef4's last proposal has landed and is released.