A telecom billing pipeline converts call duration using 60 seconds to the minute, and a known case of 120 seconds must become 2 minutes. A later edit could change that conversion unnoticed until invoices shift. Which practice stops the silent change?
Select an answer to reveal the explanation.
Short Explanation
A unit test is a padlock on a calculation you care about. You lock the seconds-to-minutes step so a later edit fails the check instead of quietly changing invoices. A comment or a clearer name will not sound an alarm.
Full Explanation
A unit test encodes a known input and the required output, then fails when the function drifts. Locking 120 seconds to 2 minutes means an edit that changes the conversion breaks the check at development time, before invoices move. A monthly dashboard may eventually show bad bills, but it runs after the silent change has already reached customers, so it does not stop the edit. A longer variable name can hint at intent and still allows the formula to change without any failed check. A comment can restate the 60-seconds-to-the-minute rule and is just as easy to leave behind when the code is edited. The known case is small on purpose. Dividing 120 by 60 yields 2, so an edit that stops using 60 seconds to the minute fails a check a person can recompute by hand. That failure arrives when the tests run, which is early enough to reject the edit, rather than after customers have been billed. Exam caveat: the test locks the behavior it asserts, not every other billing rule, so the asserted case must be the conversion the team cares about. Operational check: change the conversion on a branch, run the test, and confirm it fails while 120 seconds no longer maps to 2 minutes.