神刀安全网

#2 Testing with Jasmine – behaviors

Last time I did a short introduction to Jasmine testing – if you are new to JavaScript unit testing, I advise you to read that post first. Today I will continue this subject and will write more about the interface which is really helpful in testing behaviors.

Behavior-driven development

As stated in the official documentation of the Jasmine framework, it’s a “ behavior-driven development framework for testing JavaScript code. But what does ”behavior-driven” mean? Let’s see the definition from techopedia :

Behavior driven development (BDD) is a software development approach that relies on interactions between different layers of stakeholders, the output of such interactions and how these interactions lead to software development. BDD focuses and associates behavioral specifications with each unit of software under development.

As you can see, this applies not only to tests but to development in general. In this approach we define behaviors of the application and then implement them. Jasmine framework is based on this approach and even provides an appropriate interface to make defining these behaviors easier.

Testing behaviors using Jasmine framework

Jasmine uses the BDD approach to define tests. This means that we write tests which describe expected behaviors of the application well. Let’s see the simplest example of a test:

describe("A car", () => {   const car = new Car();    it("has four wheels", () => {     expect(car.wheelCount).toEqual(4);   }); });

Every test in Jasmine starts from the global function describe . It gets two parameters: the first is a description of what we want to test – it should answer the question “who?, what?”; the second parameter is a callback function which is an implementation of the test suite (a test suite is a group of tests which are somehow related).

Inside the spec we call the it function. It is a particular test spec ification (called spec in Jasmine). The it function also gets two parameters – the first is a description of the expected behavior . If we now concatenate a test suite description (given before in the describe function call) with the spec description we should get a full sentence. In our example we have:

A car has four wheels

This describes very well what we want to test and what we expect…

Now, let’s have a look at the second parameter of the it function. Again, it’s just a callback function which implements the spec. This is the place where we should add our assertions. To do so, we can use the expect function which gets a tested value as a parameter. Next, using a provided, fluent interface, we call another function ( toEqual in this case) which gets an expected value. This is also similar to a normal sentence:

expect wheel count to equal 4

The toEqual function is called a “matcher” in Jasmine. I will write more about matchers in the next post.

Conditional behaviors

Test suites/groups can be nested. This can be used to write expectations which only occur in some circumstances. I think an example will be really helpful in this case:

describe('A car', () => {   const car = new Car();     it('have four wheels', () => {     expect(car.wheelCount).toEqual(4);   });     describe('when you press a gas pedal', () => {     car.pressGas();       it('is moving', () => {       expect(car.isMoving).toBe(true);     });   }); });

As you can see, we still have a test suite related to the car object. We expect that it always has four wheels. But we also expect that the car is moving only if the gas pedal is pressed. To test this, we nested a test suite related to the situation when the gas pedal is pushed inside the “car” test suite.

You may notice that this nested test can still be written as a sentence (of course, punctuation marks are omitted):

A car when you press a gas pedal is moving

Simple, right? I think this approach is really helpful when you are not sure what you actually want to test. This way you can write down all expected behaviors of your application by writing a structure of empty describe and it functions. Then, it is easier to mock suitable objects and write appropriate assertions.

Summary

I hope it’s now clear how the behavior-driven development approach works with Jasmine. In the next post I will write something about available matchers. I will also show you the methods to do the test preparation and cleanup, as well as methods to disable and pause tests! Stay tuned! 😉

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » #2 Testing with Jasmine – behaviors

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
分享按钮