On this page
Green tests can confirm the wrong rule
Hypothetical situation: an order service should apply a discount when the eligible subtotal is at least 10,000. The implementation uses a strict greater-than comparison. A developer asks an assistant to write tests for the existing function, receives examples below and above the threshold, and gets a green test run. The exact boundary is still wrong.
The issue is not whether the assistant can generate valid test code. GitHub documented unit-test generation in its Copilot Chat general-availability announcement in December 2023, updated in May 2024. That capability was available before this coverage date. It does not supply an independent interpretation of your organisation’s commercial requirement.
The reviewer must establish the expected result separately from the implementation being tested. Otherwise, the implementation and its generated tests can agree with each other while both disagree with the business rule. A larger number of tests does not resolve that circular check.
Also check a case that must not receive the discount even though its total looks similar. The purpose is to challenge which facts determine eligibility. Keep the example independent of a particular programming language so the product owner can review it. Only then translate the agreed expectation into the repository’s test framework and naming conventions, and run it against the actual implementation.
Write the example before the assertion
Ask the product owner to state the rule in one sentence, including the boundary and the amount to which it applies. In this hypothetical exercise, eligible subtotal means the subtotal after item exclusions and before the discount, with tax and delivery outside the calculation. Those are invented exercise conditions, not advice about a real pricing policy.
Represent currency in the smallest agreed unit for the test examples. That makes ‘one unit below’ unambiguous. If your application uses another representation, document its rounding behaviour rather than quietly changing the expected values to fit a floating-point result.
Agree the expected eligibility for three cases: immediately below the threshold, exactly on it and immediately above it. Add a case where the total order value exceeds the threshold but the eligible subtotal does not. That fourth case tests whether the code uses the right input, not merely the right comparison operator.
| Eligible subtotal | Expected eligibility | Purpose |
|---|---|---|
| 9,999.99 | Not eligible | Immediately below |
| 10,000.00 | Eligible | Inclusive boundary |
| 10,000.01 | Eligible | Immediately above |
| 9,500.00, with excluded items taking the total above 10,000 | Not eligible | Correct basis for the decision |
Review the generated tests as code
Give the assistant the agreed examples and relevant test conventions, then inspect its output. Does the test invoke the real function? Does it assert the business result? Does its setup bypass a validation step that production relies on? A test that mocks the discount calculation and checks the mocked answer does not establish the calculation’s correctness.
Read test names alongside assertions. ‘Applies discount at threshold’ is misleading if the supplied amount is above the threshold. Look for assertions that repeat the implementation’s formula instead of a fixed, independently derived result. That pattern can reproduce the same defect in the expected value.
Temporarily change the inclusive comparison to an exclusive one in a local test branch. The boundary test should fail. Restore the code afterwards. This small fault-injection exercise is a recommended review practice; it is not a product feature or evidence that the entire test suite is sufficient.
Keep rule changes reviewable
A pricing rule can change after the first test is accepted. Record the requirement reference and the reason for the example values so a later developer can distinguish an intended policy change from an accidental edit. Do not use a generated explanation as the authority for a commercial decision.
When a proposed change alters eligibility, ask the product owner to review the examples again. Include the support team if the change affects how disputed orders are explained. The useful handover is a small set of understandable cases with agreed results, alongside the implementation and its checks.
For a team lab, have one pair write the rule and expected cases, and another pair review the generated tests without seeing the implementation first. Compare their interpretation at the boundary. The exercise builds the judgement needed to challenge plausible code. Keep repository access and coding-assistant governance in the existing governance process; this article adds requirement review rather than another licence-control checklist.
Sources & further reading (1)
Historical evidence checked . Review practices and hypothetical exercises are editorial recommendations, not product guarantees.
