test

What this skill does

# /test — Engineering Manager Orchestration

You are the **Test Engineering Manager**. You orchestrate 4 parallel test engineer agents to build a comprehensive AL test suite covering unit, integration, scenario, and edge case tests.

## Step 1: Task Slug Setup

Auto-generate a task slug from the current task context (or reuse an existing one if continuing work). Ensure the `.dev/<task-slug>/` directory exists.

```
mkdir -p .dev/<task-slug>/
```

## Step 2: Read Context

Read ALL implemented AL files and `.dev/<task-slug>/02-solution-plan.md` to understand:

- What objects exist (tables, codeunits, pages, enums, interfaces)
- What business logic is implemented
- What events are published/subscribed
- What workflows exist
- What validations are in place

Use Glob to find all `.al` files in `src/` or `app/`, then Read each one.

## Step 3: Identify and Categorize Test Scenarios

Analyze the implemented code and categorize every testable behavior into exactly 4 types:

| Type | What to Test |
|------|-------------|
| **UNIT** | Calculation methods, validation logic, data transformations, pure functions, individual business rules in isolation |
| **INTEGRATION** | Table-Codeunit interactions, event subscribers, multi-object workflows, API integrations, BC base app integration points |
| **SCENARIO** | Complete user workflows, UI to Logic to Database flows, real-world use cases, multi-step business processes, happy path scenarios |
| **EDGE CASE** | Null/empty inputs, boundary values (0, negative, MaxInt, MaxDecimal), error conditions, invalid data, concurrent access, special cases (currency rounding, date boundaries) |

Create a concrete list of specific test scenarios for each category. Be explicit — assign SPECIFIC scenarios, not just "write tests."

## Step 4: Assign Object ID Ranges

Assign non-overlapping ID ranges to avoid conflicts between the 4 engineers:

| Engineer | ID Range | Purpose |
|----------|----------|---------|
| Unit Test Engineer | 50100–50199 | Unit test codeunits |
| Integration Test Engineer | 50200–50299 | Integration test codeunits |
| Scenario Test Engineer | 50300–50399 | Scenario test codeunits |
| Edge Case Test Engineer | 50400–50499 | Edge case test codeunits |

Adjust ranges based on the project's `app.json` ID range and any already-used IDs. Check for conflicts before assigning.

## Step 5: Spawn 4 Test Engineer Agents IN PARALLEL

Use the **Agent tool** to spawn all 4 engineers simultaneously. Each agent receives:

1. Their specific section from `test-engineer-prompts.md`
2. The full list of implemented AL files (with paths)
3. Their assigned test scenarios (from Step 3)
4. Their assigned ID range (from Step 4)
5. The project's `app.json` context (name, ID range, dependencies)

**Model: sonnet** for all 4 agents.

Each agent prompt must include:
- The test scenarios assigned to them (specific, not vague)
- The AL files they need to read
- Their ID range
- The output path: `.dev/<task-slug>/` for any intermediate files
- Instruction to write test codeunits to the project's test directory (e.g., `test/` or `src/test/`)

## Step 6: Monitor Test Development

After agents complete, verify:

- **No ID conflicts** — scan all created test codeunits for duplicate IDs
- **All assigned scenarios covered** — diff assigned vs. implemented
- **Consistent patterns** — all use `[Test]` attribute, Arrange-Act-Assert, proper naming
- **No compilation issues** — check for obvious syntax problems

If agents asked technical questions (how to mock, which fixtures, which BC objects to use), answer them and re-dispatch.

## Step 7: Run bc-test on All Test Codeunits

```bash
bc-test -o .dev/<task-slug>/test-results.txt
```

- If **ALL passing** --> proceed to Step 9
- If **some failing** --> proceed to Step 8

Use `--failures-only` flag if you only need to see failures:
```bash
bc-test --failures-only -o .dev/<task-slug>/test-results-failures.txt
```

## Step 8: Iterate on Failures

For each failing test:

1. **Identify the owner** by test codeunit ID:
   - 50100–50199 --> Unit Test Engineer
   - 50200–50299 --> Integration Test Engineer
   - 50300–50399 --> Scenario Test Engineer
   - 50400–50499 --> Edge Case Test Engineer

2. **Dispatch fix** to the owning engineer with:
   - The failure message
   - The test codeunit file path
   - The production code it tests

3. **Re-run bc-test** after fixes

4. **Repeat** until ALL tests pass

**Do NOT present to the user until ALL tests pass.**

## Step 8.5: Run Test Adversary (MANDATORY)

Once all tests pass, invoke `/verify-tests`. It runs automatically in a forked sub-agent with clean context (`context: fork`) — no manual agent spawning needed.

Pass as arguments:
- Path to all production AL files
- Path to all test AL files
- Task slug (for output path: `.dev/<task-slug>/06-test-verification.md`)
- Path to `.dev/<task-slug>/02-solution-plan.md` if it exists

**Wait for the adversary to complete before proceeding.**

### If adversary finds CRITICAL or MAJOR issues:

1. Dispatch fixes to the owning test engineer (by ID range) with the specific finding
2. Re-run `bc-test` to confirm tests still pass
3. Re-run the adversary sub-agent (fresh context again)
4. Repeat until the adversary reports no CRITICAL or MAJOR issues

### If adversary finds only MINOR issues or none:

Proceed to Step 9. Note the adversary verdict in the test plan.

**Do NOT present to the user until the adversary clears the suite.**

## Step 9: Write Test Plan Document

Write `.dev/<task-slug>/05-test-plan.md` as YOUR synthesis (not agent output). Include:

```markdown
# Test Plan — <Task Name>

## Test Coverage Summary

| Category | Count | Codeunit IDs |
|----------|-------|-------------|
| Unit Tests | X | 50100, 50101, ... |
| Integration Tests | X | 50200, 50201, ... |
| Scenario Tests | X | 50300, 50301, ... |
| Edge Case Tests | X | 50400, 50401, ... |
| **Total** | **X** | |

## Test Codeunits Created

| ID | Name | Category | Scenarios Covered |
|----|------|----------|------------------|
| ... | ... | ... | ... |

## Key Test Scenarios

1. ...
2. ...
(5–10 most important scenarios)

## Test Execution Results

- Total tests: X
- Passed: X
- Failed: 0
- Execution time: Xs

## Coverage Analysis

### What's Covered
- ...

### What's NOT Covered (and Why)
- ...
```

## Step 10: Present to User

Use **AskUserQuestion** (BLOCKING):

> **Test Suite Complete**
>
> Created X test codeunits with Y individual tests.
> - Unit: A tests | Integration: B tests | Scenario: C tests | Edge Case: D tests
> All tests passing.
>
> Test plan written to `.dev/<task-slug>/05-test-plan.md`
>
> **Options:**
> - **Approve** — Test suite is complete
> - **Add More Tests** — Specify additional scenarios to cover
> - **Review Failures** — Re-examine any borderline tests
> - **Stop** — Halt testing

---

## Key Rules

1. **Assign SPECIFIC scenarios** to each engineer, never just "write tests for X"
2. **Never present failing tests** to the user — fix them first
3. **Use bc-test features**: auto-detect from `app.json`, `--failures-only`, `-o` for file output
4. **All 4 agents run in PARALLEL** — do not run sequentially
5. **ID ranges must not overlap** — verify before and after agent execution
6. **One test per behavior** — no multi-assertion mega-tests
7. **The adversary always runs** — Step 8.5 is not optional. "All tests pass" is not a quality signal on its own.