The release of Node.js 18 brought a surprise: an experimental test runner, like other languages like Python, Go or Deno. Node.js has been around since 2009, but given that until now it has not had an official test runner, several projects have attempted to take that spot. Although the runner is still experimental, given that this version will turn into a LTS version, I decided to compare to other established test runners.
In this article, I am not:
- Running any benchmarks.
- Going deep into details.
- Comparing with every single test runner around.
In this article, I am:
- Giving a gentle introduction to the new test runner.
- Comparing it feature wise with other frameworks I have used.
- Comparing the developer experience with other frameworks I have used.
As the test runner is still marked as experimental, this means that it could change at any time, or even completely dropped. Therefore, there is a chance that the content of this article is irrelevant if read it in the future.
Node.js test runner in a nutshell.
The specification of the test runner is short and concise. It can be found in the official documentation, but I will try to make even a shorter summary of it.
The test runner is executed by passing the
—-test option to node. If no file paths are provided as input, it will recursively search for test files. If it can find a test folder, it will execute its contents as a test, else, it will search for files starting or ending in test.
Every file will be executed in a different child process. If all the test cases are successful, it will exit with a 0, otherwise it will exit with a 1. The results are returned using the TAP format, an old friend of Perl developers.
The test cases can be described using the test format or the describe format, both common in other testing libraries. You are free to use the one you prefer, and both are available as part of the package
node:test. Independently of which one you use; the evaluation of the test cases will be the same. A synchronous test will…