Add moduleForAcceptance

[captain-enjoyable]

Problem

Currently the behavior necessary for starting and tearing down Ember apps in tests is located in blueprints. Blueprints expose the user to complexity and create extra boilerplate.

Solution

Create a TestModuleForAcceptance helper. This:

1. avoids the use of blueprints
2. gives the ember team a natural way to pass testing improvements down to users
3. prevents the user from accessing the testApp directly in an acceptance test
4. brings hooks for writing tests to a single location. This improves documentation and creates a stronger separation of concerns between blueprints and tests

Design

First we pulled out a AbstractTestModule. This is a place to put shared behavior between TestModule and TestModuleForAcceptance. It also helps crystalize what needs to be implemented in order to be a 'TestModule'. Next, we implemented a TestModuleForAcceptance.

TestModuleForAcceptance does several things. It sets up and tears down a testApp. It provides four temporal hooks, beforeSetup/afterTeardown, which allow a user of the module to do things before and after the test app is created, and setup/teardown which both execute while the app is running.

TestModuleForAcceptance provides options for the user of the module to customize the test app. The Application option which allows you to define what the test app will be, and a config where you can specify things like the rootElement.

[mmun]

Hmm, not sure what's up with the test error. Passes fine locally.

[captain-enjoyable]

Added explanation to PR message

[mmun]

@dgeb, @rwjblue: Do you have any feedback for this PR?

[dgeb]

I'm 👍 on moving this functionality to a test module in ember-test-modules and out of the blueprint.

The changes look pretty solid. I'm not crazy about the name AbstractTestModule, but understand that you need to keep TestModule the same and just step back one level. Anyway, this is just an implementation detail that won't be exposed, so it's fine.

I think we need to offer some lifecycle hooks for application instances. Perhaps we could offer an application instance initializer hook which would give access to the instance and allow for custom registrations / lookups just like a regular instance initializer. We want those customizations done on the instance, not the Application, so that we can tear it down and throw it away after every test run.

[mmun]

(I'm also not a fan of AbstractTestModule :P)

I'm not exactly sure what you mean by lifecycle hooks. I'd prefer, if possible, to not to add any extra hooks to the test module's callbacks that the let you configuration the application. It feels weird to me to have configuration that applies to an entire module of tests but with no way to override per test.

Would implementing something like this.boot() be sufficient to get this mergeable?

[dgeb]

@mmun My main concern here is that there's access to the Application instance but not the ApplicationInstance instance (oof).

In other words, getContext().application instanceof Ember.Application not getContext().application instanceof Ember.ApplicationInstance.

Our test suites could run faster if we didn't create instances of both Application and ApplicationInstance for each test.

I realize this is a change from the current blueprinted behavior, and could be handled in a separate PR / discussion if you and @rwjblue think that would be better and we just want to move this forward. This PR on its own is a good step forward.

[mmun]

I'm happy to do the work for it in this PR. I just want to leave any refatoring/renaming to another PR.

Would it be beneficial to share the Application across all acceptance test modules?

[dgeb]

Would it be beneficial to share the Application across all acceptance test modules?

Yes, I think so. There should be no state unique to a test run stored on the Application, so it should be feasible.

[rwjblue]

Thanks @MattEddy and @mmun!

We will continue to iterate...