I have a test where I was passing { integration: true } in order to use a model with a hasMany relationship. After upgrading from 0.3.1 to 0.3.2, running this.subject() throws an error:

TypeError: Cannot read property 'createRecord' of undefined

I've found that when setting the integration flag, this.container.lookup('store:main') returns undefined. Without the flag, this.container.lookup('store:main') returns a store object.

I'm looking at using the ember-mobiletouch addon, which extends Ember.EventDispatcher. However, I don't see a way to get this to work with Ember unit component testing. It seems that the setupComponent method of test-module-for-component assumes the dispatcher will be a stock Ember.EventDispatcher. Is there a natural way to configure the dispatcher? Perhaps an overridable hook which defaults to the stock dispatcher? Alternatively, we could modify ember-mobiletouch to reopen the dispatcher instead of extend it. Thoughts?

The tests are failing for the latest beta and canary versions of Ember. As far as I can tell, it's related to a change in the registry in which registry.resolver became registry.resolver.resolve.

I will work on creating a PR since we need the latest canary for performance enhancements that have recently landed.

Given a service foo-bar, a route with fooBar: Ember.inject.service(), and a unit test with needs: ['service:foo-bar'], the test blows up and fails to find the injected service via implicit name lookup.

Currently when callbacks for a test module are contextualized, they get bound to the test module rather than the test context. This causes inconsistent behavior, since setup/teardown get invoked with the test context.

Practically, this means that if you do something such as:

moduleFor('component:foo-bar', {
  integration: true,

  setup() {
    this.set('title', 'first title'); // works as expected
  },

  changeTitle() {
    this.set('title', 'second title'); // doesn't work
  }
});

test('it renders', function(assert) {
  this.changeTitle();
});

changeTitle won't work properly, instead you have to do:

changeTitle() {
  this.context.set('title', 'second title');
}

This is inconsistent and not intuitive. Can we change it such that all callbacks are invoked with the test context? This might limit access to some test module properties, but I feel most of those shouldn't be getting accessed anyway.

Files in the models folder currently get nerfed due to: https://github.com/switchfly/ember-test-helpers/blob/master/lib/ember-test-helpers/test-module-for-model.js#L41

Error:

Error: Assertion Failed: `(unknown mixin)` does not appear to be an ember-data model
    at new Error (native)

Now that we have {integration: true } capability in TestModule, what do people think about merging the functionality from my new TestModuleForIntegration directly into TestModuleForComponent when integration: true?

This would let us get rid of the separate TestModuleForIntegration name entirely, which I agree is not a great name.

To keep the API understandable, I would suggest that component unit tests keep their existing API but component integration tests would be expected to move to the new template-driven API, with deprecation warnings on the old way.

The test suite is failing on ember-canary.

A build with the failures can be seen at https://travis-ci.org/switchfly/ember-test-helpers/builds/79391044

Relevant section of the build failing is:

not ok 21 PhantomJS 1.9 - component:Component Integration Tests: it can handle actions
    ---
        actual: >
            null
        message: >
            Died on test #1     at http://localhost:7357/testem/qunit.js:251
                at test (http://localhost:7357/assets/ember-test-helpers-tests.amd.js:1764)
                at http://localhost:7357/assets/ember-test-helpers-tests.amd.js:1199
                at http://localhost:7357/assets/loader.js:118
                at tryFinally (http://localhost:7357/assets/loader.js:21)
                at http://localhost:7357/assets/loader.js:124
                at http://localhost:7357/assets/test-support.js:41: Assertion Failed: The action 'didFoo' did not exist on [object Object]
        Log: >
    ...
ok 22 PhantomJS 1.9 - component:Component Integration Tests: it accepts precompiled templates
ok 23 PhantomJS 1.9 - component:Component Integration Tests: it supports DOM events
ok 24 PhantomJS 1.9 - component:Component Integration Tests: it supports updating an input
not ok 25 PhantomJS 1.9 - component:Component Integration Tests: it supports dom triggered focus events
    ---
        actual: >

        expected: >
            init
        Log: >
    ...

We have these on our Application:

customEvents: {
    webkitAnimationEnd: 'animationEnd',
    msAnimationEnd: 'animationEnd',
    oAnimationEnd: 'animationEnd',
    animationend: 'animationEnd'
}

...and in a component integration test:

this.render('{{foo-bar}}')
this.$().trigger('click') // works
this.$().trigger('animationEnd') // doesn't work

I just generated a component integration test for one of my components which has a hardcoded elementId (F*ck me, right?) and the test exploded into my face with
Assertion Failed: Attempted to register a view with an id already in use: myComponentName
because of the two render calls (block and non-block form).

@rwjblue on Slack:

Should we allow multiple this.render calls in one test, and if we do should we teardown the prior one before doing another?
the answers do not seem obvious to me
I guess I would lean towards cleaning up if a this.render was already run....
if you care and have time, i'd love an issue in ember-test-helpers for this
it seems somewhat edge-casey but seems valuable to get it right

I don't have the link-to issue but I have a component that gets router injected into it in an initializer and part of it's code is:

const router = this.get('router');
router.router.currentHandlerInfos.forEach(route => {
...

On an integration test, I keep getting Cannot read property 'router' of undefined. Not sure how to resolve this from an integration test standpoint or an acceptance test should be used. A good medium would be to learn how to initialize and inject router into this component

Glimmer adds/requires a few additional items to the default application registry. We need to account for that here.

Will be fixing soon.

Currently if we set integration:true the store is not available, I asked @dgeb and he mentioned that we should be able to do this.

• It uses Ember.View, which is (soft-)removed since beta.3
• Tests need ember-data#canary because ember-data < 2 uses ArrayPolyfills

I'm cooking up a PR to fix this. Help is definitely welcome.

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?

Integration tests seem to be throwing errors when services are implicitly injected into the object being tested. IE: foo: Ember.inject.service().

I was writing an acceptance test for something that looks like this:

<div class="foo" onclick={{action "foo"}}>Click me</div>

Bad news came when I realized that click('.foo') was triggering the foo action twice, first with a jquery.event with type click and a second time shortly after with a native MouseEvent.

Digging into the helper first and the addon later I've discover that the cause is that jquery's trigger triggers a jquery.event first, and if preventDefault is not called on that event, it fires a native event just afterwards, leading to unexpected behaviour (in my case, toggling a property twice and therefore letting it unchanged).

In real life the same code works perfectly because native events are fired instead.

I don't know if kebab actions, that will also receive native events, can be affected by this too.

Solutions I see:

A) Fire real events instead. Would it be backwards incompatible? I guess that the dispatcher would catch them and turn them into jquery events as it does with regular events in real life, and also mimics real behaviour better.

B) Accept a second argument in helpers click('.css-selector', { native: true }). Clearly backwards compatible, but leaves us with 2 different paths for firing events.

Thoughts?

Definitely not failing the build for missing semi-colons, and possibly not running and failing the build in general.

The following code using this.inject.service never seems to inject the service into the component before trying to render.

/* jshint expr:true */
import { expect } from 'chai';
import {
  describeComponent,
  it
} from 'ember-mocha';
import hbs from 'htmlbars-inline-precompile';

describeComponent(
  'provider-options',
  'Integration: ProviderOptionsComponent',
  {
    integration: true
  },
  function() {
    it('renders', function() {
      // Set any properties with this.set('myProperty', 'value');
      // Handle any actions with this.on('myAction', function(val) { ... });
      // Template block usage:
      // this.render(hbs`
      //   {{#provider-options}}
      //     template content
      //   {{/provider-options}}
      // `);

      this.inject.service('i18n'); // <= This doesn't seem to inject the i18n service
      this.render(hbs`{{provider-options}}`);
      expect(this.$()).to.have.length(1);
    });
  }
);

Upgrade path to using the new attrs hash is difficult...

1. For a unit test which calls this.render:
   The component lifecycle hooks don't get called as you would expect.
2. For a unit test which doesn't call this.render:
   You still need to be able to get the component's attributes, but you can't, because didInitAttrs hasn't been called.
   (A potential workaround is to manually call didInitAttrs but this only works if you actually have a function called didInitAttrs)

Apologies if this is the wrong repo.

I created a controller test through ember generate controller-test band/songs and added a dependency that the real controller under test has:

import {
  moduleFor,
  test
} from 'ember-qunit';

moduleFor('controller:band/songs', 'BandSongsController', {
  // Specify the other units that are required for this test.
  needs: ['controller:band']
});

// Replace this with your real tests.
test('it exists', function() {
  var controller = this.subject();
  ok(controller);
});

That is the only thing I changed. When I run the test I get the following error:

Attempting to register an unknown factory: controller:band

I am running ember-cli 0.1.4, ember-qunit 0.1.8 (bower), ember-cli-qunit 0.1.2 (npm) and I checked that these are the latest versions from both. In fact, ember-cli-qunit installs the right version of ember-qunit in bower.

I also tried to manually set up the resolver by doing this in the test file:

import resolver from '../../../helpers/resolver';
setResolver(resolver);

This did not help, however.

I don't see any mention of integration: true or needs in the README for this lib. As I understand it those are the args for the methods in this lib.

Secondly, as an aside related to Ember itself, it would be better if we leveraged ES6's brilliant module functionality and import the modules which each model class needs in model class itself (like every other JS framework) rather than trying to be Ruby-esque and autoload the classes via a "Resolver". This would avoid the whole integration / needs stuff in the tests entirely.

My team uses a extended store object that gets resolved by Ember at runtime because we put the file in services/store.js. Starting in the new release, our unit tests can't resolve our custom store, the unit test's resolver just gives us the ember one. How do I load my custom store object from a unit test?

As a workaround, I'm just going to refactor the test into an integration test, which does use the integrated store, but as a patch version upgrade, I wouldn't think I would be forced to do so...

I'm trying to write an integration test for a component which touches the store service like this:

moduleForComponent('my-cool-component', {
  integration: true,
  beforeEach: function() {
    this.registry.injection('component:my-cool-component', 'store', 'service:store');
  }
});

test('Can load saved state', function(assert) {
  assert.expect(1);

  this.render(`
    {{my-cool-component}}
  `);

  assert.ok(false);
  stop();
});

What I'm getting is:
at Object.TestLoader.loadModules (http://127.0.0.1:4200/assets/test-loader.js:21:18): Attempting to inject an unknown injection:service:store`

Is this supported at all or am I missing something?

I have a component that yields block-params. That is, its template has {{yield something}} and it is used like

{{#my-component as |x|}}
  Use {{x}} somehow.
{{/my-component}}

I can't use test-module-for-component (or ember-qunit's moduleForComponent) because I need the as |x| in the invocation of my-component.

The only solution I've come up with is writing an integration test that compiles a template and renders an Ember.View. (And I actually haven't gotten that working yet, but suspect I could.)

Works: moduleForComponent('pie-chart');
Works: moduleForComponent('pie-chart', 'PieChartComponent', {});

Errors: moduleForComponent('pie-chart', 'PieChartComponent');

'undefined' is not an object (evaluating 'callbacks.needs')

/cc @sbl

The commit 78ba0c0 breaks the checkbox and switch unit tests over at https://github.com/truenorth/ember-cli-materialize (in particular this assertion: https://github.com/truenorth/ember-cli-materialize/blob/master/tests/helpers/selectable-item.js#L55, because the click() event doesn't propagate to the component).

After doing some debugging on the issue I noticed that, when calling Ember's event_dispatcher.js setupHandler() function, the container that was once undefined is now available, and therefore the viewRegistry is set from the lookup of '-view-registry:main' rather than the global View.views (see https://github.com/emberjs/ember.js/blob/680f997ed0958c420abdcd0b1673111aee26afe7/packages/ember-views/lib/system/event_dispatcher.js#L174).

However, when calling this.subject() from a component test, a view doesn't have the view-registry injected into it, and therefore registers itself with the View.views global (because of the fallback at https://github.com/emberjs/ember.js/blob/360d41da7877cd7b00943f0b8d7e7025bc53dbf2/packages/ember-views/lib/views/view.js#L1323).

This means the view is not available when attempting to look it up by its id in the viewRegistry in the event handling function within event_dispatcher.setupHandler() (at https://github.com/emberjs/ember.js/blob/680f997ed0958c420abdcd0b1673111aee26afe7/packages/ember-views/lib/system/event_dispatcher.js#L177), because two different view-registries are being used, the one by the event dispatcher and the one that the view registers itself on.

Switching the ember-cli-materialize project's ember-qunit bower dependency back to a hardcoded v0.4.6 causes the tests to pass again.

WRT https://github.com/rwjblue/ember-qunit/pull/71

@rwjblue @stefanpenner I'm looking into baking this into switchfly/ember-test-helpers:

// tests/helpers/module-for-acceptance.js

import Ember from 'ember';
import { module } from 'qunit';
import startApp from './start-app'; // This file is the unchanged, `ember new` version

export default function(name, options = {}) {
  let application;

  module(`Acceptance | ${name}`, {
    beforeEach: function() {
      application = startApp();
      if (options.beforeEach) {
        options.beforeEach.call(this, arguments);
      }
    },

    afterEach: function() {
      Ember.run(application, 'destroy');
      if (options.afterEach) {
        options.afterEach.call(this, arguments);
      }
    }
  });
}

So that it's integration with ember-qunit would be as minimal as the rest.

I'm having trouble figuring out how, though.

Any ideas?

Will this work at all, or is it best left as a hand-rolled helper?

The isolated-container depends on a private view: Ember._MetamorphView

https://github.com/switchfly/ember-test-helpers/blob/master/lib/ember-test-helpers/isolated-container.js#L64

This private view is no longer available as of this PR emberjs/ember.js#10670

In ember-cli, test helpers are made available for integration tests by calling startApp(). Ember test helpers are not available for unit tests, nor is it appropriate to call startApp() within a unit test.

However, because unit tests for Ember components rely on the component being tested to exist as part of the DOM, a subset of test helper methods are actually useful in that context - for example, fillIn() or find() (conversely, other test helpers like visit() still do not make sense in the context of a component unit test).

It would be useful to expose an appropriate subset of DOM-related test helpers, scoped to the component being tested (e.g. this.fillIn('selector', 'value'), since the component being tested exists as part of the DOM.

abuiles> dgeb: there is something else that has been buggy my and would like to hear your thoughts on, every time I create a unit test for a model, I have to put in need all the other models which it references in the belongsto and hasMany
6:24 PM all good until there
6:25 PM the really annoying part is that I also have to put all the model which those models reference so I end-up with a bunch of things in "needs" which are not necessarily related to the test
6:26 PM abuiles: yeah, that's a real annoyance :/
6:27 PM we need smarter model tests
6:27 PM this shouldn't be necessary

At one point we could override services in acceptance tests. Now it seems like that behavior is no longer supported:

Is there another solution that currently works?

I'm using Ember 2.2.0 and ember-qunit 0.4.16.

When testing component in integration test, willDestroyElement() is called but didInsertElement() is not called. I would like to call didInsertElement() manually since some component use willDestoryElement() to clean up stuff called in didInsertElement(). However since the component object created is not exposed in integration test. I cannot call it manually. It would be nice if the component instance is exposed or didInsertElement() is called after render() hook

When upgrading from Ember 1.13.3 -> 1.13.4 we have several tests that are now failing with the error Uncaught Error: Assertion Failed: BUG: Render node exists without concomitant env. .

At least one example of a failing scenario would be with a template like:

{{#if savedOption}}
  <button {{action "removeOption" on="click"}}></button>
{{else}}
  {{input value=inputValue}}
{{/if}}

(where the action simply nullifies savedOption)

with the following component integration test:

test('you can click an thing and it disappears', function(assert) {
  var component = this.subject();

  component.setProperties({
    savedOption: { id: 5, name: 'Thing '},
  });

  this.$();
  this.$('button').click();

  assert.notExists(this.$('button'), 'The thing disappears');
});

And the exception is raised.

Further, this can have the side effect of not tearing down the test correctly, so that the following test raises a Assertion Failed: You cannot use the same root element (#ember-testing) multiple times.

An example repo is here:
https://github.com/thec0keman/action-input-bug

This is using Ember QUnit 0.4.1.

@dgeb - You are the most knowledgeable on these changes in Ember itself. What changes are needed here to accommodate them?

QUnit 2 passes assert as an argument to theses callbacks:

QUnit.module( "router", {
    beforeEach: function( assert ) {
        this.router = new Router();
    },
    afterEach: function( assert ) {
        this.router.destroy();
    }
});

However TestModule is not passing these arguments to the user's callbacks from setup, teardown to invokeSteps

Using Ember 1.13.2 and Ember Data 1.13.2 I get deprecation message when running http://localhost:4200/tests

DEPRECATION: DS.FixtureAdapter has been deprecated and moved into an unsupported addon: https://github.com/emberjs/ember-data-fixture-adapter/tree/master
at Ember.defineProperty.get (http://localhost:4200/assets/vendor.js:86516:19)
at exports.default.TestModule.default.extend.setupModel (http://localhost:4200/assets/test-support.js:2151:53)
at nextStep (http://localhost:4200/assets/test-support.js:2280:53)
at tryCatch (http://localhost:4200/assets/vendor.js:65295:14)
at invokeCallback (http://localhost:4200/assets/vendor.js:65310:15)
at http://localhost:4200/assets/vendor.js:67095:40
at http://localhost:4200/assets/vendor.js:42094:7
at Queue.invoke (http://localhost:4200/assets/vendor.js:11455:16)
at Object.Queue.flush (http://localhost:4200/assets/vendor.js:11519:11)

Seems to be at line 21 of https://github.com/switchfly/ember-test-helpers/blob/master/lib/ember-test-helpers/test-module-for-model.js.

More specifically, if I re-run a standard generated 'it exists' unit test on a model through specific url such as http://localhost:4200/tests?testId=50b08f2a, then I also see the deprecation.

cc @dgeb

See this issue on ember.js: emberjs/ember.js#10840

Ember has deprecated all use of Ember.View, which is used in (at least) component integration test setup.

I can probably work on this later today.

Right now if you call this.set() or this.setProperties() in an integration test, it returns undefined. Can we set it up to return the passed in value instead? This would make it consistent with the methods of the same name on Ember objects.

Will open a PR if this sounds reasonable.

My automated builds just started failing with ember-mocha 0.8.2 + ember-test-helpers 0.5.9. Since that upgrade was the only change in ember-mocha 0.8.2, I'm filing this here. Test failures were consistent, but seemingly arbitrary:

Error: Attempting to inject an unknown injection: `service:currentRoute`
Error: No model was found for 'current-answer'
Error: No model was found for 'profile-photo'

Let me know if more info would be helpful. I didn't have much time to troubleshoot the framework, I just downgraded (which fixed my build), but this bears more investigation.

Using Ember 1.13.2 and Ember Data 1.13.2 I get this deprecation message when running http://localhost:4200/tests.

DEPRECATION: You tried to look up 'store:main', but this has been deprecated in favor of 'service:store'.
at ember$data$lib$system$container$proxy$$ContainerProxy.registerDeprecation.preLookupCallback (http://localhost:4200/assets/vendor.js:77620:15)
at Object.ember$data$lib$system$container$proxy$$ContainerProxy.aliasedFactory.create (http://localhost:4200/assets/vendor.js:77604:13)
at instantiate (http://localhost:4200/assets/vendor.js:11998:24)
at lookup (http://localhost:4200/assets/vendor.js:11865:17)
at Object.Container.lookup (http://localhost:4200/assets/vendor.js:11797:14)
at http://localhost:4200/assets/test-support.js:2165:30
at Object.Backburner.run (http://localhost:4200/assets/vendor.js:10776:25)
at Object.run (http://localhost:4200/assets/vendor.js:29984:27)
at exports.default.TestModule.default.extend.setupModel.callbacks.subject (http://localhost:4200/assets/test-support.js:2164:35)

Seems to be coming from line 35 of https://github.com/switchfly/ember-test-helpers/blob/master/lib/ember-test-helpers/test-module-for-model.js, but line 27 may also be of interest to this issue.

More specifically I see this deprecation in a standard generated 'it exists' unit model test, at URL such as http://localhost:4200/tests?testId=50b08f2a.

not ok 160 PhantomJS 1.9 - TestLoader Failures tests/unit/components/ui-selectable-item-test: could not be loaded
    ---
        message: >
            'undefined' is not an object (evaluating 'callbacks.needs')
        stack: >
            TypeError: 'undefined' is not an object (evaluating 'callbacks.needs')
                at http://localhost:7357/assets/test-support.js:1937
                at http://localhost:7357/assets/test-support.js:2426
                at http://localhost:7357/assets/test-support.js:2468
                at createModule (http://localhost:7357/assets/test-support.js:1728)
                at describeComponent (http://localhost:7357/assets/test-support.js:1622)
                at http://localhost:7357/assets/my-app.js:69026
                at http://localhost:7357/assets/vendor.js:150
                at tryFinally (http://localhost:7357/assets/vendor.js:30)
                at http://localhost:7357/assets/vendor.js:156
                at http://localhost:7357/assets/test-loader.js:29
                at http://localhost:7357/assets/test-loader.js:21
                at http://localhost:7357/assets/test-loader.js:40
                at http://localhost:7357/assets/test-support.js:14780
        Log: >
    ...

Would it be too much to get a changelog for v0.4.4?

When you do a major API change (like deprecating unit tests), I would expect something more than a patch level version bump. This was a very unpleasant suprise.

I have a very simple component:

{{#if (some-helper-that-relies-on-the-session)}}
  {{#link-to 'index'}}Home{{/link-to}}
{{/if}}

and a very simple test:

componentTest('home-link', 'HomeLinkComponent', {
  integration: true,

  beforeEach: function() {
    App = startApp();
    component = this.subject();
    this.render();
  },

  afterEach: function() {
    Ember.run(App, 'destroy');
    App = null;
  }
});

test('anything, really', function(assert) {
  assert.ok(true);
});

With those three factors together, I get Cannot read property 'recognizer' of undefined and Something you did caused a view to re-render after it rendered but before it was inserted into the DOM.

If I remove the link, the test passes. If I turn off integration: true, the test passes.

In this case, I need integration: true because the helper requires the basic app infrastructure.

The goal for ember-cli is to remove all bower dependencies. See #56

/cc @stefanpenner @chadhietala

Steps to replicate:
Create an ember-cli addon
Create a new file /addon/requests/foo
Create a new unit test /tests/unit/requests/foo

Use moduleFor('requests:foo') // This fails unless you also create /app/requests/foo

With Ember Canary from a couple days ago (2.0.0-canary+f59d716e) something like this works.

test("curly bracket component", function(assert) {
  this.render(hbs`
    {{now-playing}}
  `);
});

Something like this fails.

test("angle bracket component", function(assert) {
  this.render(hbs`
    <now-playing />
  `);
});

The ember resolver throws an error because parsedName.fullNameWithoutType is undefined. The object for parsedName in the resolver looks pretty weird.

There are a lot of pieces in play here: new angle bracket syntax, new component integration tests, and ember-cli-htmlbars-inline-precompile. Hopefully I can find the right home for this bug.