HTML MASTER CLASS /// LEARN TAGS /// BUILD STRUCTURE /// SEMANTIC WEB /// HTML MASTER CLASS /// LEARN TAGS ///

Untitled Lesson

⚡ Total XP: 0|💻 backend XP: 0

Skill Matrix

UNLOCK NODES BY LEARNING NEW TAGS.

Select an unlocked node to view details root

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Chasing 100% code coverage as a goal, mistaking a coverage number for actual test quality

// Wrong: counts as 100% coverage but asserts nothing meaningful
it('calls calculateTax', () => {
  calculateTax(100); // no expect() at all
});

// Correct: actually verifies the behavior
it('calculates 20% tax correctly', () => {
  expect(calculateTax(100)).toBe(20);
});

The Solution //

A test can execute every line of a function (100% coverage) while never actually asserting on the meaningful output — e.g. calling a function and checking only that it 'didn't throw' satisfies coverage tooling but proves nothing about correctness. Treat coverage percentage as a signal for finding untested code paths, not as a target to maximize by writing shallow, assertion-free tests.

The Error //

Configuring CI to run npm test but not actually failing the build (blocking merge) when tests fail

// GitHub Actions: running tests isn't enough on its own
// Branch protection rules must mark this job as a REQUIRED status check
// Settings > Branches > Require status checks to pass before merging

The Solution //

If the CI pipeline runs the test command but the workflow doesn't check its exit code as a required status check on the pull request, developers can merge code with failing tests because the failure is visible only if someone manually checks the logs. Configure the test job as a required check in your branch protection rules so a red test suite physically blocks the merge button.