Ember CLI Test Helpers - ember.js

Can somebody point me to a resource on how to implement a test helper with ember-cli?
Or else a simple explanation?
I know the helpers go in the test/helpers directory, but how do you load them into the integration tests?
Thanks

The only way I found to do this is:
// tests/helpers/controller.js
import Ember from 'ember';
Ember.Test.registerHelper('controller', function (app, name) {
return app.__container__.lookup('controller:' + name);
});
then in my acceptance test:
// acceptance/index-test.js
import Ember from 'ember';
// import our helper (this might be done within helpers/start-app.js to always import all helpers)
import '../helpers/controller';
import startApp from '../helpers/start-app';
// your tests using the helper(s)
But there might be some better way of doing.

Related

Integration test rendering process - EmberJS

I'm writing an integration test for one of my addon components. I've also linked it to a sibling project using npm link:
.. projects/
.... my-project/
.... my-linked-project/
I use one of the my-linked-project mixins in the my-project component in question.
//my-project/addon/components/my-component/component.js
import Ember from 'ember';
import ExternalMixin from 'my-linked-project/mixins/foo'
export default Ember.Component.extend(ExternalMixin, {
...
}
This runs fine with the application running, but seems to hit some issues when I render it in my integration test.
//my-project/tests/integration/components/my-component-test.js
import { moduleForComponent, test } from 'ember-qunit';
import hbs from 'htmlbars-inline-precompile';
moduleForComponent('my-component', 'Integration description', {
integration: true
}
test('should render', function() {
this.render(hbs`{{my-component}}`);
}
However I get Error: Could not find module 'my-linked-project/mixins/foo'.
Where can I read more about what happens when render / hbs are called?
Could the issue be the location of the test file, which can't find the external linked project?
It's worth removing the npm link from tech equation temporarily to see if that's causing your problems. What you have there looks fine ...

Unit test for helpers Ember-cli

When I create a new helper on Ember CLI, a test is created inside tests/unit/helpers. I would like to know how to test this helpers using the unit test?. I tried to find a documentation, but nothing helps. I need to test the function createArray in order to pass the test coverage to a 100%.
Now, this is my helper:
import Ember from 'ember';
export function createArray(array) {
return array;
}
export default Ember.Helper.helper(createArray);
This is my unit test: tests/unit/helpers/create-array-test.js
module('Unit | Helper | create array');
// Replace this with your real tests.
test('it works', function(assert) {
let result = createArray([42]);
assert.ok(result);
});
Hope someone can guide me.
What version of Ember CLI are you using? The blueprint should generate a test file with an import of the named export so you can use it directly.
What export function createArray does is create a named export named createArray. This means you can import the function directly and use it like you a normal function:
import { createArray } from 'app-name/helpers/create-array'
createArray(arrayOfArguments);
I modified #ykaragol's Twiddle to demonstrate how to do this in a test:
import { createArray } from 'app-name/helpers/create-array';
import { module, test } from 'qunit';
module('Unit | Helper | create array');
test('it works', function(assert) {
let result = createArray([42]);
assert.ok(result);
});
Replace app-name with the name of your application.
The code posted on twiddle helped me understand how to solve the helpers unit test. This is how I tested it, and it works like a charm.
test('Return the argument is passed', function(assert) {
assert.ok(createArray([8,4,5,6]));
assert.ok(createArray(['test1','test2','test3']));
});

Ember Addon: writing unit tests for files in my addon folder

I am writing an Ember Addon that provides some services that are not exposed through the app/ folder.
// project Foo
// addon/services/foo.js
import Ember from 'ember';
export default Ember.Service.extend({})
The unit test that gets generated by Ember CLI uses moduleFor helper.
// tests/unit/services/foo.js
import { moduleFor, test } from 'ember-qunit';
moduleFor('service:foo', 'Unit | Service | foo', {
// Specify the other units that are required for this test.
// needs: ['service:foo']
});
// Replace this with your real tests.
test('it exists', function(assert) {
let service = this.subject();
assert.ok(service);
});
Problem is that since my FooService is not exposed through the app/ folder, moduleFor helper cannot find it using service:foo name.
What would be the best way to unit test my service here?
I can see three possibilities:
1) add tests/dummy/app/services/foo.js that exports FooService
// tests/dummy/app/services/foo.js
export { default } from 'foo/services/foo.js';
2) create initializers in the dummy app that registers service:foo
// tests/dummy/app/initializers/account-data.js
import FooService from 'foo/services/foo'
export function initialize(application) {
application.register('service:foo', FooService);
}
EDIT
turns out I can't do this. it's not that moduleFor helper is trying to find 'service:foo' but trying to register 'app/services/foo' as 'service:foo'. So registering 'service:foo' ahead of the time does not help.
3) don't use moduleFor helper.
EDIT
By this I meant something like what #Andy Pye's answer. But it would be nice to be able to use moduleFor helper... Especially for models since I need access to store.
EDIT
turns out it gets more complicated for models since I can't create them directly. So if I go with not using moduleFor helper, I need an instead of store object...
I've just had the same (or a very similar) issue. I've found that this seems to work:
// tests/unit/services/foo.js
import { module, test } from 'ember-qunit';
import FooService from 'Foo/services/foo';
module('Unit | Service | foo', {
// Specify the other units that are required for this test.
// needs: ['service:foo']
});
// Replace this with your real tests.
test('it exists', function (assert) {
let service = FooService.create();
assert.ok(service);
});

Invoke custom ember helper in code

I have a custom helper 'myHelperFunction' and I want to call the method in code, how can i do that?
import Ember from 'ember';
export function myHelperFunction(params) {
return myData;
}
export default Ember.Helper.helper(myHelperFunction);
My solution was:
my-function.js (Helper)
import Ember from 'ember';
export default Ember.Helper.helper(function(params) {
...
return myData;
});
and then:
import myFunction from '../helpers/my-function';
...
myFunction.compute([param1, param2])
...
You have to import it using import keyword in file where you want to use it:
import myHelperFunction from '../helpers/my-helper-function';
let result = myHelperFunction();

How does Ember-cli know where to import 'ember-data' from

Ember-cli uses ES6 syntax to import modules.
This is how you import Ember-Data:
import DS from 'ember-data'
How does Ember-cli know where to import Ember-Data from? This case doesn't seem to fit the naming conventions explained in Using Modules and the Resolver docs. (Or maybe I'm missing something.)
The ‘ember-cli-ember-data’ node module adds ember-data to the generated Ember CLI output (via vendor.js). If you look at this module’s index.js, in the EmberCLIED.prototype.included function, you will see the following references to ember-data in the vendor directory:
EmberCLIED.prototype.included = function included(app) {
this.app = app;
var options = {
exports: {
'ember-data': [
'default'
]
}
};
if (this.app.env === 'production') {
this.app.import('vendor/ember-data/ember-data.prod.js', options); // <--
} else {
this.app.import('vendor/ember-data/ember-data.js', options); // <--
}
};
That’s how Ember CLI knows where to find ember-data.
The bit 'ember-data' refers to, in the case of a base install of Ember-CLI vendor/ember-data/ember-data.js.
This is exactly the same as: import Ember from 'ember'; which refers to vendor/ember/ember.js.
What you call it in the import doesn't matter. That is just a reference to what you are importing.