Week two lab: demonstrate a failure you fixed

Why a failed test can strengthen a project explanation

This is an evergreen career-practice lab, not a report of a new testing feature. A useful project explanation is not “the test was red, so I changed code until it became green.” It connects a written rule to evidence and explains why the correction satisfies that rule without changing unrelated behaviour.

Node.js provides a built-in test runner through the node:test module. Its documentation says a synchronous test fails when it throws and a fulfilled test passes when it does not; failed tests also produce a non-zero process exit code. Strict assertions compare actual and expected values and can display their difference, giving this exercise a small but inspectable evidence trail.

Source: Node.js documentation: Test runnerNode.js documentation: Assert

Write the requirement before introducing the fault

Create a disposable JavaScript folder. The fictional requirement is: delivery costs ₹50 when an order subtotal is below ₹500, and delivery is free when the subtotal is ₹500 or more. This is sample data for the lab, not a SPOTHUB fee or a real store policy.

Implement a deliveryFee function with a deliberate boundary mistake: return zero only when subtotal is greater than 500; otherwise return 50. Label this as an intentional fault in your notes. The implementation works for ₹499 and ₹501 but violates the exact-threshold case, which makes the boundary valuable.

• ₹499 should return a ₹50 delivery fee.
• ₹500 should return a zero delivery fee.
• ₹501 should return a zero delivery fee.

Create a test that exposes the boundary mistake

In a separate test file, import test from node:test and strict assertions from node:assert/strict. Add three test cases for ₹499, ₹500 and ₹501. Run them with node --test using a supported Node.js environment. Keep the original command and output rather than paraphrasing from memory.

The intended failure is the ₹500 case: the function returns 50 while the requirement expects zero. Record the failing test name, actual value, expected value and relevant source line. The neighbouring cases should pass. That pattern narrows the problem to the threshold comparison instead of suggesting that every delivery calculation is broken.

Source: Node.js documentation: Test runnerNode.js documentation: Assert

Diagnose before changing the implementation

Compare the requirement’s phrase “₹500 or more” with the implementation’s greater-than operator. The code excludes exactly ₹500. State that as the cause before editing: the comparison does not include the boundary value. Avoid weakening the test to expect 50, because that would make the check agree with faulty code while contradicting the written rule.

Change only the comparison from greater than to greater than or equal to. Review the diff and confirm that no price, test expectation or unrelated file changed. This minimal correction is easier to defend than a larger rewrite, but minimal does not automatically mean correct; the rerun still matters.

Rerun the evidence and preserve both outcomes

Run the complete three-case test file again. Confirm that ₹499 still returns 50 and that both ₹500 and ₹501 return zero. Save the before-and-after commands, outputs and code diff. If the project uses GitHub Actions, its workflow page lets you inspect the failed step and search or download run logs; artifacts can preserve generated test output after a job ends.

Do not erase the failed run merely because the repair now passes. The first run proves that the test could detect the controlled defect, while the second supports the specific correction. Remove any credentials, machine paths or personal data before sharing logs, and remember that hosted log and artifact access depends on repository permissions and retention settings.

Source: GitHub Docs: Using workflow run logsGitHub Docs: Workflow artifacts

Turn the lab into an honest interview answer

Explain the work in six sentences: the requirement, the exact failing input, actual versus expected output, the comparison error, the one-line fix and the passing regression cases. Say clearly that the defect was deliberately introduced for practice. If you later describe a real defect, use only evidence from work you are allowed to discuss and remove confidential details.

This lab checks three numeric examples in one pure function. It does not verify invalid inputs, floating-point currency behaviour, tax, checkout integration or a deployed system. List those limits and propose the next test rather than inflating the result. Learners in Chennai or online can extend the same evidence-first explanation in SPOTHUB’s Full Stack + AI path; completing the exercise or training does not guarantee employment.

Sources and further reading

• Node.js documentation: Test runner · checked 2026-09-30
• Node.js documentation: Assert · checked 2026-09-30
• GitHub Docs: Using workflow run logs · checked 2026-09-30
• GitHub Docs: Workflow artifacts · checked 2026-09-30

Spot an error? Email info@spothub.in with the article link and correction.