Hey there! Awesome that you’re focusing on good testing habits from the start with Jest—this will save you tons of headaches down the line, especially in vanilla Node.js projects. Let’s tackle each of your questions with practical, project-proven advice:

1. How to plan test file and folder structure? #

Two common, widely accepted patterns work great for vanilla Node.js projects:

Pattern 1: Tests alongside source files #

Place your test files directly next to the code they’re testing, using the .test.js suffix (or .spec.js if you prefer). This makes it super easy to find and update tests when you modify your source code—no switching between separate directories. Example structure:

src/
├── utils/
│   ├── formatDate.js
│   └── formatDate.test.js
├── services/
│   ├── apiClient.js
│   └── apiClient.test.js
└── config/
    ├── loadConfig.js
    └── loadConfig.test.js

Pattern 2: Dedicated __tests__ directory #

For larger projects where you want to keep your source directory clean, mirror your source structure inside a root-level __tests__ folder. This keeps all tests grouped together but still aligned with your code organization:

src/
├── utils/
│   └── formatDate.js
├── services/
│   └── apiClient.js
__tests__/
├── utils/
│   └── formatDate.test.js
└── services/
    └── apiClient.test.js

Whichever you choose, stick with it consistently. Also, note that Jest automatically recognizes __mocks__ folders—place mocks either alongside the module they’re mocking (for local mocks) or at the root level (for global mocks like fs or axios).

2. Is 100% code coverage a necessary goal, or is it overkill? #

100% code coverage is almost always overkill—it’s a metric, not a destination. The goal of testing is to give you confidence that your code works as expected, not to check a box.

Focus on covering:

• Core business logic
• Edge cases and error handling paths
• Critical utility functions that are used across your project

Don’t waste time writing tests for trivial code (like a single-line log statement) just to hit 100%. These tests add maintenance overhead without providing any real value. Use jest --coverage to identify gaps, but treat the report as a guide, not a requirement.

3. When to use mocks instead of real implementations, and vice versa? #

The golden rule here is: test the behavior of your code, not its dependencies.

Use mocks when: #

• You’re relying on external services (databases, third-party APIs, file system operations): Mocks let you avoid slow, flaky tests that depend on network or external state. For example, mock fs.readFile instead of creating real test files, or mock an API client instead of making actual HTTP requests.
• You need to simulate error conditions: Mocks make it easy to force a dependency to throw an error, so you can test how your code handles failure.
• You want to isolate your code from complex dependencies: If your module uses a large, internal utility class, mock only the specific methods your module uses to keep tests focused.

Use real implementations when: #

• Testing pure, stateless functions: If your function takes inputs and returns outputs without side effects (like a date formatter or math utility), test the real thing—mocks here would add unnecessary complexity.
• Your dependency is simple and stable: If you’re relying on a small, internal module with no external dependencies, using the real implementation keeps tests more accurate.

Example: For a function that reads a config file, use a real test config file to test successful loading, but mock fs.readFile to throw an error when testing failure handling.

4. Recommended methods for handling asynchronous tests? #

Async/await is the most clean and readable approach for modern vanilla Node.js—stick with this whenever possible. Jest fully supports it, and it aligns with standard JS async patterns. Here are the best practices:

1. Async/await (preferred) #

Wrap your test logic in an async function and use await for asynchronous operations:

test('loads config file asynchronously', async () => {
  const config = await loadConfig('./test-config.json');
  expect(config.port).toBe(3000);
});

2. Return a Promise #

If your function returns a Promise, you can return it directly from the test—Jest will wait for it to resolve or reject:

test('loads config file via Promise', () => {
  return loadConfig('./test-config.json')
    .then(config => expect(config.port).toBe(3000));
});

3. .resolves / .rejects syntax sugar #

For simple cases, you can use Jest’s built-in matchers to assert on Promises directly:

test('resolves to correct config', () => {
  expect(loadConfig('./test-config.json')).resolves.toHaveProperty('port', 3000);
});

test('rejects on invalid file path', () => {
  expect(loadConfig('./invalid-path.json')).rejects.toThrow('File not found');
});

Critical note: Always make sure Jest knows when your async test is done. If you forget to await, return the Promise, or use .resolves/.rejects, Jest will finish the test before your async code runs, leading to false positives or failures.

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