newrules

custom/knowledge/testing/tests-must-adapt-to-existing-code.md

@@ -0,0 +1,75 @@
+---
+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