Skill: F Prime Component Unit Testing

Unit tests verify each component requirement in isolation using the autocoded test harness. This skill provides lifecycle context and goals; for scaffolding, assertion macros, code patterns, and the full implementation procedure, see fprime-unit-testing and the unit testing guide.

Goals

• Verify all requirements with unit tests if possible.
• Verify all interfaces: ports, events, telemetry, commands.
• Prefer rule-based testing where possible — it provides broader coverage than traditional tests. See fprime-unit-testing §3 for criteria and constructs, and the rules-based testing guide for the full walkthrough.
• Target 95% code coverage.
• You should be able to do most of this without user input, since requirements and the FPP model are already defined. However, ask the user for help with predicting edge cases you may have missed or for clarification on expected behavior.

Process

Follow fprime-unit-testing for the step-by-step procedure: scaffold → implement → register → run. That skill covers Tester class structure, TestMain layout, CMakeLists registration, assertion macros, helper functions, and rules-based testing.

Key decisions within the lifecycle:

1. Traditional vs. rule-based: Use the criteria table in fprime-unit-testing §3. Default to rule-based for components with multiple ports or stateful behavior.
2. TDD: If following test-driven development (tests before implementation), see TDD guide. The FPP model is sufficient to write tests — implementation is not required.
3. Coverage: Run fprime-util check --coverage and review *_gcov.txt. Target 95%.

Anti-Patterns

• Testing only happy paths — off-nominal coverage is critical
• Forgetting doDispatch() for async commands/ports
• Asserting only on count (SIZE) without checking values
• Modifying component internals directly (test through the interface only)
• Guessing expected values — derive from requirements