Node.js环境下原生JavaScript项目使用Jest进行单元测试的最佳实践咨询

Great question—starting off with solid Jest habits is such a smart move, especially with vanilla Node.js where conventions can feel a bit loose compared to opinionated frameworks like React. Let’s break down each of your questions with practical, project-proven advice tailored to your stack:

1. Testing File & Folder Structure #

There are two widely accepted patterns, and which you choose depends on your project’s size:

• Colocated tests (small to medium projects)：Keep test files right next to the source code they test. Jest automatically recognizes files named *.test.js or *.spec.js, so this keeps related code close and easy to find. Example structure:

  src/
    utils/
      dateHelper.js
      dateHelper.test.js
    api/
      client.js
      client.test.js
  

• Dedicated __tests__ folder (large projects)：Mirror your source code structure inside a top-level __tests__ directory. This keeps source and test code completely separated, which can be cleaner for large codebases. Example:

  src/
    utils/
      dateHelper.js
    api/
      client.js
  __tests__/
    utils/
      dateHelper.test.js
    api/
      client.test.js
  

Pro tip: Jest ignores node_modules, dist, and other build folders by default, so don’t worry about accidentally including those. Stick to one pattern consistently across your project.

2. Should You Chase 100% Code Coverage? #

Short answer: No—100% coverage is almost always overkill and can hurt productivity.
Coverage is a tool to identify untested code, not a goal in itself. Focus on testing:

• Core business logic
• Edge cases (e.g., invalid inputs, empty datasets)
• Error paths (e.g., failed API calls, invalid file reads)
  You don’t need to test trivial code like simple getters/setters, one-line return statements, or boilerplate that’s unlikely to break. Many mature projects aim for 70-90% meaningful coverage—the key is that every test adds value, not just checks a box.

To keep things practical, use Jest’s --coverage flag to spot gaps, but don’t fixate on hitting 100%. For example, if a function has a conditional that’s only triggered by an extremely rare edge case (like a system-level error), it’s okay to skip covering that if testing it would require overly complex setup.

3. When to Use Mocks Instead of Real Implementations #

Mocks are your friend for isolating code and making tests fast/reliable, but don’t overuse them. Here are the key scenarios to mock:

• External dependencies: Any code that interacts with third-party APIs, databases, file systems, or network calls. These are slow, unstable, or require external setup—mock them to return fixed data or errors. For example, mock fs.readFile instead of reading real files during tests.
• Complex internal dependencies: If you’re testing a function that relies on another large, complex module, mock that dependency to focus only on the current function’s logic. For example, if calculateOrderTotal() depends on fetchUserDiscount(), mock fetchUserDiscount() to return a fixed value so you can test the calculation logic in isolation.
• Error path testing: To simulate rare or hard-to-reproduce errors (like a database connection failure), mock the dependency to throw an error instead of trying to trigger the real failure.

When NOT to mock:

• Pure functions with no external dependencies (e.g., a utility that formats dates)
• Integration tests where you want to verify multiple parts of your code work together
• Core business logic that’s critical to your application’s functionality

Example of mocking fs in vanilla Node.js:

const fs = require('fs');
const readConfigFile = require('./readConfigFile');

jest.mock('fs'); // Automatically mocks all fs methods

test('reads config file content', async () => {
  fs.readFile.mockResolvedValue(JSON.stringify({ apiKey: 'test-key' }));
  const config = await readConfigFile('config.json');
  expect(config.apiKey).toBe('test-key');
});

4. Recommended Approaches for Async Testing #

Jest has great support for all vanilla Node.js async patterns—here’s the order of recommendation based on readability and simplicity:

a. Async/Await (Best for Promise-based code) #

This is the most intuitive approach, as it makes async tests look almost identical to synchronous ones. Just mark your test function as async and use await for async operations:

test('fetches user data from API', async () => {
  const user = await fetchUser(1);
  expect(user.id).toBe(1);
  expect(user.name).toBe('John Doe');
});

// For error handling
test('throws error for invalid user ID', async () => {
  await expect(fetchUser(999)).rejects.toThrow('User not found');
});

b. Return Promises #

If you prefer not to use async/await, you can return a Promise directly from your test—Jest will wait for it to resolve or reject:

test('resolves with user data', () => {
  return fetchUser(1).then(user => {
    expect(user.id).toBe(1);
  });
});

test('rejects for invalid ID', () => {
  return expect(fetchUser(999)).rejects.toThrow('User not found');
});

c. Callback Pattern #

For older callback-based code, use Jest’s done parameter to signal when the test is complete. Make sure to call done() (or done(err) if there’s an error) to avoid timeout issues:

test('reads file content via callback', (done) => {
  readFile('data.txt', (err, content) => {
    if (err) return done(err);
    expect(content).toBe('test data');
    done();
  });
});

Bonus: Timers #

If your code uses timers like setTimeout, use jest.useFakeTimers() to skip waiting for real time:

test('triggers callback after delay', () => {
  jest.useFakeTimers();
  const callback = jest.fn();
  
  delay(callback, 1000);
  jest.runAllTimers(); // Fast-forwards all timers
  
  expect(callback).toHaveBeenCalled();
});

Remember, the best practices are guidelines—adjust them to fit your project’s size, team preferences, and complexity. The goal is to write tests that are reliable, fast, and give you confidence in your code.

内容的提问来源于stack exchange，提问作者Eugenie Ahangama