test-discipline

Align test assertions with API changes and disk state in the same commit.

Updated Jan 5, 2026
One-click install
npx skills add https://github.com/Golnaz89/golnaz89.github.io --skill test-discipline-golnaz89
Or copy as Structured Prompt for Agentβ–Ό
Please help me install this Agent Skill.
Skill: test-discipline
Source: https://github.com/Golnaz89/golnaz89.github.io/tree/main/.copilot/skills/test-discipline
Command: npx skills add https://github.com/Golnaz89/golnaz89.github.io --skill test-discipline-golnaz89

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

When APIs or public interfaces change, tests must be updated in the same commit. When test assertions reference file counts or expected arrays, they must be kept in sync with disk reality. Stale tests block CI for other contributors.

Core Features & Use Cases

  • API changes β†’ test updates (same commit): If you change a function signature, public interface, or exported API, update the corresponding tests before committing
  • Test assertions β†’ disk reality: When test files contain expected counts (e.g., EXPECTED_FEATURES, EXPECTED_SCENARIOS), they must match the actual files on disk
  • Add files β†’ update assertions: When adding docs pages, features, or any counted resource, update the test assertion array in the same commit
  • CI failures β†’ check assertions first: Before debugging complex failures, verify test assertion arrays match filesystem state

Examples

βœ“ Correct:

  • Changed auth API signature β†’ updated auth.test.ts in same commit
  • Added distributed-mesh.md to features/ β†’ added 'distributed-mesh' to EXPECTED_FEATURES array
  • Deleted two scenario files β†’ removed entries from EXPECTED_SCENARIOS

βœ— Incorrect:

  • Changed spawn parameters β†’ committed without updating casting.test.ts (CI breaks for next person)
  • Added built-in-roles.md β†’ left EXPECTED_FEATURES at old count (PR blocked)
  • Test says "expected 7 files" but disk has 25 (assertion staleness)

Anti-Patterns

  • Committing API changes without test updates ("I'll fix tests later")
  • Treating test assertion arrays as static (they evolve with content)
  • Assuming CI passing means coverage is correct (stale assertions can pass while being wrong)
  • Leaving gaps for other agents to discover

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 with API changes in the same commit?β–Ό

To keep test assertions aligned with API changes, you must update corresponding tests in the same commit. This enforces precise maintenance by detecting mismatches between expected arrays and disk reality, preventing stale tests from blocking CI.

Why do stale test assertions block CI when public interfaces change?β–Ό

Stale test assertions block CI because expected counts or arrays in test files no longer match the actual files on disk. When API signatures or exported interfaces change without updating tests, the mismatch creates blockers for other contributors.

What is the best way to update test assertions when adding files to a repository?β–Ό

The best way to update test assertions when adding files is to modify the expected arrays in the same commit. If you add a new resource file, you must add its entry to the corresponding expected array to maintain disk reality and prevent CI failures.

How do I fix CI failures caused by mismatched expected arrays and filesystem state?β–Ό

To fix CI failures caused by mismatched expected arrays, verify test assertion arrays against the filesystem state first. Surface actionable diffs to detect mismatches and update the expected counts to reflect disk reality before debugging complex failures.

Can I commit API changes without updating the corresponding test files?β–Ό

Committing API changes without updating corresponding test files is an anti-pattern that breaks CI. You must update test references in the same commit to reflect disk reality, avoiding gaps where stale assertions pass while being wrong.

When should I update test assertions referencing expected file counts?β–Ό

You should update test assertions referencing expected file counts whenever public interfaces change or files are added or deleted. Treating assertion arrays as evolving content ensures they match disk reality and prevents CI blockers for other contributors.