teddyzeenny / ember-mocha-adapter

A mocha adapter for ember-testing.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ember-mocha-adapter and mocha tests returning promises

jschilli opened this issue · comments

I'll try to put together a fiddle to illustrate this soon. I am looking for some guidance/direction before pursuing a PR/code solution.

We have a largish ember app and use mocha for both unit and integration tests. Our CI build runs the test suite comprehensively.

Because we're running both unit and ember-testing tests together in the same suite, we began using ember-bdd as our mocha interface. All good, works fine.

With the advent of mocha supporting promises directly return App.someModel.find().should.eventually.be.resolved we noticed that a test that should have failed was passing and traced it back to an impedance mismatch between ember-mocha-adapter and the new mocha semantics for promise returning tests.

I understand the core value prop for ember-mocha-adapter as glue to the ember-testing code but am wondering if its reasonable to pursue supporting promise returning tests as well.

I'm still tracing through the code to reason about where and what those changes would be. In the interim I thought I'd throw this out for comment.

it('should decode base64 data', function() {
        return App.SystemNotification.find().should.eventually.equal('You sir, are not funny!');
    });

Hmm, I wrote this before promise support was added.

Since we are only writing a mocha interface here (ember-bdd), the key is to figure out why the original bdd interface works and our interface doesn't. What's the difference between bdd and ember-bdd that's breaking it..

@teddyzeenny

I have a PR that we're finishing testing. Essence of it boils down to this:

  function invoke(context, fn, d) {
    done = d;
    var result = fn.call(context);
    if (result && typeof result.then === 'function') {
      result.then(function() { d() }, d);
    } else {
      if (!isAsync) {
            done = null;
            d();
          }
    }
  }

which I cribbed directly from mocha. I'm holding the PR until we validate that our entire suite executes cleanly and doesn't break existing semantics