Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-06 15:16:56 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Custom-laget bestaar nu begge CI-checks: 72 validator-fejl -> 0

Browse source 
Normalisering af alle 39 custom knowledge-filer til READ-kontraktens
skema (validate_frontmatter.py + Test-KnowledgeIndex.ps1 begge groenne):

- R01/R02: 28 filer manglede frontmatter eller brugte aeldre skemaer
  (title/category/severity/rule-id m.fl.) - alle har nu praecis de 6
  kraevede noegler; keywords haandskrevet pr. fil da de driver
  worklist-selektionen i INDEX/knowledge-index
- R09: manglende Description-sektion - regel-agtige foersteoverskrifter
  (Core Rule/Rule/Regel/Core Principle) omdoebt, eller sektion indsat
  efter titlen hvor intro-tekst fandtes
- R10: fenced code blocks konverteret til 4-space indrykkede blokke
  i alle filer (indhold uaendret)
- R11: 4 filer over 100 linjer fortaettet redaktionelt uden semantisk
  tab (ai-eval-scores 143->100, git-lifecycle 121->97,
  permission-sets 113->99, test-feature-scenario-tags 105->91)
- R05: AL0197->al0197, add_repo->add-repo; keyword-lister trimmet
  til maks 10

Ingen regler er fjernet eller aendret i betydning - kun form.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Michael Dieringer 2026-07-01 23:47:31 +02:00
parent ec2892f0ab
commit dd5637b1db
39 changed files with 729 additions and 814 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -32,37 +32,31 @@ 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.
```
// ⚠️ 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.
```
// 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.
// 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');
```
// [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