[WIP] Update blueprints to take advantage of implicit Ember.run in beforeEach/afterEach

[cowboyd]

As of ember-mocha v0.8.3, beforeEach and afterEach now happen in the context of an Ember.run, and so this takes advantage of that.

This also changes the visit invocation to happen in its own beforeEach to move it in line with the convention that side-effcts happen in beforeEach blocks, and assertions in it blocks. (I find that I very rarely use andThen)

If this looks good, I can change the other test blueprints.

[rwjblue]

Since you were up, can you change beforeEach of acceptance test blueprint to avoid the closure scoped variable (instead using this.application = startApp();). This is more in line with the default Ember CLI setup now, and makes some helpers easier to write.... KTHXBYE

[rwjblue]

Seems kinda weird to have two beforeEach blocks (maybe that is super common in mocha-land?)...

[cowboyd]

It's fairly common to separate setup concerns. In this case, application setup vs page navigation, but what I'd probably do IRL, is either extract the app setup into its own helper, or If I was feeling like a BDD purist that day, I'd introduce a new description coupled with the new setup. E.g.

describe('Acceptance: <%= classifiedModuleName %>', function() {
  beforeEach(function() {
    this.application = startApp();
  });

  afterEach(function() {
    this.application.destroy();
  });

  describe("visiting /<%= dasherizedModuleName %>", function() {
    beforeEach(function() {
      visit('/<%= dasherizedModuleName %>');
    });

    it("transitions successfully", function() {
      expect(currentPath()).to.equal('<%= dasherizedModuleName %>');
    });
  });
});

I always chafe at the amount of boilerplate in the acceptance tests anyhow, what about introducing a dedicated test helper for acceptance tests, so it could become something like:

describeAcceptance(' <%= classifiedModuleName %>', function() {
  beforeEach(function() {
    visit('/<%= dasherizedModuleName %>');
  });

  it("transitions successfully", function() {
    expect(currentPath()).to.equal('<%= dasherizedModuleName %>');
  });
});

Setting up and tearing down the application would just happen automatically.

[rwjblue]

There is a proposal in one (or all) of ember-test-helpers, ember-cli, ember-qunit to add moduleForAcceptance for exactly the reasons that it chafes. If you have time, poke around over there and chime in...

[cowboyd]

I didn't find anything explicitly mentioning moduleForAcceptance in terms of a formal proposal over at ember-test-helpers. Maybe I'm missing something? In any case, I can certainly have a look.

[cowboyd]

Found this proposal here emberjs/ember-test-helpers#94 which might me what we're looking for

[rwjblue]

@cowboyd - I can't recall where we landed on this. Is this waiting on me somehow?

[Turbo87]

Closing this as the blueprints have been moved to https://github.com/emberjs/ember.js/tree/master/blueprints/acceptance-test (and https://github.com/ember-cli/ember-cli-legacy-blueprints). In general this change makes sense to me though, so feel free to reopen on the ember.js repo!