Inside the Engine: How Modern JS Test Runners Work and the Traps They Hide

Hello, I'm grateful that you chose to watch my talk. Thank you. Last week, I had to run some unit tests while I was coding. Business performance can be awesome. It has very interesting and outstanding features. These test sets are overly complex. It's easy to find yourself troubleshooting for hours. VTest has almost 200 configuration options. By explaining how things work, we can answer questions about using complex third-party runners versus the built-in node.js runner. Understanding better helps avoid pitfalls, troubleshoot faster, and identify opportunities for configuring things better. The CLI layer does validation and hands over to the VTest class. It searches for test files, runs them efficiently using a pool of workers, and ensures isolation to prevent issues with dirty state. VTest uses the piscina library to facilitate work with multiple workers and improve performance. The workers prepare by setting the right globals, initializing snapshots, deciding the test runner file, and starting coverage collection. Each worker executes all the tests in a file and sends an RPC message when done. The decision to reuse or create a fresh worker is determined by the isolate configuration option. Consider spreading tests among more files to fully utilize the machine. Choose between process, thread, or VM as the worker type. In terms of isolation, you can choose between using a process, a thread, or a VM. Process is the heaviest in terms of performance cost, while thread is lighter. VM performance depends on known slower aspects like accessing globals. Process is the classic choice for stability, but thread has limitations and known issues. VM has reporting issues with memory leaks. Benchmark results showed that using multiple processes was 50% better for real-world applications, but for unit tests, one process was ten times faster. Thread was slightly faster than process, and VM was slower. The price of isolation with process worker types was approximately three minutes. Without isolation, the tests lasted only two minutes, much faster, but with a few failures. Threads showed similar results with a few failures. The risk of dealing with testing issues increases without isolation. By default, tests run sequentially inside workers, but you can configure them to run in parallel using the 'concurrent' keyword. However, tests still run sequentially despite specifying 'concurrent'. Concurrency in VTest is based on promises and requires asynchronous work. Unit tests run sequentially and concurrency has no isolation. Mocking in one test affects other tests running simultaneously. In choosing worker configurations, it depends on the context. In-file concurrency is best avoided, and the process worker type is recommended as the default. Isolation is crucial in integration tests but not mandatory in unit tests. Inside the worker, a TypeScript file is handled, and failures can occur when mocking functions. Mocking doesn't work in the worker. The worker handles TypeScript files and transpiles them using Vite server. Vite server replaces imports and hoists the mocking. Vite introduces a new module loader in the runtime. Vite hoisted the mock to the first line in the transform code to make it before the import. Additionally, Vite changes mocks to dynamic imports, ensuring that mocking works. Vite intercepts function calls on the file import level, but cannot intercept calls between functions in the same file. Moving function two to a different file or using an object export can solve this issue. Function one calls function two on the same object context. Use Spy to replace functions inside the object. Vite offers a range of plugins for different functionalities. You can fix import issues by customizing Vite's runtime. The Vite server handles dependency resolution and transformation. Consider using the built-in test runner or mockup for small-scale testing. Gain a better testing experience with Vite's customized runtime.