principle-test-behavior-not-implementation

Rewrites or deletes tests that assert implementation details instead of observable behavior.

Updated Aug 28, 2026
One-click install
npx skills add https://github.com/jeremybrasher/grokbot-skills --skill principle-test-behavior-not-implementation-jeremybrasher
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: principle-test-behavior-not-implementation
Source: https://github.com/jeremybrasher/grokbot-skills/tree/main/collections/pstack/skills/principle-test-behavior-not-implementation
Command: npx skills add https://github.com/jeremybrasher/grokbot-skills --skill principle-test-behavior-not-implementation-jeremybrasher

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Test suites accumulate tests that cannot fail for a real defect: assertions on mock calls, restated constants, or self-referential comparisons. These tests cost CI time and review attention while catching nothing, and constant pins actively block legitimate edits. ## Core Features & Use Cases - Dead-Test Detection: Applies a single check — would this test still pass if every imported function returned undefined? If yes, it observes no behavior. - Five Failure Shapes: Identifies weak assertions (toBeDefined, toBeTruthy), mock-only assertions (toHaveBeenCalled), self-referential expectations, constant pins, and fixture-asserts-fixture patterns. - Concrete Fixes: Rewrites tests to call the subject with one concrete input and assert a literal output, or deletes the test when no behavioral assertion exists. - Use Case: While reviewing a pull request, you find expect(LIMITS.maxTools).toBe(8). This Skill directs you to test the mechanism that reads the limit with one input instead of restating the value. ## Quick Start Review the tests in my latest commit 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 in unit tests?▼

Call the code the way its users do and assert the observable 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 detect tests that cannot fail for a real defect?▼

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.

Are toHaveBeenCalled assertions enough for mock testing?▼

No. Asserting only that a mock was called verifies no behavior. Instead assert the payload the mock received or the state after the call, so the test fails when the actual behavior breaks.

Should I write tests that assert constant or config values?▼

No. A constant pin like expect(LIMITS.maxTools).toBe(8) restates the value and blocks legitimate edits. Test the mechanism that reads the constant with one concrete input instead of restating the value itself.

When should I keep a test that does not assert literal outputs?▼

Keep tests of relations across table rows, such as a key present in two tables or an existing parent record, and compile-time checks in *.test-d.ts files. These verify real constraints even without literal output assertions.