test-discipline

Automates updating test assertions when APIs or interfaces change.

2|Updated Apr 14, 2026
One-click install
npx skills add https://github.com/rett-europe/opentreasury --skill test-discipline-rett-europe
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-discipline
Source: https://github.com/rett-europe/opentreasury/tree/main/.copilot/skills/test-discipline
Command: npx skills add https://github.com/rett-europe/opentreasury --skill test-discipline-rett-europe

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

When APIs or public interfaces change, tests must be updated in the same commit to keep the test suite aligned with code reality and CI feedback.

Core Features & Use Cases

  • Ensure test assertions reflect current disk state (counts, arrays, and resources) after API changes.
  • Prevent CI failures by maintaining synchronized tests across commits.
  • Provide a disciplined pattern for when to update tests during feature or API evolution.

Quick Start

Update corresponding test assertions in the same commit whenever an API or interface changes.

Frequently Asked Questions about test-discipline

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

FAQPage Schema
How do I keep test assertions aligned when API signatures change?

To keep test assertions aligned with API changes, you must update expected values in the same commit as the API evolution. This ensures disk state and tests stay synchronized to prevent CI failures.

Why do CI tests fail after updating public interfaces?

CI tests fail after public interface updates because expected values in test assertions no longer match the evolved API signatures. Updating test assertions alongside API changes in the same commit prevents these regression failures.

What is the best way to automate regression testing for API changes?

Automating regression testing for API changes requires a disciplined pattern of updating corresponding test assertions in the same commit. This maintains synchronized tests across feature evolution and ensures CI feedback reflects code reality.

Does this approach work for tests relying on file counts and arrays?

Yes, this approach specifically applies to codebases where tests rely on file counts, arrays, or feature lists. It requires tests to declare expected values so changes trigger corresponding updates to those assertions.

When should I update test assertions during feature evolution?

You should update test assertions during feature evolution whenever API signatures or public interfaces change. Applying test updates in the same commit as the API changes keeps the test suite aligned with code reality.

Do I need to declare expected values to keep tests synchronized?

Yes, tests must declare expected values to stay synchronized with evolving APIs. This requirement allows changes to trigger corresponding updates to those assertions, ensuring disk state and tests remain aligned.