Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
A generated test achieves 100% line coverage for a function but only asserts `expect(result).toBeDefined()`. What is the practical problem with this test?
💻 Code Challenge | +75 XP
Write a test-generation prompt that requests specific edge cases (zero items, exceeding a maximum, a duplicate idempotency key, a mid-transaction failure) for an order-creation function, rather than a generic "write tests" request.
A production bug shipped despite 95% test coverage on the affected module, because the relevant generated tests only asserted that functions didn't throw, not that they returned correct values. Reorder the steps to fix the test suite's actual effectiveness.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant
Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Treating a high test coverage percentage as equivalent to meaningful, effective test coverage
// Contributes to coverage %, but provides almost no real protection
expect(order).toBeDefined();
// Provides actual protection against a regression
expect(order.total).toBe(150.00);
expect(order.status).toBe("pending");The Solution //
Coverage percentage only measures whether a line of code executed during testing at least once — it says nothing about whether the test's assertions actually verify correct behavior. A test with a weak assertion (like expect(result).toBeDefined()) contributes to coverage while providing almost no real protection against a regression.
The Error //
Requesting test generation with a generic "write tests for this function" prompt instead of specifying edge cases
// Generic: mostly happy-path coverage
"Write tests for createOrder()"
// Specific: directs coverage toward what actually matters
"Write tests for createOrder() covering zero items, exceeding
max items, a duplicate key, and a mid-transaction failure"The Solution //
A generic request tends to produce tests covering mostly the happy path, missing the boundary values, invalid inputs, and failure scenarios that are usually where real bugs actually hide. Explicitly listing the specific edge case categories to cover produces meaningfully more thorough test coverage.