Node.js built-in test runner in Node.js - Step-by-Step Execution

Visual mode data not available for this pattern.

Practice

1. What is the main purpose of the Node.js built-in test runner?

easy

A. To write and run tests easily without extra tools

B. To compile Node.js code faster

C. To deploy Node.js applications automatically

D. To monitor server performance in real-time

Solution

1. Step 1: Understand the role of the test runner

   The Node.js built-in test runner is designed to help developers write and run tests without needing additional testing frameworks.

2. Step 2: Compare options with this purpose

   Options B, C, and D describe unrelated tasks like compiling, deploying, or monitoring, which are not the test runner's function.

3. Final Answer:

   To write and run tests easily without extra tools -> Option A

4. Quick Check:

   Test runner purpose = write and run tests [OK]

Hint: Test runner = tool to run tests simply [OK]

Common Mistakes:

• Confusing test runner with build tools
• Thinking it deploys apps
• Assuming it monitors performance

2. Which of the following is the correct way to import the assertion module in a Node.js test file?

easy

A. const assert = require('assert');

B. import assert from 'assert';

C. import { assert } from 'assert';

D. require import assert from 'assert';

Solution

1. Step 1: Recall Node.js import syntax for CommonJS

   Node.js traditionally uses const assert = require('assert'); to import modules in CommonJS style.

2. Step 2: Check each option's syntax

   import assert from 'assert'; uses ES module syntax but without enabling ES modules, it may fail. import { assert } from 'assert'; is incorrect because assert is the default export, not a named export. require import assert from 'assert'; is invalid syntax.

3. Final Answer:

   const assert = require('assert'); -> Option A

4. Quick Check:

   CommonJS import = require() [OK]

Hint: Use require() for assert in Node.js tests [OK]

Common Mistakes:

• Using ES module import without config
• Trying to destructure assert
• Mixing require and import keywords

3. What will be the output when running the following test code with node --test?

import test from 'node:test';
import assert from 'assert';

test('simple addition', () => {
  assert.strictEqual(2 + 2, 4);
});

test('failing test', () => {
  assert.strictEqual(3 * 3, 8);
});

medium

A. Both tests fail with assertion errors

B. Both tests pass with no errors

C. Syntax error stops tests from running

D. First test passes, second test fails with assertion error

Solution

1. Step 1: Analyze each test assertion

   The first test checks if 2 + 2 equals 4, which is true, so it passes. The second test checks if 3 * 3 equals 8, which is false, so it fails.

2. Step 2: Understand test runner behavior

   Node.js test runner runs all tests and reports which pass or fail. It does not stop on first failure.

3. Final Answer:

   First test passes, second test fails with assertion error -> Option D

4. Quick Check:

   Correct assertions pass, wrong ones fail [OK]

Hint: Check each assertion result carefully [OK]

Common Mistakes:

• Assuming all tests pass
• Thinking syntax error occurs
• Believing test runner stops on first fail

4. Identify the error in this test code snippet:

import test from 'node:test';
import assert from 'assert';

test('check truth', () => {
  assert.equal(true, 1);
});

medium

A. Test name must be a function, not a string

B. Using assert.equal instead of assert.strictEqual causes a type coercion issue

C. Incorrect import statement for test module

D. Missing async keyword in test callback

Solution

1. Step 1: Understand assert.equal vs assert.strictEqual

   assert.equal uses loose equality (==) which allows type coercion, so true == 1 passes, but this can cause unexpected results.

2. Step 2: Identify best practice for strict checks

   Using assert.strictEqual is recommended to avoid type coercion and ensure exact equality.

3. Final Answer:

   Using assert.equal instead of assert.strictEqual causes a type coercion issue -> Option B

4. Quick Check:

   Use strictEqual to avoid type coercion [OK]

Hint: Prefer strictEqual for exact matches [OK]

Common Mistakes:

• Ignoring difference between equal and strictEqual
• Thinking async is always required
• Misunderstanding import syntax

5. You want to write a test that checks if a function getUserName(id) returns a non-empty string for valid IDs and throws an error for invalid IDs. Which approach correctly uses the Node.js built-in test runner and assertions?

hard

A. Use assert.strictEqual(getUserName(validId), '') and no error test

B. Use one test with assert.equal(getUserName(validId), 'non-empty') and ignore errors

C. Use two tests: one with assert.ok(typeof result === 'string' && result.length > 0), another with assert.throws(() => getUserName(invalidId))

D. Use console.log to check outputs manually instead of assertions

Solution

1. Step 1: Define tests for both valid and invalid cases

   Testing valid IDs requires checking the return is a non-empty string. Testing invalid IDs requires checking that an error is thrown.

2. Step 2: Use appropriate assertions

   assert.ok can check conditions like type and length. assert.throws verifies that calling the function with invalid input throws an error.

3. Final Answer:

   Use two tests: one with assert.ok(typeof result === 'string' && result.length > 0), another with assert.throws(() => getUserName(invalidId)) -> Option C

4. Quick Check:

   Separate tests for success and error cases [OK]

Hint: Test success and error cases separately with assert [OK]

Common Mistakes:

• Ignoring error case tests
• Checking empty string instead of non-empty
• Using console.log instead of assertions