codecharter test

codecharter test <path> [options]

codecharter test führt eine Regel gegen eine Reihe kuratierter Code-Snippets aus und prüft, dass sie genau die Snippets meldet, die sie melden soll, und die übrigen in Ruhe lässt. Das ist der Regressionstest für Ihre .cgr-Regeln: Sie schreiben die Spec einmal, und jede spätere Änderung an der Regel wird gegen dieselben Erwartungen geprüft.

<path> kann sein:

• eine einzelne .cgr-Regel-Datei (die zugehörige .spec.md daneben wird verwendet),
• eine einzelne .spec.md-Datei (verwendet wird die gleichnamige .cgr-Regel-Datei im selben Verzeichnis, foo.spec.md testet also foo.cgr) oder
• ein Verzeichnis, in dem jede darin liegende Spec gefunden und ausgeführt wird. Regeln ohne .spec.md daneben werden stillschweigend übersprungen; sie werden nicht als Fehlschläge gemeldet.

Das .spec.md-Format

Eine Spec ist eine Markdown-Datei, die eine Regel mit Beispiel-Snippets verbindet. Sie hat zwei Abschnitte auf oberster Ebene:

• ## hits: Snippets, die die Regel melden muss. Erzeugt die Regel für eines davon kein Finding, schlägt die Spec fehl.
• ## misses: Snippets, die die Regel nicht melden darf. Erzeugt die Regel für eines davon ein Finding, schlägt die Spec fehl.

Eine Spec kann zusätzlich mit einer optionalen Titelzeile (# ...) und einem Intent-Blockzitat (> ...) beginnen, das in einer Zeile beschreibt, was die Regel durchsetzt; das Scaffold erzeugt beides.

Innerhalb jedes Abschnitts ist jedes Beispiel eine ###-Überschrift, gefolgt von einem csharp-Codeblock. Der Überschriftentext, eine beliebige kurze Beschreibung, ist das Label des Cases:

# repository-naming

## hits

### case: Klasse ohne Repository-Suffix
```csharp
public class UserStore
{
}
```

## misses

### case: korrekt benannte Klasse
```csharp
public class UserRepository
{
}
```

Der vollständige Text jeder ###-Überschrift ist das Label, mit dem die Test-Ausgabe auf genau das Snippet zeigt, das fehlgeschlagen ist (das Präfix case: im Beispiel oben ist eine Konvention, keine Pflicht). Der Codeblock muss das Sprach-Tag csharp tragen; Blöcke in anderen Sprachen werden ignoriert.

Beispiele

# Eine Regel gegen ihre Geschwister-Spec testen
codecharter test .codecharter/rules/repository-naming.cgr

# Eine Spec-Datei direkt testen
codecharter test .codecharter/rules/repository-naming.spec.md

# Jede Spec in einem Verzeichnisbaum finden und ausführen
codecharter test .codecharter/rules

Optionen

Exit-Codes

codecharter test ist CI-freundlich: der Exit-Code sagt einer Pipeline, ob die Specs durchgelaufen sind, ohne dass sie die Ausgabe parsen muss.

• 0: jeder Case in jeder Spec hat seine Erwartung erfüllt.
• 1: mindestens ein Case ist fehlgeschlagen (fehlender Treffer oder unerwarteter Treffer auf einem Miss). Auch eine Regel, die nicht parst, führt zu Exit-Code 1: alle ihre Cases werden als fehlgeschlagen gemeldet.
• 2: nichts zu testen, weil der angegebene Pfad nicht existiert oder keine .spec.md dafür gefunden wurde.
• 6: Lizenzfehler (fehlend, abgelaufen oder für diese CLI-Version nicht gültig).

Mit --scaffold bedeuten die Codes: 0 Skelett geschrieben, 1 es existiert bereits eine Spec (sie wird nicht überschrieben), 2 die Regel-Datei existiert nicht.

In VS Code

Die VS Code Extension (ab 0.5.0) kapselt denselben Test hinter Command-Palette-Befehlen:

• CodeCharter: Test rule spec: führt die Spec für die Regel im aktiven Editor aus.
• CodeCharter: Test all specs: findet und führt jede Spec im konfigurierten Regel-Verzeichnis aus (Einstellung codecharter.analyze.rulesDirectory, standardmäßig rules/ im Workspace-Root).
• CodeCharter: Scaffold spec for current rule: legt eine Start-.spec.md neben der aktuellen .cgr-Datei an, das Editor-Äquivalent zu --scaffold.

Die Ergebnisse erscheinen im Editor, sodass Sie direkt zum fehlgeschlagenen Case springen können.

Verwandt

• codecharter validate prüft, ob eine Regel parst; codecharter test prüft, ob sie den richtigen Code meldet.
• MCP-Regel-Authoring treibt denselben Treffer-Test über das Tool test_rule_spec aus einem KI-Assistenten heraus.