I started using Jasmine to test, angularjs, but soon I started wondering which of the approach is good, and why ? I chose the single expect per spec. I liked it because a non-techie can understand it better, well, that is the point of BDD ,is not it ? For example
describe('Testing multple expect per spec My Service', function() {
beforeEach(/* some stuff*/);
it('test part ',function(){
expect('part 1').toBe('part one'); //
expect('part 2').toBe('part two'); // some crazy stuff, just for example
}
}
describe('Testing single expect per spec My Service', function() {
beforeEach(/* some stuff*/);
it('test part one ',function(){
expect('part 1').toBe('part one'); // just for example
}
it('test part two ',function(){
expect('part 2').toBe('part two'); // just for example
}
}
But soon got into trouble, I realized that the beforeEach is actually reseting/ creating a new object of my service ( not shown in the above example) thus the encapsulated behavior is not reflecting correctly.
For example, I am testing the firstMethod() part of a injected service which changes a data structure of the service, 'test part one', then in the second spec i am testing the secondMethod() which tests the change data structure in the 'test part two'. But due to the fact that beforeEach re-injected my service, the 'test part two' fails. How can I get around such situation ?
Please help Jasmine newbie here.
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is the title of the spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code.
You can have more than one describe per file. describe and context are synonyms and can be used interchangeably.
Just like suites, you can also exclude individual specs using the xit() function which temporary disables the it() spec and marks the spec as pending.
We use the Jasmine-provided it function to define a spec. The first parameter of it is a text description of what the spec will be testing — in this case we have a defined component. The second parameter is a function that will run the test. We then use Jasmine's expect function to define our expectation.
Your unit tests should be independent of each other. Otherwise, if Test 2 fails, you don't know if there is a problem in Method 2, or if there is a problem with the setup that was done in Method 1.
To handle this situation, you can do some additional setup at the start of Test 2 where you ensure the service is in whatever state necessary in order to test the logic in Method 2. If multiple tests will require that setup, you can put it in a nested describe
and beforeEach
.
As @ktharsis notes, multiple expects per spec are fine as long as they are verifying the same "behavior". Each test should correspond to one behavior, not necessarily one assert.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With