The Battle of Node.js Testing: When Switching Back to Mocha Seemed Like easier

Introduction

Testing is essential in software development, but it often feels like a battleground. I recently faced a challenging issue while working with the native Node.js test runner, specifically when testing asynchronous processes related to PostgreSQL and EventStoreDB. My frustration peaked several times, nearly pushing me to switch back to the ever-reliable Mocha. I thought my choice of using the native solution was the problem. As it turned out, the real issue wasn't the test framework itself but rather how I managed open resources.

The Setup

I had been working on a microservices project where I used Event Store to implement event sourcing, which was a core part of the system's architecture. Naturally, my test suite needed to interact with the Event Store to verify that events were correctly appended, read, and handled.

Choosing Node.js’s native test runner (node:test) seemed modern and efficient, mainly because it was lightweight and didn’t require extra dependencies. I set up my tests using the EventStoreDBClient from the @eventstore/db-client library. Here’s a simplified version of what my test setup looked like:

describe("Event Store", async () => {

  it("should connect to the eventStore and perform operations", async () => {

    const result = await client.appendToStream("TEST_STREAM", testEventJson);

    expect(result.success).to.be.true;

  });

});

The Issue

Initially, everything seemed fine when I ran the tests. However, I soon noticed that the test runner didn't exit after the tests completed. The test suite would pass, but the process kept running, causing intermittent hangs.

I tried various approaches: using .then() and .finally(), implementing try/catch blocks, working with done(), and even using await directly in the it block. Despite all these attempts, the problem persisted. The frustration tempted me to revert to Mocha—a framework that had never let me down.

The Discovery

At this point, I took a step back and considered what could be causing the test runner process to hang. My past experience with databases and file handles reminded me that open connections often cause Node.js processes to hang, waiting for those connections to close.

This realization prompted me to review my resource management. I discovered that the EventStoreDBClient instance needed to be properly disposed of after each test run. While I had an after hook to dispose of the client, I hadn’t ensured that all resources were being closed rigorously.

The Fix

To address the issue, I made sure to explicitly call the dispose() method on the Event Store client after the tests had finished. This ensured that any open connections were closed, and resources were cleaned up properly:

after(async () => {

  await client.dispose(); // Ensure all resources are properly closed

});

Lessons Learned

1. Resource Management is Crucial: Always check for open resources, such as database connections, file handles, or network connections. Failing to properly dispose of these can cause tests to hang or fail intermittently.




2. Don’t Blame the Framework Too Quickly: It’s tempting to blame the testing tool when things go wrong. However, the issue often lies within the implementation. Understanding the tools and properly managing resources can solve many problems.

Conclusion

Using the native Node.js test runner was a valuable learning experience. Although the temptation to revert to Mocha was strong, resolving the resource management issue highlighted the importance of proper setup and teardown processes in automated testing. Ultimately, it’s not about the tool you choose but how effectively you use it. Properly managing resources, understanding the framework, and thorough testing practices will lead to a more stable and reliable testing environment.