Esp32 Test Plan

ESP32 Test Plan

Generate a comprehensive test plan covering all applicable testing layers for a firmware change.

When to Use

• After an implementation contract is accepted.
• Before starting implementation.
• When adding test coverage to existing code.

Steps

1. Classify the Change

Determine which testing layers apply:

| Layer | Applies When | Tools | |-------|-------------|-------| | Repository logic | Change involves Python tooling or templates | pytest | | Host-side logic | Change involves pure C logic (parsers, state machines, encoders) | pytest + native compilation | | ESP-IDF unit tests | Change modifies an isolated component | ESP-IDF unity framework | | Target integration | Change requires real hardware validation | pytest-embedded | | Static analysis | Always | cppcheck, compiler warnings |

2. Identify Test Cases

For each applicable layer, list specific test cases:

Positive cases: Expected behavior with valid inputs. Negative cases: Behavior with invalid inputs, null pointers, edge values. Boundary cases: Limits of buffers, ranges, timeouts. Concurrency cases: Race conditions, shared state under load. Error cases: Failure paths, recovery behavior.

3. Define Test Infrastructure

Specify what is needed:

• New test files to create.
• Fixtures or mocks required.
• Test data or configuration.
• Hardware requirements (if any).

4. Set Pass/Fail Criteria

For each test case:

• Expected result.
• Acceptable tolerance (for timing or analog tests).
• Required evidence (log output, assertion pass, measurement).

5. Generate Test Plan Document

Use the template at missions/templates/test_plan_template.md:

# Test Plan: [Feature Name]

## Change Reference
- Contract: [link to implementation contract]
- Mission: [link to mission file]

## Test Layers

### Layer 1: Repository Logic
| Test Case | Input | Expected Output | Status |
|-----------|-------|-----------------|--------|

### Layer 2: Host-Side Logic
| Test Case | Input | Expected Output | Status |
|-----------|-------|-----------------|--------|

### Layer 3: ESP-IDF Unit Tests
| Test Case | Component | Expected Behavior | Status |
|-----------|-----------|-------------------|--------|

### Layer 4: Target Integration
| Test Case | Setup Required | Expected Behavior | Status |
|-----------|---------------|-------------------|--------|

## Infrastructure Requirements
- [ ] [Requirement]

## No-Hardware Tests
[List tests that can run without ESP32 hardware]

## Hardware-Required Tests
[List tests that need real hardware, marked with pytest `@pytest.mark.hardware`]

## Coverage Goals
- Statement coverage target: [X%]
- Branch coverage target: [X%]
- Critical paths that MUST be covered: [list]

Rules

1. Every implementation contract must have a test plan. No exceptions.
2. Maximize no-hardware tests. Extract and test pure logic separately.
3. Mark hardware tests explicitly. Use @pytest.mark.hardware so CI can skip them.
4. Include negative tests. Happy-path-only testing is insufficient for firmware.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: agodianel
• Source: agodianel/esp32-claude-workbench
• License: MIT

Install and usage instructions live in the source repository linked above.