I have a function in my service as:
logError(message: string, stack: string) {
console.log('LoggingService: ' + message);
}
and I want to test this function test case I am writing are as:
it('should be created', inject([LoggerService], (loggerService: LoggerService) => {
expect(loggerService).toBeTruthy();
}));
it('log error should be called', inject([LoggerService], (loggerService: LoggerService) => {
spyOn(loggerService, 'logError');
expect(loggerService.logError).toHaveBeenCalled();
expect(loggerService.logError).toHaveBeenCalledTimes(1);
}));
Problem is when I run tests and I see code coverage it shows that logError function is not covered and also the console.log statement is not covered.
But when I change my approach from spyOn to call the actual method it says there are no expectations and I am not sure what will be the right expectaion in this case?
Any help on recommended approach is appreciated.
spyOn installs a spy onto a method of an existing object but it doesn't invoke that method. Therefore, after installing the spy on a method, you need to call the method under test, which is supposed to invoke the spied/mocked method.
it('log error should be called', inject([LoggerService], (loggerService: LoggerService) => {
spyOn(console, 'log');
const error = 'abc';
loggerService.logError(...);
expect(console.log).toHaveBeenCalledTimes(1);
expect(console.log)toHaveBeenCalledWith(error);
}));
Related
Trying to access the alias value on the this () Context, I followed the docs from https://docs.cypress.io/api/commands/as#Fixture
In the .then callback the dataExample parameter is filled OK, but on this.example it is undefined.
describe('cy.as and this', function () {
it('Testing cy.as and this', function () {
cy.fixture('example.json').as('example')
.then(function (dataExample) {
cy.log('ACCESSING this, dataExample', this, dataExample);
});
cy.log(`ACCESSING this.example : ${JSON.stringify(this['example'])}`, this);
});
});
The first log outputs the following: with the dataExample correctly filled, but the contex.example undefined
The second log outside of .then, with this.example also undefined
If I move the cy.fixture line into a beforeEach() it does work. Cold somebody explain this behavior?
describe('alias', () => {
beforeEach(() => {
cy.fixture('example.json').as('example');
});
it('can access all aliases as properties', function () {
expect(this['example']).not.to.eq(undefined); // true
cy.log('THIS', this); // curious => [0]: Context {_runnable: undefined, test: undefined, example: undefined}
cy.log('THIS.example', this['example']); // {name: 'Using fixtures to represent data', email: 'hello#cypress.io',
// body: 'Fixtures are a great way to mock data for responses to routes'}
});
});
Cypress commands are asynchronous. Cypress does not execute a command immediately, it just puts one into a queue to be executed lately. So any command inside a single block of code will not be executed in this block. And the other block of code means any of this:
other it test
before/beforeAll/after/afterAll hooks
then/should callback
So if you want to use a value from a cypress command inside the same it test, you have to use a then callback in order to give Cypress time to execute the command.
If you use a cypress command in a beforeEach hook, the command will be executed by the time when it code starts.
A helpful way to think of the flow is that there are two passes:
first pass, runs the javascript of the test and executes plain JS but enqueues Cypress commands (and their callbacks)
second pass executes those commands
So when
cy.log(`ACCESSING this.example : ${JSON.stringify(this['example'])}`, this)
is enqueued in the first pass, the parameter this['example'] is evaluated immediately (value is undefined).
It's not storing the parameter expression to be evaluated in the second pass, which is what most people expect.
But you can defer the parameter evaluation by putting it inside another callback.
cy.then(() => {
// this callback code is enqueued
// so the evaluation of "this['example']" is deferred until the queue is running
cy.log(`ACCESSING this.example : ${JSON.stringify(this['example'])}`, this)
})
Gleb Bahmutov has a blog
How to replace the confusing cy.then command with the less confusing cy.later command
I am a beginner in Jasmine and I was wondering, why the default value for allowRespy is set to false?
I found this answer, where explained that jasmine.spyOn() always returns the first created spy, so I assume that the reason for flag it to prevent usage of mock with state.
I can come out with a simplified example where such a behavior could be problematic:
describe("TestedService", () => {
const testedService = TestBed.inject(TestedService) // configuration is ommited for simplicity
it("calls foo only once", () => {
const fooSpy = spyOn(testedService, 'foo')
testedService.doAction()
expect(fooSpy).toHaveBeenCalledOnce()
fooSpy = spyOn(testedService, 'foo') // creating new spy to check if it will be called for the second time
testedService.doAction()
expect(fooSpy).not.toHaveBeenCalledOnce() // fails the test because it still points to the same spy,that was called few moments later.
})
})
Another, more realistic example of problematic behavior is when you want to reset a spy used in your test by creating a new spy with spyOn function, but instead of it you will not be created and spy with old state will be used.
Example
describe("TestedService", () => {
beforeEach(() => {
TestBed.inject(TestedService) // configuration is ommited for simplicity
spyOn(TestedService, 'foo').and.returnValue(100)
})
....
it('tests TestedService behavior when foo returns undefined', () => {
spyOn(TestedService, 'foo') // expect it to set spy return value to undefined,
but it don't, so the test below does not tests behavior when foo returns undefined
.....
})
})
Other examples and corrections would be appreciated!
I want to know how the "spyOn" function works internally. I read that the 'spyOn' function internally replaces the implementation of the function being spied on. Does it keep the old functionality?
As an example, suppose I wanted to spy on an object that sends data to a server.
describe("A spy", function() {
var object;
spyOn(object, 'sendDataToServer');
object.sendDataToServer('Some Message');
});
In this case, does the message still get sent to the server or does the spy mock it?
The message does not get sent to the server. The way you defined the spy, it will replace the sendDataToServer function whenever it is called in the context of your test case.
You can specify a more elaborate spy, for example when you want to call another function instead:
let mySpy = spyOn(object, 'sendDataToServer').and.callFake((message: string) => {
console.log('I have been called with ' + message);
});
object.sendDataToServer('Some Message'); // -> will call the function defined above and log the message passed
Or if you want to call the actual function:
let mySpy = spyOn(object, 'sendDataToServer').and.callThrough();
object.sendDataToServer('Some Message'); // -> will call the actual function on object
I am currently writing some tests in a legacy system and am confused about a test result here.
I have one test here which fails as expected but mocha shows as a result 1 passing and 1 failing.
I am using Bluebird Promises, mocha, chai-as-promised and sinon with sinon-chai for spies and stubs. This is the test (I have removed stuff not needed for understanding my problem):
describe("with a triggerable activity (selection)", function () {
beforeEach(function stubData() {
stubbedTriggerFunction = sinon.stub(trigger, "newParticipation");
activityLibStub = ... // stub
selectionLibStub = ... // stub
fakeActivities = ... // simple data with just ONE element
fakeSelection = ... // simple data with just ONE element
// stub methods to return synthetic data
activityLibStub.returns(new Promise(function (resolve) {
resolve(fakeActivities);
}));
selectionLibStub.withArgs(1).returns(new Promise(function (resolve) {
resolve(fakeSelection);
}));
});
afterEach(function releaseStubs() {
// restore stubs...
});
it("should call the newParticipation function", function () {
var member = memberBuilder.buildCorrect();
trigger.allActivities(member)
.then(function () {
return expect(stubbedTriggerFunction).to.not.have.been.called;
})
.done();
})
});
This test fails as expected, because the function is actually invoked. However, mocha tells me that one test passed and one test failed. This is the only test I have implemented in this module.
I am pretty sure this has something to do with the promises but I don't seem to figure out what it is. Also if I add
.catch(function(){
chai.assert.fail();
})
after the then-block, mocha still claims that one test passed. The method is also just invoked one time and I have only one synthetic dataset which I am working with. So I don't see what it is which tells mocha that this has passed while failed...
Any ideas?
Regards, Vegaaaa
Return your promise, return your promise, return your promise. Let's chant it all together now "Return, yoooooooour promise!"
it("should call the newParticipation function", function () {
var member = memberBuilder.buildCorrect();
return trigger.allActivities(member)
.then(function () {
return expect(stubbedTriggerFunction).to.not.have.been.called;
});
})
});
I've also removed .done() because that's not generally useful with Bluebird and would be downright harmful here. Mocha still needs to use your promise.
(It's use is generally discouraged, see here.) If you do not return your promise, then Mocha treats you test as synchronous and most likely that's going to be successful because your test is not really testing anything synchronously. Then if you get an asychronous failure, Mocha has to decide what failed exactly and will do its best to record the failure but it can lead to funny things like having an incorrect number of tests or the same test being reported as failed and successful!
In my journey towards TDD, I am using Mocha, chai and sinon.
There certainly is a learning curve there.
My goal is to write a test to verify that method4 was executed. How do I achieve that ?
//MyData.js
class MyData {
constructor(input) {
this._runMethod4 = input; //true or false
this.underProcessing = this.init();
}
method1() { return this.method2() }
method2() {
if (this._runMethod4) {
return this.method4();
} else {
return this.method3();
}
method4(){
return thirdPartyAPI.getData();
}
method3(){
return someAPI.fetchData();
}
init(){
return this.method1();
}
}
MyData.spec.js
describe('MyData', () => {
it('should execute method 4', function() {
let foo = new MyData(true);
foo.underProcessing.then(()=>{
// How do I verify that method4 was executed ??
expect(foo.method4.callCount).to.equal(1);
});
});
})
Here's an example:
const expect = require('chai').expect;
const sinon = require('sinon');
const sinonTest = require('sinon-test');
sinon.test = sinonTest.configureTest(sinon);
sinon.testCase = sinonTest.configureTestCase(sinon);
describe("MyData", () => {
it("should execute method 4", sinon.test(function() {
let spy = this.spy(MyData.prototype, 'method4');
let foo = new MyData(true);
return foo.underProcessing.then(() => {
expect(spy.callCount).to.equal(1);
});
}));
});
As an additional requirement, I added sinon-test because it's really useful to help clean up spies/stubs after the test has run.
The main feature is this line:
let spy = this.spy(MyData.prototype, 'method4');
This replaces MyData.prototype.method4 by a Sinon spy, which is a pass-through function (so it calls the original) that will record how exactly it was called, how often, with what arguments, etc. You need to do this before the instance is created, because otherwise you're too late (the method might already have been called through the chain of method calls that starts with this.init() in the constructor).
If you want to use a stub instead, which is not pass-through (so it won't call the original method), you can do that as well:
let spy = this.stub(MyData.prototype, 'method4').returns(Promise.resolve('yay'));
So instead of calling thirdPartyAPI.getData() and returning its result, method4 will now return a promise resolved with the value yay.
The remaining code should speak for itself, with one caveat: an explicit return in front of foo.underProcessing.then(...).
I assume that foo.underProcessing is a promise, so it's asynchronous, which means that your test should be asynchronous as well. Since Mocha supports promises, when you return a promise from a test, Mocha will know how to deal with it properly (there's an alternative method of making an asynchronous test with Mocha, involving callback functions, but when you're testing promise-based code you shouldn't really use those since it's easy to run into timeouts or swallowed exceptions).