Testing Strategy — Series 3

Preview — 3 of 10 questions

How should a threshold like this be used?

javascript

{ "coverageThreshold": { "global": { "lines": 80 } } }

AAs a target to reach, after which the number can be left alone

BAs a ratchet: set it at or just below the current figure so coverage cannot fall, and raise it when it rises — which turns the threshold into a guard against regression rather than a goal to be hit, since a number chosen as a target invites tests written to satisfy the metric instead of to catch defects

CAs a release gate at 100%, since anything less leaves untested code

DAs a per-developer metric, to identify who contributes the least tested code

What gives the strongest evidence before the cutover?

javascript

A rewritten pricing service must replace the old one. Correctness matters more than speed.

AA comprehensive unit-test suite for the new implementation

BA canary release sending 1% of traffic to the new service

CRunning both in staging with synthetic requests

DShadow traffic: send every production request to both, serve the old service's response, and record where the two disagree — which tests the new implementation against real inputs, at real volume, with no user exposed to its output

What belongs in the follow-up?

javascript

A malformed timezone in a customer record crashed the nightly job for three hours.

AA test reproducing that exact input, committed with the fix — so the specific defect cannot return, and the test documents a real-world case the original design missed; a fix without one leaves nothing preventing a later refactor from reintroducing it

BA broader integration test covering the whole job, since the specific case is now understood

CNothing beyond the fix, if the cause is well understood

DA monitoring alert, which is more valuable than a test

Answer all 10 questions (7 more), see explanations for every answer, and track your score.