principle-test-behavior-not-implementation

Rewrites tests to assert observable behavior against literal expected values instead of implementation details.

1|Updated Aug 26, 2026
One-click install
npx skills add https://github.com/edivad1999/stuc-stack --skill principle-test-behavior-not-implementation-edivad1999
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-test-behavior-not-implementation
Source: https://github.com/edivad1999/stuc-stack/tree/main/skills/principle-test-behavior-not-implementation
Command: npx skills add https://github.com/edivad1999/stuc-stack --skill principle-test-behavior-not-implementation-edivad1999

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Test suites accumulate tests that cannot fail for a defect: assertions on mock calls, restated constants, or self-referential comparisons that still pass when every imported function returns undefined. These tests waste CI time and review attention while catching nothing. ## Core Features & Use Cases - Behavior Check: Applies a single litmus test—would this test still pass if every imported function returned undefined?—to decide whether a test observes real behavior. - Five Anti-Pattern Detection: Identifies weak assertions, mock-only verification, self-referential expectations, constant pins, and fixture-asserts-fixture shapes. - Concrete Fixes: Rewrites each anti-pattern into a call with one concrete input asserting a literal output, or deletes the test when no such assertion exists. - Use Case: While reviewing a Kotlin pull request, you find verify { repo.save(any()) } with no asserted state; the Skill directs you to assert the state after the call or remove the test. ## Quick Start Review the tests in this change and rewrite or delete any that would still pass if every imported function returned undefined.

Frequently Asked Questions about principle-test-behavior-not-implementation

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

FAQPage Schema
How do I test behavior instead of implementation?▼

Call the code the way its users do and assert the observed result against a literal expected value, such as expect(slugify("Hello, World!")).toBe("hello-world"). Avoid asserting which internal calls were made or restating constants the code contains.

How to tell if a test is useless?▼

Ask whether the test would still pass if every function it imports returned undefined. If yes, it observes no behavior and cannot fail for a defect, so rewrite the assertion or delete the test.

Is verify with mockk or Mockito a good assertion?▼

A bare verify { repo.save(any()) } with no asserted state does not observe behavior. Assert the payload the mock received or the state after the call, not merely that the call happened.

Should I test constants and config values?▼

Do not restate a constant in an assertion, since that only fails when someone edits the constant. Instead test the mechanism that reads the constant with one concrete input.

When is it acceptable to keep a non-behavioral test?▼

Keep tests of a relation across table rows, such as a key present in two tables or an existing parent, and compile-time checks in *.test-d.ts files. Everything else must assert observable behavior or be deleted.