如何测试Ember.js引擎路由且规避ember/no-restricted-resolver-tests ESLint错误？

Let’s break down your problem and the practical solutions available:

Why the Conflict Occurs #

The ember/no-restricted-resolver-tests ESLint rule is built to encourage modern Ember testing patterns—specifically, avoiding manual resolver setup when newer test helpers can handle context automatically. However, in Ember 3.8 (and earlier versions), the engine testing tooling didn’t support this automatic context handling. The Ember Engines documentation at the time correctly reflected the required approach for these older versions, which creates a clash with the ESLint rule optimized for newer Ember releases.

Your Fix for Ember 3.8 #

Since you’re working with Ember 3.8 right now, your test code is actually correct for this version. To resolve the ESLint error, you have two safe options:

• Disable the rule for the entire test file: Add this comment at the very top of your test file:

  /* eslint-disable ember/no-restricted-resolver-tests */
  

• Disable the rule only for the problematic line: Adjust your setupTest call like this:

  setupTest(hooks, {resolver}); // eslint-disable-line ember/no-restricted-resolver-tests
  

Looking Forward: Upgrading Ember #

If you plan to upgrade your Ember version to 3.14 or later, you can drop the manual resolver setup entirely. Newer test helpers let you specify the engine’s module prefix directly, which aligns perfectly with the ESLint rule’s expectations:

import { module, test } from 'qunit';
import { setupTest } from 'ember-qunit';

module('[user-backoffice] Unit | Route | my-engine-route', function(hooks) {
  setupTest(hooks, { modulePrefix: 'user-backoffice' });

  test('it exists', function(assert) {
    let route = this.owner.lookup('route:my-engine-route');
    assert.ok(route);
  });
});

This way, you won’t need to disable any ESLint rules, and your code will follow modern Ember best practices.

Final Takeaway #

In your current Ember 3.8 setup, locally disabling the ember/no-restricted-resolver-tests rule is the right call—your test code matches the documentation requirements for that version. The conflict is simply a mismatch between the rule’s modern focus and the older engine testing workflow you’re using. Once you upgrade Ember, you can transition to the rule-compliant approach seamlessly.

内容的提问来源于stack exchange，提问作者bartocc