policyengine-test-writing

Define standardized test-writing practices for PolicyEngine projects with SKILL.md frontmatter.

2|Updated Mar 31, 2026
One-click install
npx skills add https://github.com/PolicyEngine/policyengine-skills --skill policyengine-test-writing
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: policyengine-test-writing
Source: https://github.com/PolicyEngine/policyengine-skills/tree/main/skills/technical-patterns/policyengine-test-writing-skill
Command: npx skills add https://github.com/PolicyEngine/policyengine-skills --skill policyengine-test-writing

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

PolicyEngine projects often require consistent, well-documented test practices across frontend apps, APIs, SDKs, and standalone tools. This skill standardizes how tests and fixtures are written to improve maintainability and coverage. Not for country model packages, which use YAML-based tests with their own conventions.

Core Features & Use Cases

  • Given-When-Then Naming: Test names follow the pattern test__given_X_condition__then_Y_occurs to promote readability and traceability.
  • One Test File Per Source File: Each source file gets a single corresponding test file, mirroring the source directory structure.
  • Fixtures Live Separately: Mocks, setup code, and data live in fixtures, keeping tests focused on Given-When-Then logic and expectations.
  • Test Edge Cases and Failure Paths: Cover happy paths, boundary values, error paths, nulls, and type coercion traps.
  • Structured Describe Blocks: Group tests by function under describe blocks to make coverage obvious.

Quick Start

Create a new skill directory with a SKILL.md frontmatter and implement test-writing conventions (Given-When-Then naming, fixture separation, and edge-case coverage) as described.

Frequently Asked Questions about policyengine-test-writing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write unit tests for PolicyEngine APIs and frontend apps?

Standardized test writing for PolicyEngine projects uses a Given-When-Then naming convention like test__given_X_condition__then_Y_occurs. This pattern improves readability and makes test logic traceable across frontend apps, APIs, and SDKs.

What's the best way to organize test fixtures for PolicyEngine SDKs?

Test fixtures for PolicyEngine SDKs belong in separate directories, keeping mocks and setup data away from test logic. This ensures tests remain focused on expectations and Given-When-Then logic without clutter.

Does PolicyEngine test writing support YAML-based tests for country model packages?

No, this test-writing skill excludes country model packages, which use YAML-based tests with their own separate conventions. It applies only to frontend apps, APIs, SDKs, and standalone tools.

How do I ensure edge-case coverage when writing integration tests for PolicyEngine tools?

Ensure edge-case coverage by testing happy paths, boundary values, error paths, nulls, and type coercion traps. Group these tests under structured describe blocks organized by function to make coverage obvious.

Why do my PolicyEngine test names lack traceability across source files?

Test names lack traceability when not following the Given-When-Then naming pattern. Using test__given_X_condition__then_Y_occurs and mirroring the source directory structure ensures each test is readable and traceable.