dd5637b1db
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>
2.7 KiB
| bc-version | domain | keywords | technologies | countries | application-area | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
testing |
|
|
|
|
CURABIS Test Data Guidelines
Description
"CURABIS tests assume an empty database. All test data must be created programmatically — never assume existing records or hardcode codes, numbers, or names that may or may not exist in a given environment."
Three Mandatory Rules
Rule 1: Leverage Microsoft Libraries
Use built-in setup codeunits (Library - ERM, Library - Inventory, Library - Sales) for standard Business Central objects like no-series, G/L accounts, customers, and items. These generate collision-free random codes.
Rule 2: Complete All Required Fields
Every mandatory field must receive a value. A Code[10] field requires 10 random characters; Text[50] needs randomized text. Partial setups violating this principle are prohibited.
Rule 3: Create Custom Procedures for Domain-Specific Tables For CURABIS-exclusive tables, build dedicated setup functions in Test Library following Microsoft's patterns: programmatic creation with random values unless the test documents a fixed contract requirement.
Critical Exception
Integration and flow tests validating external contracts (JSON structures, EDIFACT messages, counterparty codes) may use hardcoded values. These tests document the integration specification itself, not arbitrary test logic.
Anti-Patterns to Avoid
- Conditional hardcoded lookups assuming pre-existing data
- Shortened field values not matching declared field length
- Underfilled required fields
Implementation Example
Generate randomized payment method codes via LibraryUtility.GenerateRandomCode() rather than assuming 'CASH' exists. Create source codes through LibraryERM.CreateSourceCode() and retrieve no-series using LibraryUtility.GetGlobalNoSeriesCode().
BCApps Reference
The randomization helpers central to this rule — LibraryUtility.GenerateRandomCode(), LibraryERM.CreateSourceCode(), LibraryUtility.GetGlobalNoSeriesCode() — are implemented and maintained in BCApps. BCApps test code never hardcodes record identifiers like 'CASH', '10000', or '70000'; all test data is generated programmatically.
- Source: https://github.com/microsoft/BCApps/tree/main/src/Tools/Test%20Framework
- Pattern: BCApps test codeunits create every required record from scratch using library helpers that guarantee uniqueness per test run. The CURABIS rule mirrors this approach exactly.
- Note: The
BCPTCreateSOWithNLines.Codeunit.alsample in BCApps usesCustomer.get('10000')as a fallback — this is a BCPT performance scenario (not a correctness test) and explicitly acknowledges this deviation. Correctness tests must never do this.