teddyzeenny/ember-mocha-adapter

A mocha adapter for ember-testing.

Ember Mocha Adapter

DEPRECATED: The ember-mocha-adapter is now part of the ember-mocha project!

A mocha adapter for ember-testing.

This adapter makes async testing ember apps with mocha easier.

It gets rid of the done() callback and lets you test without worrying whether your tests are sync or async.

Setup

Just include the adapter.js file in your test. The Mocha Adapter will automatically be set as the default Test Adapter.

This adapter calls mocha.setup() for you. If you call mocha.setup() in your test setup code you will break this adapter.

You should setup Ember.js for testing as described in the documentation. These function calls should happen outside any Mocha callback.

To run the tests, call mocha.run() like this:

Ember.$(function() {
  mocha.run();
});

Example:

describe("Adding a post", function() {

  beforeEach(function() {
    visit('posts/new');
  });

  afterEach(function() {
    App.reset();
  });

  it("should take me to a form", function() {
    find('form').should.exist;
  });

  it("should not submit with an empty title", function() {
    click('.submit');

    andThen(function() {
      find('.error').text().should.equal('Title is required.');
    });
  });

  it("should create a post on submit", function() {
    fillIn('.title', 'Test Post');
    fillIn('.body', 'This is the body');
    click('.submit');
    andThen(function() {
      find('.post').should.exist;
      find('.post-title').text().should.equal('Test Post');
    });
  });


});

ember-mocha-adapter's Issues

What is the License for this project?

@teddyzeenny Can you please add a license for this project.

Integrate Ember resolver helpers

There's an open ticket on the ember-qunit project to split out the Ember stuff from the qunit stuff.

With that completed, it'd be great to integrate the moduleFor style helpers.

Let me know if I can help out with this in some way.

Possible to run single test file?

Hi there,

I find that it slows me down to need to run ever single test every time that I want to re-run a particular test. Is there any sort of flag/setting to allow me to run test from a particular file?

Thanks!

Jeff

Migrate into ember-mocha?

I'd like to reduce the general number of "moving parts" in ember-mocha as I prepare to start working on implementation for emberjs/rfcs#119.

@teddyzeenny - Would it be OK for me to inline the work you have done here, into ember-mocha (with proper credit of course)?

Async tests running before route loads

The issue is that if I do a visit(..) anywhere (beforeEach or within a test) Mocha doesn't wait for the route to load, but runs the test and obviously fails since the DOM elements aren't there yet.. I hope I'm doing something wrong.. We tried to solve this on IRC before, but had no luck.

Have a look at this SO question which also has a jsbin.

d variable in asyncEnd is null when called.

I have a situation where the d(); in asyncEnd throws an error because d is null. Because the code is in a timeout, there is no stack trace. I'm currently trying to figure out the case that this happens, but if you have any thoughts, I'd very much appreciate it!

timeout of 2000ms exceeded

Thanks for making this adapter. It's eased my transition away from the pain that is doing BDD with QUnit ;)

I'm having trouble with the Async tests and I'm not entirely sure why. This may not be a bug in the adapter, but hopefully you can shed some light on it for me. (Apologies in advance for potentially stupid question.)

I have the following tests:

describe 'application', ->

  beforeEach ->
    Ember.run ->
      App.reset()

  describe 'sign-up', ->

    beforeEach ->
      visit '/sign-up'

    it 'should be navigable', ->
      App.get 'currentPath'
        .should.equal 'sign-up'

    describe 'elements', ->

      it 'should have an input element \'.email\'', ->
        find 'input.email'
          .should.exist

      it 'should have an input element \'.password\'', ->
        find 'input.password'
          .should.exist

      it 'should have an button element \'.login-btn\'', ->
        find 'button.login-btn'
          .should.exist

    describe 'successful signup', ->

      beforeEach ->
        App.Store = DS.Store.extend
          adapter: DS.FixtureAdapter.extend {}

      it 'should redirect to \'apps.index\'', ->
        fillIn 'input.email', '[email protected]'
        fillIn 'input.password', 'giraffe'
        click 'button.login-btn'
          .then ->
            App.get 'currentPath'
              .should.equal 'apps.index'

All of which work fine except last one. The code is obviously getting into the final test as if I set that assertion up to fail then the test fails with that message, but as it is I get:

timeout of 2000ms exceeded

Is there something I need to do with the async here to prevent this?

Thanks

`mocha.checkLeaks()`: noop or bad?

In issue #8 you said "I don't let mocha track global leaks; not sure if it's possible since Ember testing helpers are injected globally by default." Does this mean that calling mocha.checkLeaks() is a noop or is actively bad? In either case I would like to add it to this project's README if you will accept it.

It is reasonable that you don't want README to have to track API in other projects but this is a non-obvious change in what a mocha user would expect so I think it is worth highlighting.

cheers
/Eoin/

Proposal: ember-cli addon (or integration?)

Would be great if there was an ember-cli addon ember-cli-mocha which auto-configured mocha testing for an ember-cli app ;)

using assertion library “expect” within promise does not work

Hi there, I want to begin with thanks for creating this adapter without which testing ember app with mocha would have been impossible.
I have been facing an issue which I think is associated with the adapter but I may be wrong. When using "expect" asserts within a promise I always get a js error. I had posted this issue in stackoverflow here: http://stackoverflow.com/questions/20005458/using-assertion-library-expect-within-promise-does-not-work?noredirect=1#comment29873715_20005458

Thanks,
Dee

Release new version

With the changes to automatically set the adapter and the two changes to the Readme, the version released on NPM is now out of sync with the documentation.

Adding more detail to the Read Me

Hello @teddyzeenny,

First of all I wanted to say thanks for taking the time to write this adapter. I am just in the process of learning how to test Javascript and Ember and so far I have my first (proper) failing test, yay! 😄

One thing I think would be helpful is to add a bit more information to the Read Me on the setup and usage of this adapter. As Ember testing still seems to be unsettled territory there are a few unofficial sources of how to test Ember with Mocha and I'm not sure which things apply if you are using ember-mocha-adapter and what can be left out.

Specifically do you feel things like this need to be included in the setup when using ember-mocha-adapter?

App.setupForTesting()
App.injectTestHelpers()

mocha.globals(['Ember', 'DS', 'App', 'MD5'])
mocha.timeout(500)
chai.Assertion.includeStack = true

$.fx.off = true

afterEach ->
  App.reset()

App.setup()
App.advanceReadiness()

ENV = {
  TESTING: true
};

from tutorials like http://matteodepalo.github.io/blog/2014/01/03/ember-integration-testing-with-konacha/ and http://blog.crowdint.com/2013/11/20/testing-ember-js-applications-with-konacha.html

Also, does the testing changes released in Ember 1.3.0 affect this adapter's implementation in anyway?

Thanks for any help you can provide. If you answer the above questions I would be happy to submit a Pull Request to the Read Me if you would like.

Cheers.

Bower

Hey @teddyzeenny, I was thinking maybe it would be nice to register this in the bower registry. I barely came across this but would have found it if it was in bower.

What do you think?

Cheers

Be able to manually calling done()

I am running into trouble with a test where I want to manually control when done() is invoked. Here is an example:

it('should inform the user that they got the answer wrong', function (done) {
  visit('/testing123')
  .then(function () {

    // a helper that makes the app's root DOM node visible. CSS Animations do
    // not run unless they are visible (presumably a performance thing)
    showEmberRoot();

    var listener = function (e) {
      // Yay the animation ran!
      done();
    };

    left.addEventListener('webkitAnimationStart', listener, false);
  })
  .click('.thing')
  .click('.other-thing')
  .then(function () {
    hideEmberRoot();
  });
});

In the example above, the user clicks on stuff that triggers the addition of a class to an element. This class triggers a CSS animation and is removed when the animation finishes. This makes it tricky to test because sometimes the animation has finished and the class has been removed before the test can get to it.

The error I get is that Mocha complains that done() is called twice. This makes sense as I call done in listener() and the adapter calls it too. Just to be clear, I'm not asking/expecting you to fix my test 😄 - there are a few ways I can get around this for this particular instance but in general it would be very convenient to be able to use the done callback in tests - it is one of Mocha's best features I think. Is this something that you would consider addressing in the adapter? I am happy to try and PR something if you feel like it is a feature you would consider.

andThen / then issue after visit

Hi teddyzeenny,

thanks for creating this adapter, should be useful to many people who dislike QUnit.

Nevertheless I've encountered a strange behavior which I cannot fix myself as I'm not deep enough into mocha testing and your adapter.

I've created a fiddle http://jsfiddle.net/UD2D3/ which can be used to reproduce the problem.

Note that all tests titled "should fail" are expected to fail. If the visit helper is used in the beforeEach hook everything works as expected. But if the visit helper is used in the test function combined with andThen/then the failed tests look like they were executed successfully. In reality the tests fail, but the error is only reported in the console instead of the mocha UI.

This bug might be related to issue #6 .

Thanks for your advice.

Best regards,
toovy

Patch Release

Can you please cut a patch release with the fix from #25 in it so I don't need to run off master for my tests to run.

How to catch promise rejections?

Hi everyone,

I'm trying to write an acceptance test where a user would submit and invalid form. I'm using ember-cli-mirage.

Here is the test:

it('shows an error message', function(done) {
  server.create('user');
  server.put('user/1', { message: 'Invalid data' }, 400);

  visit('/my-account');

  Ember.run(function() {
    click('.save-button');
  });

  andThen(function() {
    assert.equal(currentRouteName(), 'my-account');
    assert.equal(find('.alert-error').length, 1);
    done();
  });
});

And here is the save method:

actions: {
  saveUser(user) {
    var promise = user.save();

    promise.then(() => {
      this.alerts.success('User saved.');
      this.transitionTo('index');
    });

    promise.catch(()=> {
      this.alerts.error('Cannot save.');
    });
  }
}

My test keeps failing with the message Error: Adapter operation failed. I've been told to wrap the click inside Ember.run but it doesn't change much. The test passes but the afterEach hooks fails with the same error message.

Since I'm catching the error in the saveUser method, why is my test failing? Any idea on how to prevent that?

Race condition sometimes generates error `null` is not a function

I encountered a problem, probably due to a race condition.

The d() method call sometimes fails and results in an error null is not a function.

I cannot clearly reproduce the problem, but it did not appear again since I change the line linked above with this one:

if (d) { d(); }

Please let me know if it seems an acceptable fix so I can submit you a PR.

Thanks !

Tests failing randomly with async code

I have random failures as soon as a promise is used in the tested code.

I usually get this error:

Error: Assertion Failed: You cannot defer readiness since the `ready()` hook has already been called.

I’m assuming I must be doing something wrong, so I asked the question on StackOverflow, but didn’t get a correct answer yet.

Here is a JS Bin testcase. It contains 10 times the same test and usually fails (tested with Firefox and Chromium).

The same tests run fine with QUnit (maybe by chance :)): JS Bin testcase.

I tried wrapping the promise in an Ember.run() call and also not calling mocha.setup(), but it doesn’t solve the problem.

Also, the JS Bin testcase of the proposed answer on another related question on StackOverflow still fails for me with the same error message.

ember-mocha-adapter and mocha tests returning promises

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!');
    });