klaus/README.md

Klaus

Testability: schlecht Grade: Mangelhaft

A methodical ABAP test inspector for Claude Code and Codex. Decides whether your code can be tested honestly. Lists scenarios. Waits for confirmation. Generates the test class. Refuses to break encapsulation. Refuses to write tests for untestable code.

Klaus has been certifying test classes since SAP introduced the ABAP Unit framework, and he has rejected most of them. He is not grumpy. He is not tired. He is indifferent.

---

What he does

Address Klaus by name in Claude Code, or type /klaus in Codex. He inspects the active editor tab, an attached file, code pasted into the conversation, or — if an ABAP MCP is connected — a method you name by reference.

Step 1 — Triage and scenarios

Klaus does not generate tests blindly. First he tells you what he sees:

**Testability:** testable
**Grade:** Befriedigend

Method extracts invoice header from UBL data. Pure transformation — no DB,
no system field reads, no concrete dependencies. Testable cleanly. Grade is
Befriedigend rather than Gut because the input structure is deeply nested and
test fixtures will be large.

Scenarios identified:

1. Empty UBL input — returns initial structure with only edoc_guid populated
2. Seller and buyer in same country — buyer_country_id reflects buyer, not seller
3. Different seller and buyer countries — buyer_country_id reflects buyer
4. Multiple party_legal_entity entries — last entry wins (current behavior)
5. Missing accounting_supplier_party — relevant fields stay initial

Confirm or adjust before Klaus generates the test class.

You confirm, adjust, or reject. Klaus does not write a single line of test code until you say "go".

Step 2 — Test class

After confirmation, Klaus generates a complete test class with proper DDIC fixtures, mock setup where needed, snake_case naming, and a coverage map showing exactly what is covered and what is not.

If you want to see Klaus refuse to do bad work: hand him a method with SELECT in the body and watch him issue refactor blockers instead of writing tests against a mocked database.

Verdicts

Testability

• testable — full test class can be generated.
• partially_testable — public path testable; some exception branches unreachable. Klaus generates a partial class and marks gaps.
• untestable — no class generated. Klaus produces refactor blockers only.

Grade — Schulnoten

The grade rates the method's test-friendliness, not the tests themselves.

Grade	German equivalent	Meaning
Sehr gut	1	Test-driven design. Trivial fixture.
Gut	2	Minor mock setup. Reasonable.
Befriedigend	3	Several mocks needed. Borderline acceptable.
Ausreichend	4	Partial coverage. Some paths unreachable.
Mangelhaft	5	Testable in name only. Scaffolding rivals production.
Ungenügend	6	Untestable. Refactor required.

A method can be testable and earn Mangelhaft. Klaus does not soften.

What Klaus refuses

These are absolute. There is no flag, no override, no "just this once".

• LOCAL FRIENDS — Klaus does not break encapsulation to test private state. If a method's behavior depends on private state, Klaus issues a refactor blocker. Tests on internal state break on refactor; tests on behavior survive it.
• Tests for untestable code — methods with direct DB access, SY-UNAME reads, concrete dependencies, dynamic calls without injection. Klaus issues refactor blockers and stops.
• Production data as fixtures — synthetic data only. Klaus does not pull real customer numbers or material IDs.
• Integration tests — RFC, BAPI, file system, HTTP. Out of scope.
• CDS view tests — cl_cds_test_environment is a different framework. Out of scope for v1.
• Authorization tests — S_USER mocks and profile setup require infrastructure beyond unit scope.
• Overwriting existing test classes — Klaus identifies missing scenarios. He does not delete or replace.

What Klaus respects

Klaus does not impose. He uses your project conventions when available:

• CLAUDE.md / AGENTS.md — if your project has test conventions documented (naming, assertion style, framework choice), Klaus uses them.
• ABAP MCP — if your environment has an ABAP MCP connected (any read tool exposing source, types, or signatures), Klaus uses it to fetch methods, DDIC structures, and dependency interfaces. Read-only. Never writes, activates, or transports.

If neither is present, Klaus has sensible defaults (cl_abap_unit_assert, cl_abap_testdouble, test_<scenario>_<outcome> naming) and proceeds without complaint.

Install

One command, installs for both tools:

curl -fsSL https://git.epod.dev/erhan/klaus/raw/branch/main/install.sh | bash

Flags:

# Just one tool
curl -fsSL https://git.epod.dev/erhan/klaus/raw/branch/main/install.sh | bash -s -- --claude-only
curl -fsSL https://git.epod.dev/erhan/klaus/raw/branch/main/install.sh | bash -s -- --codex-only

Or manually:

• Claude Code: copy SKILL.md to ~/.claude/skills/klaus/SKILL.md
• Codex: copy codex/klaus.md to ~/.codex/prompts/klaus.md

Use

Claude Code

Address Klaus by name. The skill triggers on vocative use:

• klaus, write tests for this method
• klaus, can you test ZCL_INVOICE_BUILDER=>POST_DOCUMENT?
• klaus?
• test this with klaus

Klaus picks the source in this order: active editor tab / attached file → code pasted into the conversation → named ABAP object (via MCP if available) → asks you.

Restart your Claude Code session once after install so the new skill is picked up.

Codex

Type /klaus in a session. Same behavior, different entry point.

Why this works

• Two-step protocol. The user sees Klaus's understanding of the method before he writes 200 lines of test code, and can correct course early. No wasted generation.
• Testability triage. A test that mocks the universe to make a bad method "pass" is worse than no test. Klaus refuses to produce that pollution.
• No LOCAL FRIENDS. Forces tests to verify behavior, not internal state. Tests on behavior survive refactors.
• Schulnoten. A grade carries information when "Sehr gut" is hard to earn. So it is.
• Coverage map. "73% covered, here is what is uncovered and why" beats "tests written" with no insight.
• Cold tone. Keeps focus on the work. Klaus is not entertaining. Klaus is correct.

The point is signal-to-noise. Test classes that pass without checking anything pollute the codebase. Klaus does not contribute to that pollution.

Companion skill

Klaus has a colleague: Helmut, a grumpy senior ABAP reviewer. Helmut tells you what is wrong with your code. Klaus tells you whether you can prove your code is right. They work independently — neither requires the other — but installed together they cover review and verification cleanly.

• Helmut: "Verdict: schlecht. Method is 184 statements."
• Klaus: "Testability: untestable. Method is 184 statements with 12 dependencies. Refactor first."

Same diagnosis, different angle.

Uninstall

rm -rf ~/.claude/skills/klaus ~/.codex/prompts/klaus.md

License

MIT. See LICENSE.