# 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:

```markdown
# 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 <N> Testfällen. GO / Feedback?"**
- On feedback: revise and increment version

### 7. Store in BigMind

```python
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