What is the role of description () in Mocha?

Question

The documentation on the official Mocha website contains this example:

describe('User', function(){ describe('#save()', function(){ it('should save without error', function(done){ var user = new User('Luna'); user.save(function(err){ if (err) throw err; done(); }); }) }) }) 

I want to know when I should nest my tests in the describe function and what the main purpose of describe is. Can I compare the first argument passed to describe with comments in a programming language? describe not shown in the console output. Is this just for readability, or is there some other use for this feature?

Is there something wrong if I use it like that?

 describe('User', function(){ describe('#save()', function(){ var user = new User('Luna'); user.save(function(err){ if (err) throw err; done(); }) }) }) 

If I do it this way, the test passes anyway.

Answer 1

Calling it identifies each individual test, but by itself, it does not tell Mocha how your test suite is structured. How you use the describe call is what gives the structure to your test suite. Here are some of the things that describe use to structure your test suite for you. Here is an example of a test suite simplified for discussion:

 function Foo() { } describe("Foo", function () { var foo; beforeEach(function () { foo = new Foo(); }); describe("#clone", function () { beforeEach(function () { // Some other hook }); it("clones the object", function () { }); }); describe("#equals", function () { it("returns true when the object passed is the same", function () { }); it("returns false, when...", function () { }); }); afterEach(function () { // Destroy the foo that was created. // foo.destroy(); }); }); function Bar() { } describe("Bar", function () { describe("#clone", function () { it("clones the object", function () { }); }); }); 

Suppose Foo and Bar are full classes. Foo has clone and equals methods. Bar has a clone . The structure described above is one of the possible ways to structure tests for these classes.

(The designation # used by some systems (for example, jsdoc) to indicate an instance field. Therefore, when used with a method name, it indicates the method called by the class instance (and not the class that is called for the class itself). The test suite will also work without presence # .)

Provide Banners

Some of Mocha's reporters show the names you give describe in the reports they create. For example, a spec reporter (which you can use by running $ mocha -R spec ) will report:

  Foo #clone ✓ clones the object #equals ✓ returns true when the object passed is the same ✓ returns false, when... Bar #clone ✓ clones the object 4 passing (4ms) 

Help Select Parts to Run

If you want to run only some of the tests, you can use the --grep option. Therefore, if you only care about the Bar class, you can make $ mocha -R spec --grep Bar and get the result:

  Bar #clone ✓ clones the object 1 passing (4ms) 

Or if you only care about clone methods for all classes, then $ mocha -R spec --grep '\bclone\b' and get the result:

  Foo #clone ✓ clones the object Bar #clone ✓ clones the object 2 passing (5ms) 

The value specified in --grep is interpreted as a regular expression, so when I pass \bclone\b , I ask only the word clone , and not things like clones or cloned .

Provide hooks

In the above example, the calls to beforeEach and afterEach are intercepts. Each hook affects it calls, which are inside the describe call, which is the parent of the hook. Various hooks:

• beforeEach , which is executed before each individual it inside the describe call.

• afterEach , which runs after each separate it inside the describe call.

• before , which starts once before any of it is executed inside the describe call.

• after , which starts once after running an individual it inside the describe call.

These hooks can be used to obtain resources or create the data structures necessary for testing, and then to free resources or destroy these structures (if necessary) after the tests are completed.

The snippet that you will show at the end of your question will not lead to an error, but in fact it does not contain any test, because the tests are determined by it .

Answer 2

As far as I know, to describe is really just for people ... So we can see different areas of the application. You can nest levels n levels deep.

 describe('user',function(){ describe('create',function(){} }); 

Answer 3

It's hard to add Louis's excellent answer. There are several advantages to the description block that he did not mention, which are skip and only functions.

 describe.skip(...) { ... } 

this descriptor will skip, and all its nested description will be described, and it will function until:

 describe.only(...) { ... } 

only this descriptor will execute, and its nested description and its functions. The skip() and only() modifiers can also be applied to the it () functions.

Answer 4

The description is simply used to understand the purpose of the tests, it is also used to logically group the tests. Suppose you are testing a database API, all database tests can fall under an external description, so the external description logically groups everything related to the database. Suppose that for testing 10 APIs are tested that are associated with a database, each of the internal description functions determines that these tests ....

Answer 5

The special role of the description is to indicate which component is being tested and which method of this component is also being tested.

for example, let's say we have a user prototype

 var User = function() { const self = this; function setName(name) { self.name = name } function getName(name) { return self.name; } return{setName, getName}; } module.exports = User; 

And it needs to be tested, so a specification file is created for the unit test.

 var assert = require('assert'); var User = require("../controllers/user.controller"); describe("User", function() { describe('setName', function() { it("should set the name on user", function() { const pedro = new User(); name = "Pedro" pedro.setName(name); assert(pedro.getName(), name); }); }); }); 

It is easy to see that the purpose of the description is to indicate the component to be tested, and the nested description methods indicate which methods should be tested.