I'm writing a spec that checks a method is called during the config phase of the Angular module under test.
Here's a simplified look at the code being tested:
angular.module('core',['services.configAction'])
.config(function(configAction){
configAction.deferIntercept(true);
});
What happens above is we define a core module that has a single dependency.
Then, in the config-block of the core module, we call the deferIntercept method on the configAction object given to use from services.configAction.
I'm trying to test that core's config calls that method.
This is the current setup:
describe('core',function()
{
const configActionProvider={
deferIntercept:jasmine.createSpy('deferIntercept'),
$get:function(){
return {/*...*/}
}
};
beforeEach(function()
{
module(function($provide)
{
$provide.provider('configAction',configActionProvider);
});
module('core.AppInitializer');
inject(function($injector)
{
//...
});
});
it('should call deferIntercept',function()
{
expect(configActionProvider.deferIntercept).toHaveBeenCalledWith(true);
});
});
The problem with that is that it doesn't override configAction and so the spy is never called, the original method is.
It will do so if I remove it as a dependency of the core module, so angular.module('core',[]) instead of angular.module('core',['services.configAction']) will work and the spy is called.
Any idea how to override services.configAction during testing without removing it from the dependency list?
Have a look at - https://dzone.com/articles/unit-testing-config-and-run.
Something like the following -
module('services.configAction', function (configAction) {
mockConfigAction = configAction;
spyOn(mockConfigAction, 'deferIntercept').andCallThrough();
});
module('core');
in your beforeEach might do the job.
Related
I'm attempting to test that a value is changed to true after a promise is resolved inside $onInit. I'm following, as best I can, the example in this Stack Overflow question/answer. Here is my code:
class TestCtrl {
constructor(SearchService) {
this.testValue = false;
this.SearchService = SearchService;
}
$onInit() {
this.SearchService.getResults()
.then(function () {
this.testValue = true;
});
}
}
TestCtrl.$inject = ['SearchService'];
And here's the test I'm attempting to run (using mocha, chai, sinon):
it('should work', function() {
ctrl = $componentController('test', {
SearchService: SearchService
}, {});
sinon.stub(SearchService, 'getResults').resolves({response:{data: 'data'}});
ctrl.$onInit();
$rootScope.$apply();
ctrl.testValue.should.equal(true);
});
Should I be testing ctrl.testValue inside a then? Also, is using this example a bad idea because that example doesn't use a component with an $onInit lifecycle hook?
From what I've read, no, "don't use expect inside then in tests." But I'm not so sure based on what I've read elsewhere.
I wouldn't be surprised if I'm missing something obvious in how to test promises (maybe a stub wasn't the way to go?) and/or how to test what happens in the $onInit lifecycle hook.
If the question needs more details, please ask and I'll do my best to add them.
Edit: Checkout you $onInit method:
$onInit() {
this.SearchService.getResults()
.then(function () {
// `this` in anonymous function is reffering to window not the controller instance
this.testValue = true;
});
}
$onInit() {
var self = this;
self.SearchService.getResults()
.then(function () {
self.testValue = true;
});
}
Your example is correct
This is the way to test async code in angularjs - it is tested like synchronous code. Stubs' returning promises are resolved when you execute $rootScope.$apply().
Why it doesn't work
The promise returned from stub.resolves() is not an angular promise. It cannot be triggered to resolve using $rootScope, because it's not a part of angular's world. It's promise resolution queue is tied to something else and hence the need to test like you usually test async code.
Angular doesn't depend on JavaScript's native Promise implementation - it uses a light implementation of Q's promise library that is wrapped in a service called $q
The answer you have quoted uses the same service to create and return a promise from a stub
In order for your code to work - to test like you test synchronous code - you should return a $q promise (By wrapping a value in $q.when(value)) calling $rootScope.$apply() will execute the code in the then block, then proceed with the code below $rootScope.$apply() line.
Here is an example:
it('Sinon should work with angular promises', function () {
var resolved = 'resolved';
var promise = $q.when(resolved);
// Our async function
var stub = sinon.stub().returns(promise);
// Callback to be executed after the promise resolves
var handler = sinon.stub();
stub().then(handler); // async code
// The handler will be called only after $rootScope.$apply()
handler.callCount.should.equal(0);
// triggers digest which will resolve `ready` promises
// like those created with $q.when(), $q.resolve() or those created
// using the $q.defer() and deferred.resolve() was called
// this will execute the code inside the appropriate callback for
// `then/catch/finally` for all promises and then continue
// with the code bellow -> this is why the test is considered `synchronous`
$rootScope.$apply();
// Verify the handler was called and with the expected value
handler.callCount.should.equal(1);
handler.should.have.been.calledWith(resolved);
})
Here it is in action test promise synchronously in angular
For starters, you should read up on how Mocha expects you to test async code.
To start out with the quick bits:
You are on the right path - there are just some bits missing.
Yes you should do your test inside a then.
The example you linked to is fine. Just understand it.
There is absolutely no reason to avoid asserting a test inside a then. In fact, it is usually the only way to assert the resolved value of a promise.
The main problem with your test code is it tries to assert the result before it is available (as promises resolve in a later tick, they are asynchronous).
The main problem with the code you are trying to test is that there is no way of knowing when the init function has resolved.
We can deal with #2 by waiting for the stubbed SearchService.getResults to resolve (as we control the stub in the test), but that assumes too much knowledge of the implementation of onInit, so that is a bad hack.
Instead, we fix the code in TestCtrl, simply by returning the promise in onInit:
//main code / TestCtrl
$onInit() {
return this.SearchService.getResults()
.then(function () {
this.testValue = true;
});
}
Now we can simply wait for any call to onInit to resolve before we test what has happened during its execution!
To fix your test we first add a parameter to the wrapping test function. Mocha will see this and pass in a function that you can call when your test finishes.
it('should work', function(done) {
That makes it an async test. Now lets fix the test part:
ctrl.$onInit().then( () => {
ctrl.testValue.should.equal(true);
done(); // signals to mocha that the test is finished ok
}).catch(done); // pass any errors to the callback
You might find also find this answer enlightening (upvote if it helps you out). After reading it you might also understand why Mocha also supports dropping the done callback by returning a promise from the test instead. Makes for shorter tests:
return ctrl.$onInit().then( () => {
ctrl.testValue.should.equal(true);
});
sinon.stub(SearchService, 'getResults').resolves({response:{data: 'data'}}); is not returning a promise. Use $q.
I would suggest doing this:
ctrl = $componentController('test', {
SearchService: SearchService
}, {});
let deferred =$q.defer();
deferred.resolve({response:{data: 'data'}});
sinon.stub(SearchService, 'getResults').resolves(deferred.promise);
ctrl.$onInit();
$rootScope.$apply();
ctrl.testValue.should.equal(true);
You don't need to test ctrl.testValue inside a then. And generally, I would recommend not assert inside .then() in your specs. The specs will not fail if the promise never gets resolved. That can give you a false sense of security when in reality, your tests are not doing anything. But that's just my opinion.
Your test will pass once the stub returns a promise. Ideally, I would recommend using $httpBackend if the service is making an http call.
Cheers.
I'm new to Angular and I'm not quite sure exactly how dependency injection works. My problem is that I have Service A which depends on Service B, but when I inject Service A into my test Service B becomes undefined.
I have seen Injecting dependent services when unit testing AngularJS services but that problem is a bit different than mine.
This Injected Dependencies become undefined in angular service is very similar to my issue but I couldn't translate the JS.
I have also changed my variable names and simplified the code to remove irrelevant lines.
Service.ts
export class ServiceA {
constructor(private $resource: ng.resource.IResourceService, private ServiceBInstance: ServiceB){
}
ServiceAMethod() {
var resources = ServiceBInstance.property; //ServiceBInstance is undefined here
}
}
factory.$inject = [
'$resource'
'ServiceBModule'
];
function factory($resource: ng.resource.IResourceService, ServiceBInstance: ServiceB): IServiceA {
return new ServiceA($resource, ServiceBInstance);
}
angular
.module('ServiceAModule')
.factory('ServiceA',
factory);
Spec.ts
describe('ServiceB', (): void => {
beforeEach((): void => {
angular.mock.module(
'ServiceAModule',
'ServiceBmodule',
'ngResource'
);
});
describe('ServiceAMethod', (): void => {
it("should...", inject(
['ServiceA', (ServiceAInstance: ServiceA): void => {
ServiceAInstance.ServiceAMethod(); //Problem Here
}]));
});
});
The problem I'm having is that when I call ServiceAMethod I get an error which states "TypeError: Cannot read property 'property' of undefined". The weird thing is that $resource is never undefined but my ServiceB is always undefined.
I thought that when I inject ServiceA into my test it should automatically also inject all of its dependencies.
Also note that I am not mocking ServiceB on purpose.
Update
I've also tried to inject an instance of my ServiceB into the it but when I print out the variable it also states that is it undefined, and when I try to to do the code below into the beforeEach
inject(function (_ServiceBInstance_: ServiceB) {
console.log(_ServiceBInstance_);
});
I get and Unknown Provider error.
Ok so after hours of searching I finally found the answer. I forgot to include a file which included Angular's .config method
When creating the provider make sure that you also call .config, here's an example:
angular
.module('ServiceBModule')
.config(['ServiceBProvider', (ServiceBClass) => { //Very Important
//Code here
}])
.provider('ServiceB', ServiceB);
In my unit tests, I want to inject certain modules, and I want the beforeEach hook to be asynchronous. Basically, I'm looking for something like this:
beforeEach(inject(function(_$rootScope_, _$compile_, done) {
...
}));
However, this doesn't work, because Karma complains that there is no provider called doneProvider. Basically, it's trying to look up a provider for anything inside inject.
Done typically gets inserted in the beforeEach hook like this:
beforeEach(function(done) {
...
});
But how can I inject what I need and still have the beforeEach be asynchronous?
I also tried placing an injector function inside the beforeEach:
beforeEach(function(done) {
inject(function(_$rootScope_, _$compile_) {
...
done();
});
});
But the test times out when I do this. For some reason, it seems that done cannot be called inside the inject callback. When I place the call to done outside the inject function, the stuff I am injecting never gets set.
Any ideas?
Solution is pretty simple;
beforeEach(inject(function(_$injector_) {
$injector = _$injector_;
}));
beforeEach(function (done) {
setTimeout(function () {
console.log('Got injector: '+$injector);
done();
}, 100);
});
SetTimeout is example of async task. You can put there yours. So just do not do any async job inside on inject and it will be fine.
Then you use $injector.get('$modal') or whatever you need.
I have a project using AngularAMD/RequireJS/Karma/Jasmine, that I have the basic configuration all working, most unit tests run and pass successfully.
I cannot get a mocked service injected correctly using either angular.mock.module or angularAMD.value().
I have:
// service definition in services/MyService.js
define(['app'],
function(app) {
app.factory('myService', [ '$document', function($document) {
function add(html) {
$document.find('body').append(html);
}
return { add: add };
}]);
}
);
// test
define(['angularAMD', 'angular-mocks', 'app', 'services/MyService'],
function(aamd, mocks, app) {
describe('MyService', function() {
var myBodyMock = {
append: function() {}
};
var myDocumentMock = {
find: function(sel) {
// this never gets called
console.log('selector: ' + sel);
return myBodyMock;
}
};
var svc;
beforeEach(function() {
// try standard way to mock a service through ng-mock
mocks.module(function($provide) {
$provide.value('$document', myDocumentMock);
});
// hedge my bets - try overriding in aamd as well as ng-mock
aamd.value('$document', myDocumentMock);
});
beforeEach(function() {
aamd.inject(['myService',
function(myService) {
svc = myService;
}]);
});
it('should work', function() {
// use svc expecting it to have injected mock of $document.
spyOn(myDocumentMock, 'find').andCallThrough();
spyOn(myBodyMock, 'append');
svc.add('<p></p>');
expect(myDocumentMock.find).toHaveBeenCalledWith('body');
expect(myBockMock.append).toHaveBeenCalledWith('<p></p>');
});
});
}
);
Does anyone know where I'm going wrong ? Any help would be much appreciated.
Angular isn't asynchronous, I think is not a good ideia use both. If you're trying to reach to a good modularization method, okay, but use the RequireJS optimizer to build everything before you put this on your browser, and about the tests, I think you can just use RequireJS optimizer to build your modules before, it will let you free from "CommonJS environment even in tests".
Looks like it'll be an issue with variable scopes, karma is very finicky about that. I think you should initialize your mock objects globally, then set them in the beforeEach.
The top line of my test files always looks something like:
var bodyMock, svcMock, foo, bar
Then in the beforeEach'es I set the values
Edit: Since bodyMock is only a scope variable, at the point where the tests are actually running and the browser is looking for an object 'bodyMock', it can't find anything.
I have a decorator in Angular that is going to extend the functionality of the $log service and I would like to test it, but I don't see a way to do this. Here is a stub of my decorator:
angular.module('myApp')
.config(function ($provide) {
$provide.decorator('$log', ['$delegate', function($delegate) {
var _debug = $delegate.debug;
$delegate.debug = function() {
var args = [].slice.call(arguments);
// Do some custom stuff
window.console.info('inside delegated method!');
_debug.apply(null, args);
};
return $delegate
}]);
});
Notice that this basically overrides the $log.debug() method, then calls it after doing some custom stuff. In my app this works and I see the 'inside delegated method!' message in the console. But in my test I do not get that output.
How can I test my decorator functionality??
Specifically, how can I inject my decorator such that it actually decorates my $log mock implementation (see below)?
Here is my current test (mocha/chai, but that isn't really relevant):
describe('Log Decorator', function () {
var MockNativeLog;
beforeEach(function() {
MockNativeLog = {
debug: chai.spy(function() { window.console.log("\nmock debug call\n"); })
};
});
beforeEach(angular.mock.module('myApp'));
beforeEach(function() {
angular.mock.module(function ($provide) {
$provide.value('$log', MockNativeLog);
});
});
describe('The logger', function() {
it('should go through the delegate', inject(function($log) {
// this calls my mock (above), but NOT the $log decorator
// how do I get the decorator to delegate the $log module??
$log.debug();
MockNativeLog.debug.should.have.been.called(1);
}));
});
});
From the attached plunk (http://j.mp/1p8AcLT), the initial version is the (mostly) untouched code provided by #jakerella (minor adjustments for syntax). I tried to use the same dependencies I could derive from the original post. Note tests.js:12-14:
angular.mock.module(function ($provide) {
$provide.value('$log', MockNativeLog);
});
This completely overrides the native $log Service, as you might expect, with the MockNativeLog implementation provided at the beginning of the tests because angular.mock.module(fn) acts as a config function for the mock module. Since the config functions execute in FIFO order, this function clobbers the decorated $log Service.
One solution is to re-apply the decorator inside that config function, as you can see from version 2 of the plunk (permalink would be nice, Plunker), tests.js:12-18:
angular.mock.module('myApp', function ($injector, $provide) {
// This replaces the native $log service with MockNativeLog...
$provide.value('$log', MockNativeLog);
// This decorates MockNativeLog, which _replaces_ MockNativeLog.debug...
$provide.decorator('$log', logDecorator);
});
That's not enough, however. The decorator #jakerella defines replaces the debug method of the $log service, causing the later call to MockNativeLog.debug.should.be.called(1) to fail. The method MockNativeLog.debug is no longer a spy provided by chai.spy, so the matchers won't work.
Instead, note that I created an additional spy in tests.js:2-8:
var MockNativeLog, MockDebug;
beforeEach(function () {
MockNativeLog = {
debug: MockDebug = chai.spy(function () {
window.console.log("\nmock debug call\n");
})
};
});
That code could be easier to read:
MockDebug = chai.spy(function () {
window.console.log("\nmock debug call\n");
});
MockNativeLog = {
debug: MockDebug
};
And this still doesn't represent a good testing outcome, just a sanity check. That's a relief after banging your head against the "why don't this work" question for a few hours.
Note that I additionally refactored the decorator function into the global scope so that I could use it in tests.js without having to redefine it. Better would be to refactor into a proper Service with $provider.value(), but that task has been left as an exercise for the student... Or someone less lazy than myself. :D