-
-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow overriding services/factories in the registry. #96
Conversation
By default in Ember things that are automatically resolved take precedence over things that are manually registered. This is somewhat counterintuitive to many people, as they would like to be able to override a service or other factory in a given set of tests (for example to use a mock analytics service). The ability to do this has existed since the SSR/Fastboot work that split the registry from the container in 1.11, but I only recently realized how I could leverage that work here. This change adds new functionality on Ember 1.11+, but allows older versions to continue to work as they do today (aka non-breaking). --- Example: Assuming you have a `app/services/analytics.js` and want to use a mock service for a set of component integration tests, you might do something like this: ```javascript import MockAnalyticsService from '../mock-services/analytics'; import { moduleForComponent, test } from 'ember-qunit'; moduleForComponent('something-cool', { integration: true, beforeEach() { this.registry.register('service:analytics', MockAnalyticsService); } }); ``` In the above scenario, the mock service would be used instead of the one at `app/services/analytics.js`.
Allow overriding services/factories in the registry.
Great work @rwjblue! |
Does this only apply to component integration tests? Or can this be more widely applied to acceptance tests? |
I was unable to reference |
Acceptance tests generally do not use ember-qunit, so this doesn't do anything for them. More work to come for acceptance tests... |
Right on! Side note, this is awesome! |
Could this be extended to stub out modules as well? ( |
@tim-evans - Generally, I would rather not do that. What is your use-case? |
Mocking out functions that are the only export from a file. This is for the testing story of the "actions" RFC that I proposed. |
If the functions are looked up via the container/resolver, it will already work... |
Hmm... I'll test that! Seems like a nice way to do that. (They're currently using |
This requires documentation. |
@mixonic - TBH, I'm not sure we can document it. AFAIK, registry is private. |
Also, this project contains no documentation (though we could document in the ember-qunit README which is a bit more fleshed out). |
By default in Ember things that are automatically resolved take precedence over things that are manually registered. This is somewhat counterintuitive to many people, as they would like to be able to override a service or other factory in a given set of tests (for example to use a mock analytics service).
The ability to do this has existed since the SSR/Fastboot work that split the registry from the container in 1.11, but I only recently realized how I could leverage that work here.
This change adds new functionality on Ember 1.11+, but allows older versions to continue to work as they do today (aka non-breaking).
Example:
Assuming you have a
app/services/analytics.js
and want to use a mock service for a set of component integration tests, you might do something like this:In the above scenario, the mock service would be used instead of the one at
app/services/analytics.js
.