Testing - Example Issues?

What is the mechanism to get all the new testing goodness into an older test suite that uses Mocha?

I saw some codemods mentioned for ember-cli-mocha mentioned in @TBieniek’s Emberconf talk, but I’m not sure there is a canonical guide yet.

there is a beta release for ember-mocha (not ember-cli-mocha) that includes support for the new testing APIs. I’ve been holding off on releasing it as stable because I was hoping someone would do the work and update the existing codemod to the new APIs. unfortunately that has not yet happened though.

1 Like

Thanks for posting that link. The moved video is here: - YouTube. Unfortunately that link does not include the actual testing talk part.

I would start with:

  1. install ember-cli-mirage
  2. Create fixtures for your most common api calls, especially those already made when you start up your app.
  3. Setup route handlers to return those fixtures in mirage/config.js
  4. Create a simple acceptance test that does visit(‘/’) and get it to pass.
  5. Start adding unit tests for commonly used services.
  6. Start adding component integration tests for your ‘leaf’ components, components that do not contain components inside them.
  7. Look through your utils and helpers for simple testable functions and write unit tests for those.
  8. As you get practiced at writing tests, start writing tests for whatever bugs you are fixing and whatever features you are implementing while continuing to backfill tests.
  9. Once you are at a certain point where you feel comfortable, start looking into factories and models and serializers with Mirage. Start working on getting your app working in ‘Mirage mode’ where all your backend calls are instead faked by Mirage. As you do this, it will become easier to write acceptance tests.
  10. Write a few acceptance tests for the most critical flows in your app.
  11. At this point, start requiring tests with every PR as part of your code review process.

Good luck. It’s very much worth it when you can make a change with confidence you haven’t broken stuff. And especially when you can do a major refactor without fear.

4 Likes

I know they had some technical issues with the streaming, but maybe @samselikoff managed to salvage the video or audio from Rob’s talk?

Ya, we did record it (ended up recording locally as a backup). I gave a copy to @ryanto last Friday, but I’m guessing it’s a bit of work to polish up…

Thank you so much! I still definitely be going over your suggestions with my team

Sorry all - team EmberMap is at a conference this week and we’ve been busy, but we’ll update the talk soon and post here!

1 Like

@rwjblue I think a question came up regarding testing drag and drop. We’re using ember-sortable and adding support to our feature to use keyboard for A11y and power users. In the test it’s easy to trigger the keyboard commands to facilitate sorting. I know that’s not testing drag and drop but it is testing our sortable feature in a simple way. My recommendation is to look for opportunities to use A11y to push for keyboard solutions as they are testable too :slight_smile:

Ember NYC has now posted the full talk.

2 Likes

What’s the difference between ember-mocha and ember-cli-mocha?

as posted on Anything blocking deploying the new testing API? · Issue #205 · emberjs/ember-mocha · GitHub yesterday:

at this point ember-cli-mocha is just a legacy wrapper that will eventually go away.

the same is true for ember-cli-qunit. the reason why they still exist is that some other packages (including Ember itself) rely on those package names to determine what testing framework is being used. we have updated all known packages to be compatible with ember-qunit and ember-mocha, but wanted to give users a bit more time to update to those adjusted releases.

3 Likes

Is it expected that to use the new test syntax in an addon, I would have to drop ember 1.13 support?

The newer style tests setupRenderingTest / setupApplicationTest / setupTest require Ember 2.4 or higher.

1 Like

@TBieniek Thanks for the engine testing workaround, this seems to get integration tests working for my app too. However, I had to add a couple lines, posting here in case anyone else runs into issues:

import Resolver from 'dummy/resolver';
import engineResolverFor from 'ember-engines/test-support/engine-resolver-for';

let engineResolver = engineResolverFor('engine-name');

const resolver = Resolver.extend({
  resolve() {
    let resolved = this._super(...arguments);
    if (resolved) {
      return resolved;
    }

    this.namespace.modulePrefix = 'engine-name';

    return engineResolver.resolve(...arguments);
  },
}).create({
  namespace: {
    modulePrefix: 'dummy'
  }
});

Basically, I needed to create the Resolver with a namespace object with a modulePrefix prop. I believe the commit removing the fallback to the DefaultResolver in ember-resolver changed the semantics somewhat