<<< Part 1 – Angular Test Basic Understand Angular unit tests

>>> Part 3 – Angular unit Testing easy start

In the previous article, I had a basic understanding of the structure of the entire test file, and I also wrote a simple test case. Now I have a detailed understanding of Jasmine’s syntax. Let’s look at the simple test case I wrote earlier:

it('should return sum of two', () = > {let result = Convert.sum(1, 2);
    expect(result).toEqual(3);
});
Copy the code

The entire test case code is contained in an IT method:

  • The first argument is a string of description, which describes the purpose of the test case.
  • The second parameter accepts a callback, the specific test execution code;
  • The IT method accepts a value of type number as a third parameter to set setTimaOut to delay code execution.

Ecpectation

The most complex test logic of the entire test case is contained in the second callback, and we can try to parse a test case semantics. In each test case, there is a test expectation, starting with an Expect operator, in which expect(result).toequal (3) is an expectation; An expectation has three parts:

  1. Current value: the value accepted by the Expect function, and the above result is the actual value;
  2. Matcher: Call it a matcher. Each matcher performs a Boolean comparison between the actual value and the expected value. The result of the comparison is the result of the test pass or fail, as in the toEqual method above. In addition, each matcher can be preceded by a negative assertion via a. Not link, such asexpect(result).not.toEqual(3). Provides a comprehensive matcher jasmine, such as not/place/noting/toBeCloseTo/toBeFalse etc, specific refer to the officialAPI, you can also customize matcher according to your own needs.
  3. Expect value: that is, the expected running result.

before & afrer

As part of a component or relative functions do comprehensive testing, we usually written on the tectonic unit tests, such as testing a DOM shows the width and the height and color, we need to construct three unit tests respectively, each test to get the current DOM object, usually this kind of circumstance, repetitive code will appear. In order to prevent appear in the test a lot of repetitive code, jasmine professional provides global beforeEach/afterEach/beforeAll/afterAll method, according to the literal meaning to understand, BeforeEach and afterEach are executed before and afterEach test case execution, while beforeAll and afterAll are executed before and after the entire test combination. Simply modify the convert.spec.ts test code and observe the order in which the above code is executed:

describe('convert util testing', ()=>{
    beforeAll(() => {
        console.log('before all')
    }),
    beforeEach(() => {
        console.log('before each')
    }),
    afterEach(() => {
        console.log('after each')
    }),
    afterAll(() => {
        console.log('after all')
    }),
    it('should return sum of two', () = > {let result = Convert.sum(1, 2);
        console.log('unit spec1');
        expect(result).toEqual(3);
    });
    it('should return a - b', () = > {let result = Convert.sum(1,-1);
        console.log('unit spec2'); expect(result).toEqual(0); })})Copy the code

Output from the console:

this

Also, Jasmine provides the this keyword as a global variable through which variables can be shared in methods such as IT /beforeEach/afterEach. To test this with a simple example, we create the multiplicate. ts and multiplicate.spec. ts files in the arc/app/utils folder, respectively, with the following code:

// multiply.ts
export class Multiply {
    public static multiply(x: number, y:number){
        returnx*y; }}Copy the code
// multiply.spec.ts
import { Multiply } from './multiply';

describe('multiple util testing', ()=>{
    beforeAll(function(){
        this.value = 1;
    });
    it('Any number multiplied by 1 remians the same'.function() {let result = Multiply.multiply(this.value, 3);
        expect(result).toEqual(3);
    });
})
Copy the code

The above code implements a simple multiplication and passes a value through this object. Test 1 * 3 = 3. Run the test code separately and get the following result:

fail

In some cases, some unit tests need to cover the failure of the application, such as testing whether some error messages are displayed. In this case, we can use the fail method to make the test result failing. We make the following changes to the multiply. Spec. ts file above, adding a test error use case:

describe('multiple util testing', ()=>{
    beforeAll(function(){
        this.value = 1;
    });
    it('Any number multiplied by 1 remians the same'.function() {let result = Multiply.multiply(this.value, 3);
        expect(result).toEqual(3);
    });
    it('test error'.function(){
        fail('manually failing')}); })Copy the code

Run the test and the following output is displayed:

The describe of nesting

Multiple layers of describe can be nested within the DESCRIBE method. When the test kinetic energy is complex, the test logic can be well divided by nesting. Also, each describe method has its own scope, and its own global methods or methods remain independent of each other. Make the following changes to the multiply. Spec. ts file above, add child describe and also pass the value through this.value:

describe('multiple util testing', ()=>{
    beforeAll(function(){
        this.value = 1;
    });
    it('Any number multiplied by 1 remians the same'.function() {let result = Multiply.multiply(this.value, 3);
        expect(result).toEqual(3);
    });
    
    // it('test error'.function(){
    //     fail('manually failing')
    // });

    describe('nested inside a second describe'.function(){
        beforeAll(function(){
            this.value = 0;
        });
        it('Any number multiplied by 0 equals to 0'.function() {letresult = Multiply.multiply(this.value, 3); expect(result).toEqual(0); }); })})Copy the code

In the report of the test results, the describe hierarchy is shown by indenting the lines as follows:

xdescribe & xit

In some cases, we need to temporarily disable some test cases, which can be controlled by the X prefix. Xdescribe can disable the entire test unit, including its internal test cases. Xit, on the other hand, can do Disable for each test case. 2. To be deflected. 2. To be deflated.

Making: github.com/sunrun93/ap…

<<< Part 1 – Angular Test Basic Understand Angular unit tests

>>> Part 3 – Angular unit Testing easy start