The above code uses Object.prototype.toString to determine the data type, and we use the test case for the above code (here asserting the use of node-native assert methods, using the BDD’s testing style):

The api semantics provided by mocha are still relatively strong, even if you have not written unit test code, it is not difficult to understand what this code does just by looking at this code, and this test code page will be used as a sample of our final verification of simple Mocha, let’s first look at the execution results of running the test case using mocha:

As shown in the image above, that is, the execution result of our previous test code, let’s split some of the functional points of the current mocha implementation.

Note: For more ways to use mocha, see Mocha – the fun, simple, flexible JavaScript test framework[1]

afterEach: triggers the hook after each test unit execution ends;

This kind of asynchronous code is also very common in our actual business, such as a part of the code that relies on the return of interface data, or the writing of a single test use case for some timers. Micha supports asynchronous code in two ways, one is that the callback function directly returns a promise, and the other is that it supports passing the argument done in the callback function and manually calling the done function to end the use case.

The above mocha folder is the simple version of the mocha directory that we are going to implement, and the directory structure refers to the mocha source code, but only takes the core part of the directory structure.

The portal file is updated to:

The order of execution of test cases is particularly important, as mentioned earlier the execution of the use cases follows the order from outside to inside, top to bottom, and the callback function handling for describe and it makes it easy to think that this is a tree structure and a depth-first traversal order. Simplify the above use case code:

The code structure for this section is as follows:

The structure of the whole tree is as above, and when we deal with specific functions, we can define Suite/Test classes to describe the describe/it functions separately. You can see that the describe function is parent-child relationship, and we define the properties of the Suite class as follows:

The Test class represents a simpler definition of it:

At this point our whole process comes out:

Collect the execution results of the test case.

OK, the idea is already very clear, implement the specific code

To facilitate support for a variety of test-style interfaces we export uniformly:

Then do the global mounting of the bdd interface in the Moscha class:

At this point, we have completed the global mounting of the APIs, and we can safely import the test case file for the function to execute.

The above function simply implements a method that recursively reads all the local test case files and then uses that method in the Mica class to load our current test case files:

Note that the above code we only created the structure of the tree by executing the describe’s callback function, and the specific test case code (its callback function) has not yet begun to execute. Based on the above code, our entire Suite-Test tree has been created, and the process of collecting the use cases has been completed so far. At this point our Sute-Test tree is created with this structure:

Let’s modify the Suite-Test tree we created earlier to adapt the callback functions for it, before, after, beforeEach, and afterEach:

Based on the Suite-Test tree created above, we can perform a traversal of the tree to execute all test cases, and for the execution of asynchronous code we can borrow async/await to achieve. At this point our flowchart is updated as follows:

The whole idea is very simple, for the Suite-Test tree, start from the root node to traverse the tree, the tree in all the Test nodes mounted on the callback function can be executed. The relevant code is implemented as follows:

Inject the Runner class into the Morcha class:

Briefly introduce the above code logic, the Runner class includes two methods, one method to process Suite, one method to process Test, using the structure of the stack to traverse the Suite-Test tree, recursively process all Suite nodes, so as to find all Test nodes, the callback function in Test is processed, and the test case execution ends. But at this point we will find that only the test case has been executed, the execution results of the test case have not yet been obtained, and we cannot know which test case passed and which did not pass.

We need a middleman to record the results of the execution and output them to us, at which point our flowchart is updated as follows:

Modify the Runner class so that it inherits EventEmitter to do the delivery of events:

Callbacks that listen to execution results in the handler of test results are handled uniformly:

The role of the above code collects the code.

Let’s manually construct a failure use case:

Execute next:

A lite mocha is here!

Strange Dance Troupe is the largest front-end team of the 360 Group, representing the group in the work of W3C and ECMA members (TC39). Qi Dance Troupe attaches great importance to talent training, there are engineers, lecturers, translators, business interface personnel, team leaders and other development directions for employees to choose, and supplemented by providing corresponding technical, professional, general, leadership and other training courses. With an open and seeking mindset, the Odd Dance Company welcomes all kinds of outstanding talents to pay attention to and join the Strange Dance Troupe.