New testing API

[Turbo87]

The old testing API is sort-of using inheritance on the describe() function to setup and teardown all the necessary pieces. The proposed new testing API is using composition instead via the new setupModuleTest() functions.

• Replace custom it() with original from Mocha
• Extract new setupModuleTest() and related functions
• Add tests for the new functions
• Update README to the new API
• Add deprecation messages to the old API

Before:

import { expect } from 'chai';
import { describeModule, it } from 'ember-mocha';

describeModule(
  'controller:users',
  'Unit | Controller | users',
  {
    // Specify the other units that are required for this test.
    // needs: ['controller:foo']
  },
  function() {
    // Replace this with your real tests.
    it('exists', function() {
      let controller = this.subject();
      expect(controller).to.be.ok;
    });
  }
);

After:

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

describe('Unit | Controller | users', function() {
  setupTest('controller:users', {
    // Specify the other units that are required for this test.
    // needs: ['controller:foo']
  });

  // Replace this with your real tests.
  it('exists', function() {
    let controller = this.subject();
    expect(controller).to.be.ok;
  });
});

/cc @rwjblue @stefanpenner

[rwjblue]

I like it! Would like @dgeb and/or @stefanpenner to review also.

Definitely need deprecations on the existing things I think...

[dgeb]

I like this approach too. I'm in favor of using mocha's describe and it instead of overriding.

My only real issue is with the method name setupModuleTest. Can we drop Module and just go with setupTest? Then there would be setupTest, setupModelTest, setupComponentTest, and setupAcceptanceTest.

I regret cargo-culting the term Module over from QUnit (and ember-qunit) and this seems a good chance to drop it.

Open to suggestions here.

[Turbo87]

@dgeb I'd be fine with setupTest(), although in the future we might switch to setupUnit/Integration/AcceptanceTest() anyway once the RFC of @rwjblue gets implemented.

[dgeb]

Yes, good to consider the implications of the testing RFC and aim for consistency with ember-qunit.

[Turbo87]

pinging mr. @cowboyd! @rwjblue said you might have an opinion on this too and he'd like to hear it... 😉

[Turbo87]

@dgeb renamed it to setupTest()

@rwjblue added the deprecation message

should be good to go now unless you have any more suggestions

[cowboyd]

@Turbo87 This looks like a much welcome improvement!

[Turbo87]

@rwjblue can we merge this? any more comments?

[Turbo87]

1️⃣ 2️⃣ 3️⃣

[rwjblue]

I'm 👍 . I'd like a 👍 /:-1: from @dgeb and/or @trentmwillis before landing...

[Turbo87]

Given that I addressed everything in #84 (comment) I assumed that he was 👍 too

[Turbo87]

@dgeb @trentmwillis ping 😉

[trentmwillis]

👍 didn't review the code, but I agree with this approach. Primarily, I like that it provides better separation between the default test framework and the Ember-specific test helpers. I also believe this will make it easier to retain all the default behaviors of the underlying framework (something we've had issues with in ember-qunit).

[dgeb]

Given that I addressed everything in #84 (comment) I assumed that he was 👍 too

Yep, thanks for addressing my concerns @Turbo87. Let's ship this!

[Turbo87]

🎉

[Turbo87]

@dgeb @rwjblue any plans for a 0.9 release?