Question: Can I setup multiple resolvers in an acceptance test?

[danielspaniel]

I was looking at the docs from 'ember-mocha' here:
https://github.com/emberjs/ember-mocha#setting-the-resolver

and it is suggesting you can set multiple resolvers in a mocha test, and since the setResolver method is one that is borrowed from 'ember-test-helpers', I was wondering if that really would work in a qunit test. Ie. to set up 2 resolvers in a test.??? Especially an acceptance test.

I tried it already in qunit test with setResolver(myOtherResolver) in the beforeEach of the module, but that did not work.

import {module} from 'qunit';
import startApp from '../helpers/start-app';
import {setResolver} from 'ember-test-helpers';
import destroyApp from '../helpers/destroy-app';
import myOtherResolver from '../helpers/engine-resolver';

export default function(name, options = {}) {
  module(name, {
    beforeEach() {
      this.application = startApp();
      setResolver(myOtherResolver);  // <-----------------------
      if (options.beforeEach) {
        options.beforeEach.apply(this, arguments);
      }
    },

    afterEach() {
      if (options.afterEach) {
        options.afterEach.apply(this, arguments);
      }

      destroyApp(this.application);
    }
  });
}

[trentmwillis]

You can't have more than one Resolver in a given test as it does not make sense to have multiple ways to look up a single module.

Additionally, the setResolver method only sets up the Resolver to use during Unit and Integration tests. For Acceptance tests, since you're testing the full application, the application will simply use the Resolver that it normally does.

Also, for Unit/Integration tests, if you want to set a different Resolver for a specific test module, you should use the resolver option (which needs to be documented).

[danielspaniel]

Yeah ... I hear you .. it is a pretty remote use case, because I am trying to make mock data with factory-guy with models that are in an engine, and factory-guy needs to know about the model it is mocking. Since engine models are not available to the application, when I run application level acceptance tests, I can't build a payload for a page that will have that engine.
You might say, no problem, just run acceptance tests within that engine for routes in that engine.
I say, very good point.
But sometimes it might be nice to test an application page/route that uses an engine route somewhere in a child route / outlet.
So, I will close this and call that a day.