I'm having a problem where when running my Ember tests. Once in every 3-5 tries it hits errors before running any tests. When I run in server mode I can see this output:
ReferenceError: Can't find variable: EmberENV at http://localhost:7357/3256/tests/index.html?hidepassed, line 42
ReferenceError: Can't find variable: define at http://localhost:7357/assets/test-loader-53146f185443881bff29aab3e80079e2.js, line 3
ReferenceError: Can't find variable: define at http://localhost:7357/assets/tests-a72d35574ec0d1ab014d4af21210a23a.js, line 1
When I look at the offensive files referenced, they looks like this:
/* globals requirejs, require */
(function() {
define("ember-cli/test-loader",
[],
function() {
"use strict";
var moduleIncludeMatchers = [];
var moduleExcludeMatchers = [];
function addModuleIncludeMatcher(fn) {
moduleIncludeMatchers.push(fn);
};
etc...
As I understand, define() is a function introduced by requirejs, so it seems like it's just not loading before the tests begin. Any idea why this would be, and if there is any way to ensure things are loaded in the proper order?
Other important things; this doesn't seem to be an issue with the individual tests, as deleting them, especially the first which would be hit doesn't make a difference. This looks like it started happening occasionally after a big check in, where among other things, we went from 130 to 174 tests, but nothing particularly strange seems to have been introduced. I've also tried cutting out pieces of the new code with no change, BUT if I revert to the previous version it seems to still work correctly every time. It could just be a matter of the codebase growing larger.
For versions of dependencies:
EmberCLI: 1.13.13
node: 5.4.1
PhantomJS: 2.1.1
Anything else that would be helpful to provide? Thanks.
Forgot to report back here that it has been fixed in my case.
First of all this issue was reported here: https://github.com/ariya/phantomjs/issues/14173, and it's likely caused by some inline import #import url(...) used in css.
The fix in my case is to write an alternative test runner which ignore the network request, similar to what #wagenet suggested in the above issue.
Hopefully that works for other use cases.
We had the same issue and were able to fix it by updating qunit to 1.20.0 in bower.json
"qunit": "~1.20.0",
Related
Having a hard time finding out where a helper not in app/helpers is defined. The helper was very generically named, I searched my package.json for the helper name but there was nothing. I was stuck hunting around with google to try and figure out what addon defined it.
Given some helper ({{totally-generic-name param1="foo"}}) how would one go about finding where it's defined?
(I happen to be on Ember 2.13)
(Note: the helper was contains defined in ember-composable-helpers, so it would have been a LITTLE helpful to search package.json for "helper" but that is a pretty tedious in-direct way of searching, which have may not even yielded the answer)
For me the easiest way is to run a development build of your application (ember serve), open development tools of your browser and open a file called <your-app-name>/helpers/<helper-name>.js. In the first line of the file, you see from where it is imported.
Let's assume your application name is foo and you have installed ember-array-helper. Run your application via ember serve and open it in Chrome. Go to development tools Source section. Search for helpers/array.js in subsection Network. You could search for a file per name via ctrl+p. If the helper is provided by an addon this file is autogenerated. It looks like the following:
define('foo/helpers/array', ['exports', 'ember-array-helper/helpers/array'], function (exports, _array) {
'use strict';
Object.defineProperty(exports, "__esModule", {
value: true
});
Object.defineProperty(exports, 'default', {
enumerable: true,
get: function () {
return _array.default;
}
});
});
In first line your read the name of the import ember-array-helper/helpers/array from which you can guess on the addon name (first part). Note that you could also open the actual helper exported by addon via developer tools by opening /assets/addon-tree-output/ember-array-helper/helpers/array.js. Since the last part is coming from the import, you could easily use that one to search for the file. Now place your breakpoints and inspect this code as much as you like.
The same approach should work in all major browsers.
I have these two Ember integration tests, A and B. (I have a lot more, but in debugging this I have literally removed every other test in order to isolate the problem. There are 9 tests in the same file as A and I commented the other 8.) If A runs before B, B will fail. If B runs by itself, or before A, it will pass.
From this description it seems pretty clear that A is doing something to the test environment that screws up B. After liberally salting the tests and the production code involved with log messages, however, I'm no closer to figuring out what's up, and I'm hoping someone else can spot if there's an obvious issue.
Right now I'm looking closely at the afterEach blocks in both tests. Here's an outline of what the beforeEach and afterEach blocks look like for test A:
beforeEach: function() {
server = new Pretender(function() {
// Pretender setup removed for brevity
});
App = startApp();
},
afterEach: function() {
server.shutdown();
Ember.run(App, App.destroy);
}
That afterEach is pretty much the stock ember-cli code, but it baffles me a bit. The documentation on Ember.run() suggests it should get a function as an argument, but we're not giving it one here, so I'm not sure how that works. And, should the Pretender shutdown() call be inside the Ember.run (or in its own Ember.run)?
The versions, for the record: ember-cli 0.2.0, Ember 1.10.1.
ETA: The issue goes away when I update to ember-cli 0.2.3 and Ember 1.11.3. Now if only I could figure out the other failing tests we have with that update...
Your setup and teardown looks fine. They are commonly used and are properly defined.
However, there is (still) open issue on ember-qunit about not tearing down the app properly - take a look here to see the progress.
As you said, it does not happen in Ember 1.13.
I am using ember-cli and have a problem with selecting the production environment. Specifically, everything works when I run ember serve --environment=development and I get a blank page when I run ember serve --environment=production. In the console, I see:
Uncaught TypeError: undefined is not a function
Uncaught Error: Could not find module simple-auth/authenticators/base
All other things are equal, and all dependencies are up to date. I'm a total noob so I don't even know where to begin on how to debug: is it ember? ember-cli? broccoli? Any help would be appreciated.
I had exact the same problem, and James_1x0 is correct, it is an broccoli issue.
After debugging it occurs, that the "undefined" error apears on "Ember.handlebars.compile" which lead to other research.
It seems, that in production envrironment "handlebars.js" is replaced by "handlebars.runtime.js" in the ember-cli build process, which seem to be a problem for broccoli at this time.
Other devs had the same problem but with other libraries as well:
https://github.com/stefanpenner/ember-cli/pull/675#issuecomment-47431195
Here the solution was to add:
var index = app.legacyFilesToAppend.indexOf('bower_components/handlebars/handlebars.runtime.js');
if(index) {
app.legacyFilesToAppend[index] = 'bower_components/handlebars/handlebars.js';
}
into your Brocfile.js to replace the "handlebars.runtime.js" with the "handlebars.js".
This also fixed the problem for me.
It sure has the drawback that the whole handlebars file is deployed but its a workarround for now, until the problem is fixed.
Solution is mentioned on Ember CLI website:
This is somewhat non-standard and discouraged, but suppose that due to a requirement in your application that you need to use the full version of Handlebars even in the production environment.
Basically, you can pass vendorFiles option to your EmberApp instance which will force CLI to include full version of Handlebars.
Example of explicitly requiring handlebars.js , in Brocfile.js:
var app = new EmberApp({
vendorFiles: {
'handlebars.js': {
production: 'bower_components/handlebars/handlebars.js'
}
}
});
This is recommended way of solving this issue(discussion on GitHub).
I have what I think are standard functional tests set up for the intern and I can get them to pass consistently in several browsers. I'm still evaluating if it makes sense to use the intern for a project so I'm trying to see what happens when tests fail, and currently if I make one test fail, it always seems to cause all the tests in the suite to fail.
My tests look a bit like :
registerSuite({name : 'demo',
'thing that works' : function () {
return this.remote.get('http://foo.com')
.waitForCondition("typeof globalThing !== 'undefined'", 5000)
.elementById('bigRedButton')
.clickElement()
.end()
.eval('jsObj.isTrue()')
.then(function(result){
assert.isTrue(result);
})
.end(); // not sure if this necessary...
},
'other thing that works': function() {
// more of the same
}
});
I'm going to try and debug to figure out this for myself, but I was just wondering if anyone knows if this is expected behaviour (1 test failure causes whole test suite to fail, and report that all tests in suite have failed), or whether its more likely that my set up is wrong and I have bad interactions between the promises or something?
Any help would be awesome, and happy to provide any more info if helpful :)
Thanks!
I ran into the exact same issue a few weeks ago and created a ticket on github for the issue: https://github.com/theintern/intern/issues/46.
It's tagged 'needs-triage' at the moment, I've no idea of what it means.
Is there a way to inject providers when writing unit tests using Karma(Testacular) and Jasmine in angular?
Our team decided recently to use angularjs $log to write debugging details to the console. This way we can leverage the ability to disable the logging via the $logProvider.debugEnabled() method.
angular.module("App", ["prismLogin", "ui.bootstrap"])
.config(["$routeProvider", "$logProvider",
function ($routeProvider, $logProvider) {
$routeProvider
//routes here edited for brevity
//This is the offending line, it breaks several pre-existing tests
$logProvider.debugEnabled(true);
}]);
However after adding the $logProvider.debugEnabled(true); line several of our tests no longer execute successfully, failing with the following message:
TypeError: Object doesn't support property or method 'debugEnabled' from App
So my question again, is it possible to mock the $logProvider? Or should I provide my own configuration block for the test harness?
I attempted searching for a way to mock the app module with no luck. It seems to me that using the concrete app module instead of a mock is very brittle. I would like to avoid reworking tests associated with the app module every time a change is made in the app or run configuration blocks.
The tests that are failing are units of code with no relation to the $logProvider? I feel as if I a missing something here and making things much harder than they should be. How should one go about writing tests that are flexible and are not affected by other side effects introduced in your application?
It appears that this is a know issue with angular-mocks.
Until the issue is addressed , I was able to resolve the issue by adding the following method to the angular.mock.$LogProvider definition in angular-mocks.js at line 295.
this.debugEnabled = function(flag) {
return this;
};