mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-08-06 17:36:53 +01:00
75 lines
2.9 KiB
Markdown
75 lines
2.9 KiB
Markdown
---
|
|
bc-version: [all]
|
|
domain: testing
|
|
keywords: [test, refactor, adapt, existing-code, green, failing, tdd]
|
|
technologies: [al]
|
|
countries: [w1]
|
|
application-area: [all]
|
|
---
|
|
|
|
## Description
|
|
|
|
When a CURABIS developer asks for a test that "must work" or "must pass",
|
|
the agent's job is to write a test that passes against the **existing production code**
|
|
— not to write an idealized test and then report that the code needs changing.
|
|
|
|
This rule applies in two distinct scenarios:
|
|
|
|
**Scenario A — New test for existing behaviour**
|
|
The production code is correct and stable. Write the test to match what the code
|
|
actually does. Read the relevant codeunits before writing assertions. If the
|
|
expected value in the story differs from what the code produces, surface the
|
|
discrepancy and ask before assuming either is wrong.
|
|
|
|
**Scenario B — Refactoring an existing test**
|
|
The test exists but fails because the production code was changed. Adapt the
|
|
test to match the new behaviour. Do not rewrite the production code to make
|
|
the old test pass unless explicitly asked to refactor production code.
|
|
|
|
## The distinction that matters
|
|
|
|
Writing a test that adapts to existing code is **not** the same as writing a
|
|
test that accepts wrong behaviour silently. If the production code contains a
|
|
bug that contradicts the business specification, flag it explicitly:
|
|
|
|
```
|
|
// ⚠️ NOTE: This assertion reflects current code behaviour.
|
|
// Business spec says 1792,00 but code currently produces 1800,00.
|
|
// Flagged for review — do not merge until resolved.
|
|
```
|
|
|
|
Never silently adjust an assertion to make a test green when the discrepancy
|
|
is a real business logic error.
|
|
|
|
## Anti Pattern
|
|
|
|
```al
|
|
// WRONG: Writing the "ideal" test without reading the production code,
|
|
// then leaving it failing and saying "the code needs to be fixed"
|
|
[THEN]
|
|
Assert.AreEqual(1792, ActualAmount, 'Total should be 1792');
|
|
// Test fails. Agent says: "You need to fix SVPost to produce 1792."
|
|
// This is not what was asked for.
|
|
```
|
|
|
|
## Best Practice
|
|
|
|
```al
|
|
// CORRECT: Read SVPost, understand what it produces, write the test to match.
|
|
// If the number is 1792 in both spec and code → assert 1792.
|
|
// If the number differs → flag it, don't silently change it.
|
|
|
|
// [GIVEN] Read SVPost.Codeunit.al and SV Test Library before writing assertions.
|
|
// [THEN] Assert what the code actually produces, verified by reading the source.
|
|
Assert.AreEqual(ExpectedAmount, ActualAmount, 'Net payout to vendor must match');
|
|
```
|
|
|
|
## Workflow when asked to write a passing test
|
|
|
|
1. Read the relevant production codeunits (SVPost, SVApplyMgt, etc.)
|
|
2. Trace the calculation path for the specific scenario
|
|
3. Derive the expected values from the code — not only from the story
|
|
4. If code and story agree → write the test with those values
|
|
5. If code and story disagree → write the test with the code's values AND add
|
|
a clearly visible `// ⚠️ NOTE` comment explaining the discrepancy
|
|
6. Never leave a test failing when the task was to write a passing test
|