Table of contents
1.
Introduction
2.
Serial Mode
3.
Parallel Mode
4.
FAQs
5.
Key Takeaways
Last Updated: Mar 27, 2024

Mocha Runcycle and flow of execution

Career growth poll
Do you think IIT Guwahati certified course can help you in your career?

Introduction

Mocha.js is a free JavaScript test framework that runs in the browser and on Node.js. It has a very simple interface for testing both synchronous and asynchronous code.

Mocha.js executes tests in a sequential/serial order to provide flexible and accurate reporting, while also mapping uncaught exceptions to their respective test cases. Mocha.js provides functions that run in a predetermined order and log the results in the terminal window. It also cleans up the state of the software under test so that test cases can execute independently.

In this blog we will discuss the generic flow of tasks in serial mode and parallel mode. These are the two modes of workflow supported in Mocha.js.

Serial Mode

  1. Mocha is run by the user.
  2. Mocha processes any command-line parameters provided and loads options from config files if they are present.
  3. If the node executable has any known flags:
    1. Mocha will create a child process and execute it with these flags.
    2. Mocha does not launch a child process if this is not the case.
  4. --require tells Mocha which modules to load.
    1. Mocha "registers" known Mocha-specific exports (e.g., root hook plugins) in a file loaded this way.
    2. Otherwise, any exports of a –require'd module are ignored by Mocha.
  5. Any custom reporters or interfaces loaded using –require or otherwise are validated by Mocha.
  6. When no files or directories are specified, Mocha looks for files with the extensions .js.mjs, or .cjs in the test directory (but not its descendants), relative to the current working directory.
  7. The (default) bdd interface imports the test files in any order and gives them an interface-specific global context (this is how, for example, describe() becomes a global in a test file).
    1. When you load a test file, Mocha runs all of its suites and looks for–but does not run–any hooks and tests.
    2. All top-level hooks, tests, and suites are made members of an "invisible" root suite; the entire process has only one root suite.
  8. If there are any global setup fixtures, Mocha will run them.
  9. Mocha begins by executing the "root" suite:
  10. Any hooks that go "before all" (for the root suite, this only happens once; 
  11. Mocha runs the following tests for each one:
    1. Any hooks that go "before each"
    2. The test (and reports the result)
    3. Any hooks that go "after each"
  12. If the current suite has a child suite, repeat steps 10 through 12 for each child suite; each child suite inherits any "before each" and "after each" hooks defined in its parent suite.
  13. Any "after all" hooks. (for the root suite, this only happens once; see root hook plugins)
  14. If necessary, Mocha prints a final summary/epilog.
  15. If there are any global teardown fixtures, Mocha will run them.

Parallel Mode

  1. Skip reporter validation and repeat steps 1 through 5 from Serial Mode.
  2. All test files discovered are added to a queue (they are not loaded by the main process)
  3. If there are any global setup fixtures, Mocha will run them.
  4. Mocha produces a "worker" pool of subprocesses.
  5. A worker "bootstraps" itself immediately before running the first test it gets by:
    1. All --require'd modules are being loaded.
    2. Plugins for root hooks must be registered.
    3. Ignoring international conventions and custom reports
    4. Asserting the validity of a built-in or custom interface
  6. When a worker receives a test file to run, it starts a new Mocha instance for the single test file, and then:
  7. Step 7 is repeated by the worker.
  8. The worker replicates step 10 above, with the exception that it does not directly submit test findings; instead, it stores them in a memory buffer.
  9. When the worker finishes the test file, the results are buffered and returned to the main process, which then sends them to the reporter designated by the user (spec by default)
  10. If there are any remaining test files, the worker makes himself available to the pool; the pool provides the worker another test file to run.
  11. If necessary, Mocha prints a final summary/epilog.
  12. If there are any global teardown fixtures, Mocha will run them.

FAQs

  1. How does Mocha Testing work?
    Mocha is a powerful JavaScript test framework that runs on Node.js and in the browser, making asynchronous testing easy and enjoyable. Mocha tests run in a sequential order, allowing for flexible and precise reporting while mapping uncaught exceptions to the appropriate test cases.
     
  2. Does Mocha execute tests in order?
    Mocha will run the tests in the order the describe calls execute.
     
  3. Does Mocha run tests in parallel?
    Individual tests are not executed in parallel by Mocha. That is, if you provide Mocha a solitary, lonely test file, it will create a single worker process, which will run the file. You'll be punished for using parallel mode if you just have one test file.
     
  4. What is done() in Mocha?
    This "done" option tells Mocha that you're writing an asynchronous test when it's included in your callback method.

Key Takeaways

In this blog, we discussed in detail the way tests are executed in Mocha.js. We discussed the workflow in serial and parallel modes and also came up with interesting questions in the FAQs section. We saw that in the parallel mode of execution, some of the steps are the same as that in serial mode.

You can follow this interesting article from Coding Ninjas to get started with Mocha.js.

We hope that this blog has helped you enhance your knowledge regarding Flow of execution and runcycle in Mocha.js and if you would like to learn more, head over to our practice platform Coding Ninjas Studio to practice top problems, attempt mock tests, read interview experiences, and much more.! Do upvote our blog to help other ninjas grow. 
Happy Coding!.

Live masterclass