pi_mcps/zoo_backup/work/rules/skills/skill-generate-testplan.md

Skill: generate-testplan

Structured test plan from implementation plan / assessment.

Invoked by

📋 Planner mode

Required Inputs

Input	Source	Example
TICKET_KEY	Jira issue key	ESIDEPAISY-12081
MODULE	PAISY module name	eau, eubp, svmeldungen
PLAN_PATH	Path to plan.md	docs/EAU/ESIDEPAISY-12081/ESIDEPAISY-12081-plan.md

Output

Markdown file: docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-testplan.md

Steps

1. Read the implementation plan

Read PLAN_PATH to understand:

• Which classes/methods are being added or modified
• Which data flows are affected
• Which database changes are involved (Flyway migrations, new tables/columns)
• Which integration points exist (ServiceCenter, NATS, external APIs)

2. Read the assessment (if exists)

Check for docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-assessment.md — extract risk areas that need extra test coverage.

3. Identify testable units

For each component in the plan:

Category	What to test	Test type
New methods	Input/output, edge cases, null handling	Unit
Modified methods	Regression + new behavior	Unit
Database changes	Migration up/down, data integrity	Integration
Data flows	End-to-end processing	Integration
PAISY interaction	ServiceCenter calls, pgm responses	SSH (manual)
Error paths	Invalid input, missing data, PAISY "F;" responses	Unit

4. Generate test plan document

Write docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-testplan.md with this structure:

# Testplan: <TICKET_KEY> — <Summary>

**Datum:** <today>
**Modul:** <MODULE>
**Autor:** Patrick Plate / Roo (Planner)
**Status:** Entwurf v1
**Basis:** <TICKET_KEY>-plan.md

---

## Testübersicht

| ID | Beschreibung | Typ | Klasse | Status |
|----|-------------|-----|--------|--------|
| T-01 | <short desc> | Unit | <TestClass> | ⬜ |
| T-02 | <short desc> | Unit | <TestClass> | ⬜ |
| T-03 | <short desc> | Integration | <TestClass> | ⬜ |
| T-nn | <short desc> | SSH | manuell | ⬜ |

Status: ⬜ Offen | ✅ Bestanden | ❌ Fehlgeschlagen | ⏭️ Übersprungen

---

## Testfälle

### T-01: <Descriptive name>

**Typ:** Unit
**Klasse:** `<package>.<TestClassName>`
**Methode:** `test<MethodName>()`

**Vorbedingungen:**
- <setup requirements>

**Szenarien:**

| # | Eingabe | Erwartetes Ergebnis |
|---|---------|-------------------|
| a | <input> | <expected> |
| b | <input> | <expected> |
| c | <edge case> | <expected> |

**Nachbedingungen:**
- <what to verify after test>

---

### T-02: <Descriptive name>
...

---

## Testdaten

<Describe any test data requirements, fixtures, or database setup needed.>

## Manuelle Tests (SSH)

| ID | Instanz | Programm | Eingabe | Erwartetes Ergebnis |
|----|---------|----------|---------|-------------------|
| T-nn | <instance> | <PAI program> | <input> | <expected> |

## Testabdeckung

| Komponente | Unit | Integration | SSH | Gesamt |
|-----------|------|-------------|-----|--------|
| <Class1> | 3 | 1 | 0 | 4 |
| <Class2> | 2 | 0 | 1 | 3 |
| **Summe** | **5** | **1** | **1** | **7** |

5. Cross-reference with plan

Verify every implementation step in the plan has at least one test case:

• New method → unit test
• Modified method → regression test
• Database migration → migration test
• Integration point → integration test or SSH test

Flag any gaps as warnings in the testplan.

6. Present to user

• Show the test overview table
• Explicitly ask: "Testplan v1 erstellt mit Testfällen. GO / Feedback?"
• On feedback: revise and increment version

7. Store in BigMind

memory_store_fact(
    category="codebase",
    fact=f"{TICKET_KEY}: Testplan with {N} test cases (Unit: {u}, Integration: {i}, SSH: {s})"
)

Test Naming Conventions

• Test class: <OriginalClass>Test.java or <Feature>Test.java
• Test method: test<What>_<Scenario>_<Expected>() or test<What>() for simple cases
• Location: mirror source structure under src/test/java/
• Base classes: extend existing test bases where available (e.g., EAUFlywayMigrationTestBase)

Test ID Format

• Sequential: T-01, T-02, ..., T-nn
• Prefix by type if needed: UT-01 (unit), IT-01 (integration), MT-01 (manual/SSH)
• IDs are stable — don't renumber on revision, append new tests at the end

Language

• Document content: German
• Test method names and code: English (Java convention)
• Scenario descriptions in the table: German