The following code will let an ember addon provide an addon-test-support/ folder whose contents get merged into app/mirage/. It excludes addon-test-support/ from the build if mirage is disabled.
See Better Addon Support on the Ember CLI Mirage feature-request board.
BACKGROUND
In the [RFC-232] , [RFC-268] style tests we wanted to simplify some of the abstractions around testing, so it is simpler to implement, and the ecosystem gets out of the way more. This led to a paradigm shift from "I'm doing an x-style test", to "I'm testing X and need Y and Z configured in order to do it". E.g moduleForComponent -> setupRenderingTest, moduleForAcceptance -> setupApplicationTest.
In implementing the new style blueprints for ember-data, I'd like to understand where we'd like the ember-data testing story to go, and if this is the right point to do so, since we will be modifying those files.
As such, what are analagous concepts we could introduce for ember-data? Does it make sense to introduce these analagous concepts?
Ember Data Classes Who's Testing Use Cases We Need To Ensure We Address
Ember.js Testing package was a great addition to the project. It allowed us to have fast specs to guarantee the defined behavior. However, there's no convention on how you should guarantee that your models, the heart of any Ember.js application, are valid in relation to your backend.
Put another way, if you have an User model with a name attribute, how can you be sure that your backend is still responding with {"user": {"name": "Your Name"}}? So, even though your acceptance specs pass, you're stubbing out your models with FIXTURES.
Most people either manually test their apps or create an end-to-end test with the backend server, which is slow as hell (think of Capybara). The good news is that there are conventions for solving this since like forever. One way to guarantee this integrity is via Contract tests (http://martinfowler.com/bliki/IntegrationContractTest.html). Basically, you have a test to guarantee your models are matching your backend.
Using server-side end-to-end tests have many drawbacks,