Install any skill in seconds. Free to start, no credit card required.
Get Started Free →cursor/principle-test-behavior-not-implementation
Apply when you write, change, or keep a test. Call the code the way its users do and assert the result they observe against a literal expected value. If the test would still pass when every imported function returns undefined, rewrite the assertion or delete the test.
Passed 21 of 24 test cases with the skill, and 17 of 24 without it.
and 2 more in the full report
4 fixed17 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
In `AgentPrompt.test.ts`, the test suite has: ```ts test('system prompt content', () => { expect(SYSTEM_PROMPT_TEMPLATE).toContain('You are an AI assistant helping with customer support'); }); ``` The developer wants to ensure the prompt text isn't changed accidentally. Evaluate this test and state what should be done.
| Checked | Without skill | With skill |
|---|---|---|
| Rejects asserting prompt string contents directly in test assertions | Missed | Passed |
| Recommends testing the prompt template mechanism with concrete inputs | Missed | Passed |
The instructions your model reads when the skill loads.
A test is a claim about what the code does for its users: a caller, an end user, or another service. Behavior is what those users can observe through the interface they use. That includes return values, errors, state they can read back, and effects on systems outside the code, such as a request sent, a row written, or a message emitted. Implementation is what they cannot observe: private helpers, internal call order, intermediate data, and which internal collaborator did the work.
Judge each test against two imagined edits:
Keep a test that catches the first edit and survives the second. Rewrite or delete the rest. To write a test that does both, drive the code through its users' interface with a concrete input. Derive the expected value from the requirement, not from a run of the code. Assert what the contract promises, no less and no more.
The contract decides, not the shape of the assertion. When "an empty cart never charges" is the promise, an assertion that the payment client got no call is behavior. Pair it with a case where the charge happens, so that the test shows it can see a call. The payload that a mocked external service receives is behavior, because that service observes it. A call to an internal helper is implementation, because no user can see it. An empty list is the exact answer when no record matches, and a hollow check when the test only needs some result. An exact error message pins wording that no caller reads. The error type that callers branch on is the contract.
A test can pin an invariant instead of a call, such as a key that must exist in two tables or a compile-time type check. The invariant is the behavior.
test cases passed, vs 17 / 24 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.