Menu
Test writing guide — one assertion per behavior, test contracts not implementation, arrange-act-assert, mocking strategy.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Recognizing context pressure before it degrades output quality.
Writing implementation plans — small testable steps, dependency ordering, upfront risk identification.
Evidence before claims, always — run verification commands and confirm output before making any completion or success claims.
Generate Architecture Decision Records — use when asked to document a decision, create an ADR, record why we chose X, or capture architectural rationale.
Generate a structured changelog from git history — use when asked to create a changelog, release notes, or summarize what changed between versions/tags/branches.
How to write pikit workflow YAML files — steps, loops, branches, interpolation.
| name | writing-tests |
| description | Test writing guide — one assertion per behavior, test contracts not implementation, arrange-act-assert, mocking strategy. |
Every test has three parts:
// Arrange — set up the preconditions
const cart = new Cart();
cart.addItem({ name: "Widget", price: 10 });
// Act — do the thing being tested
const total = cart.calculateTotal();
// Assert — verify the result
expect(total).toBe(10);
Keep each section short. If arrange is 20 lines, extract a helper. If you need multiple act+assert blocks, write multiple tests.
Each test verifies one behavior. Not one function — one behavior.
// Good: each test checks one thing
test("rejects empty username", () => { /* ... */ });
test("rejects username with spaces", () => { /* ... */ });
test("accepts valid username", () => { /* ... */ });
// Bad: multiple behaviors in one test
test("validates username", () => {
expect(validate("")).toBe(false);
expect(validate("has space")).toBe(false);
expect(validate("valid")).toBe(true);
});
When a test fails, you should know exactly what broke from the test name alone.
Tests should verify what a function does, not how it does it.
Mock these:
Don't mock these:
Prefer real dependencies when practical. Mocks test that you call things correctly; real dependencies test that things actually work.
Use names that describe the scenario and expected outcome:
"returns empty array when no items match filter"
"throws when called with negative amount"
"sends notification email after order is placed"
If you can't name the test clearly, you may not understand the requirement yet.