Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inject integration test helpers into component integration tests. #67

Closed
tim-evans opened this issue Jun 26, 2015 · 5 comments
Closed

Comments

@tim-evans
Copy link
Contributor

I found myself using the helpers click, keyDown, and friends in component integration tests. This worked for me because our test-helpers.js starts a test on every QUnit run:

import startApp from './helpers/start-app';

QUnit.testStart(function () {
  window.App = startApp();
});

Using test helpers in component tests where integration: true feels very natural. Any thoughts on injecting test helpers in the setup for the moduleForComponent?

@mitchlloyd
Copy link

I was trying to put together a test for a component that makes an ajax call and found it very awkward. Being able to use these test helpers would be helpful.

@praxxis
Copy link

praxxis commented Jul 22, 2015

This worked out of the box for me in 1.12, but in one of the point release 1.13's it broke, due to this change. Basically, view lookups stopped being a just-in-time check of a global shared by all "applications" (I put that in quotes because technically there's no application in the test helpers, but views do get registered into that global). That change meant that the application built by startApp no longer had knowledge of the component views created in the test. When an event was invoked in the component, by clicking or filling in or whatever, the application event dispatcher couldn't find the view with the action corresponding to the event.

I fixed this by creating a test function that recreates the integration test event dispatcher with a link to the applications container, so view lookups worked again:

export default function (context, app) {
  run(app, () => {
    // destroy the old dispatcher...
    context.dispatcher.destroy();

    // ... then replace it with a dispatcher that knows about the application container
    context.dispatcher = EventDispatcher.create({
      container: app.container
    });

    context.dispatcher.setup({}, '#ember-testing');
  });
}

In my tests I'd use it as such:

  beforeEach() {
    App = startApp();

    linkAppDispatcher(this, App);
  },

@rwjblue
Copy link
Member

rwjblue commented Jul 22, 2015

@praxxis - Thank you for the detailed explanation and workaround.

@praxxis
Copy link

praxxis commented Aug 19, 2015

Huzzah, I updated a bunch of dependencies (including going to Ember 2.0) and no longer need to re-link the container with the above workaround. I assume it was #90 that fixed it

@rwjblue
Copy link
Member

rwjblue commented Oct 16, 2017

FWIW, these helpers are available via ember-native-dom-helpers, and I plan to submit an RFC to expose them directly from ember-test-helpers in the near future (as soon as the changes from emberjs/rfcs#232 are totally finished).

I'm going to close this for now (since it is possible with that addon)...

@rwjblue rwjblue closed this as completed Oct 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants