Start from a business statement
“A refund cannot exceed the captured payment” is more useful than “test the refund function.” It states a constraint independently of the implementation. Name the object, the permitted change and the condition. Add examples around the boundary, including zero values and repeat requests when relevant. The statement should be understandable to the owner who approves it, not only to a developer reading the code.
Do not turn every old behavior into a rule
Legacy software is evidence of what currently happens, not proof of what ought to happen. An accidental discount or an over-permissive endpoint should not become a protected requirement merely because it exists. Separate observed behavior from owner-approved intent. When they differ, record whether the project preserves the behavior for compatibility or deliberately corrects it.
Connect rules to several kinds of evidence
One rule may need a unit check for a calculation, an integration check for persistence and an authorization check for who may invoke it. A browser scenario can then demonstrate the user journey. Avoid a requirement-to-test count as the only quality measure: ten assertions that repeat the same assumption can miss the forbidden path. Choose evidence that attacks the actual failure modes.
Protect the meaning when tests change
Tests may need maintenance, but the implementation must not silently weaken an approved business rule to pass. Review the reason for changed expectations and bind the new suite to the approved rule version. Forge’s Product knowledge and Rehearsal are designed to connect these decisions, so a green test result remains interpretable rather than detached from the owner’s intent.
Define the rule before asking the agent to verify it
Suppose a booking can be cancelled only by its owner or an authorized operator. A test generated from the existing controller may simply reproduce its current permission logic. If that logic is wrong, the test can become a reassuring description of the defect. Start from the approved business rule and independent examples instead.
Ask who may act, on which object and in which state. Add a permitted case, a forbidden case and a boundary case such as an already cancelled booking. Attach the rule’s source and owner decision. The test is then a translation of intent into evidence, not the origin of the intent.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Actor | Only authorized roles may cancel. | Allowed and denied sessions. |
| Object | The booking belongs to the permitted scope. | Cross-customer and cross-office negatives. |
| Repeat | A repeated event has no second effect. | Replay with the same operation identifier. |
Where this goes wrong
An owner can approve an intentional rule change, but that decision must be distinct from a Developer trying to make a failing test pass. Preserve the prior rule and evidence. Review what other Projects or releases depend on it before treating the amendment as local to one screen.
The test is evidence for a rule, not the authority that invents the rule.
Turn it into a working checklist
- Write owner-readable constraints.
- Separate observed and intended behavior.
- Include forbidden and boundary cases.
- Review changed test expectations.
A concrete next step
Create a rule card with statement, owner, scope, examples and linked scenarios. Unknown behavior remains an open question until confirmed. This small discipline is more valuable than a large suite whose expected results nobody has reviewed.
Watch a related case
The video could not be loaded. Try again later.