emberjs / ember-test-helpers Goto Github PK
View Code? Open in Web Editor NEWTest-framework-agnostic helpers for testing Ember.js applications
License: Apache License 2.0
Test-framework-agnostic helpers for testing Ember.js applications
License: Apache License 2.0
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.
Glimmer adds/requires a few additional items to the default application registry. We need to account for that here.
Will be fixing soon.
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?
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.
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
?
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
Works: moduleForComponent('pie-chart');
Works: moduleForComponent('pie-chart', 'PieChartComponent', {});
Errors: moduleForComponent('pie-chart', 'PieChartComponent');
'undefined' is not an object (evaluating 'callbacks.needs')
/cc @sbl
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)
Upgrade path to using the new attrs
hash is difficult...
this.render
:this.render
:didInitAttrs
hasn't been called.didInitAttrs
but this only works if you actually have a function called didInitAttrs
)Apologies if this is the wrong repo.
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 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?
Ember.View
, which is (soft-)removed since beta.3ember-data#canary
because ember-data < 2
uses ArrayPolyfills
I'm cooking up a PR to fix this. Help is definitely welcome.
I have a component that yields block-params. That is, its template has {{yield something}}
and it is used like
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.)
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.
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?
See this issue on ember.js: emberjs/ember.js#10840
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
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.
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.
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.
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.
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.
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.
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
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.
@dgeb - You are the most knowledgeable on these changes in Ember itself. What changes are needed here to accommodate them?
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
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
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: >
...
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
The goal for ember-cli is to remove all bower dependencies. See #56
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...
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.
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.
Definitely not failing the build for missing semi-colons, and possibly not running and failing the build in general.
The isolated-container depends on a private view: Ember._MetamorphView
This private view is no longer available as of this PR emberjs/ember.js#10670
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.
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);
});
}
);
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 athis.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
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.
Integration tests seem to be throwing errors when services are implicitly injected into the object being tested. IE: foo: Ember.inject.service()
.
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.
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 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.
cc @dgeb
I have a very simple component:
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 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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.