Component tests run fine if in the 'root' describe block, but throw 'You have turned on testing mode, which disabled the run-loop's autorun' error when in nested describe blocks

[fushi]

The following pseudo code works fine:

describe('Unit | Component | common | input-with-validation', function() {
  setupComponentTest('componentToTest', {
    needs: [],
    unit: true
  });
  beforeEach(function () {
    component = this.subject();
  });

  it('Test Observer', function() {
    component.set('observedKey', true);
  }
}

but the following does not, and raises an assertion error: You have turned on testing mode, which disabled the run-loop's autorun. You will need to wrap any code with asynchronous side-effects in a run

describe('Unit | Component | common | input-with-validation', function() {
  setupComponentTest('componentToTest', {
    needs: [],
    unit: true
  });

  beforeEach(function () {
    component = this.subject();
  });

  describe('Observers', function () {
    it('Test Observer', function() {
      component.set('observedKey', true);
    }
  }
}

[Turbo87]

@fushi where are the setupComponentTest() calls in your code?

[fushi]

Updated the original question with more complete code blocks

[fushi]

I've got a very ugly workaround, for now:

Create a test helper

import Ember from 'ember';
import { it as originalIt } from 'mocha';

function it(label, func) {
  originalIt(label, function () {
    Ember.run(this, func);
  });
}

Object.keys(originalIt).forEach(key => it[key] = originalIt[key]);

export {
  it
};

And in the test file:

import { it } from 'tests/helpers/mocha-helper';

[Turbo87]

import { expect } from 'chai';
import { describe, it, beforeEach } from 'mocha';
import { setupComponentTest } from 'ember-mocha';

describe('Unit | Component | foo bar', function() {
  setupComponentTest('foo-bar', {
    // Specify the other units that are required for this test
    // needs: ['component:foo', 'helper:bar'],
    unit: true
  });

  let component;
  beforeEach(function() {
    component = this.subject();
  });

  describe('bla', function() {
    it('renders', function() {
      component.set('foo', 21);
      expect(component.get('bar')).to.equal(42);
    });
  });
});

seems to work fine for me

[fushi]

Rendering is fine, it's only when you attempt to modify a component attribute that is being watched by an observer.

[rwjblue]

Can you share a demo repo? I'm getting confused 🙃

I just reproduced this in our app. Here is an example test that reproduces the error: https://github.com/efx/ember-mocha/commit/560abc959fe70abd8baf8313eeecb055117aebe0

[plwalters]

Just ran in to this as well, any ideas? Is it basically just recommended to not use nested describe blocks with ember-mocha?

[fushi]

@pwkad We've been using the workaround from above successfully for the last 6 months.

Rebased the above reproduction failure on this branch: https://github.com/efx/ember-mocha/tree/bug-132.

The error comes from an ember.js or ember-data validation. Wrapping a try catch around this line causes the error to disappear: https://github.com/emberjs/ember-mocha/blob/master/vendor/ember-mocha/ember-mocha-adapter.js#L69. That seems like a workaround. I do not know what effects it could have on other kinds of exceptions, et. al. @Turbo87 is this kind of fix worth pursuing? Or are there broader refactors that could help this case?

[Turbo87]

that link goes to 404 for me 🤔

IMHO similar to how QUnit does it we should not start any runloops automatically in Mocha. This has been a major pain and also can't be implemented reliably. This is obviously a breaking change, so my plan is to tackle these things once the Ember CLI addon transition (see #173) has been completed.

whoops, updated so it should work.
Ah interesting. Great, thanks for the update. I'll be glad to help test / try out the fixes on the application I work on.

[rreckonerr]

@efx Just hit the same problem. Can you please share the reproduction links again? The above mentioned ones seem to be broken.

@rreckonerr I deleted my fork and that work; apologies! I will take a look later today to see if I have a copy locally. I reduced the example to the most basic form. You should be able to see the issue by simply nesting the 2nd describe in the first one. For the record, our team avoids nesting describe blocks in our ember application because of this.