In the title of it we in a human-readable way describe the particular use case, and the second argument is a function that tests it. Such description is called a specification or, in short, a spec, and contains descriptions of use cases together with tests for them, like this:Ī spec has three main building blocks that you can see above: describe('title', function() ) That task is just an example: there’s the ** operator in JavaScript that can do that, but here we concentrate on the development flow that can be applied to more complex tasks as well.īefore creating the code of pow, we can imagine what the function should do and describe it. Let’s say we want to make a function pow(x, n) that raises x to an integer power n. To understand BDD, we’ll examine a practical case of development. Let’s start with a technique named Behavior Driven Development or, in short, BDD.īDD is three things in one: tests AND documentation AND examples. They run our functions in various ways and compare results with the expected.

So it becomes easy to fix one thing and break another one.Īutomated testing means that tests are written separately, in addition to the code. But it’s hard to expect a programmer to check all of them manually after every change. When we develop something, we keep a lot of possible use cases in mind.

Looks complete? But we forgot to re-test f(1). Wrote some code, testing: f(1) works, but f(2) doesn’t work. When testing a code by manual re-runs, it’s easy to miss something.įor instance, we’re creating a function f. If something is wrong – then we fix the code, run again, check the result – and so on till it works. For instance, we can do it in the console. When we write a function, we can usually imagine what it should do: which parameters give which results.ĭuring development, we can check the function by running it and comparing the outcome with the expected one. Automated testing will be used in further tasks, and it’s also widely used in real projects.

Mocha pro tutorial