원클릭으로 Manus에서 모든 스킬 실행

test-design-heuristics

스타1

포크0

업데이트2026년 6월 17일 20:23

Use when deciding what to test for a change. Covers the test pyramid, risk-based prioritization, boundary and equivalence partitioning, the edge cases worth checking, and — just as important — what not to test.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

meaganewaller

meaganewaller/rosetta

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Test design heuristics

The goal of a test is to catch a regression that matters, cheaply. Optimize for signal per test, not for a coverage number.

Pick the level (the pyramid)

Unit — fast, many, isolated. Pure logic, branching, transformations. Most tests live here.
Integration — fewer. Real boundaries: a DB, a queue, an HTTP client, the file system. Test the seam, not the whole world.
End-to-end — fewest. One or two happy-path journeys that prove the pieces connect.

Push each behavior to the lowest level that can meaningfully exercise it.

Prioritize by risk

Test first where a bug would hurt most and is most likely: money, auth, data loss, irreversible actions, and the code that just changed. Don't spend the same effort on a log-formatting helper as on a payment path.

Find the cases

Equivalence classes — one representative per class of input, not every value.
Boundaries — 0, 1, n, n+1, max, just-over-max. Off-by-one lives here.
Empty / null / missing — empty list, null field, absent config, zero-length string.
Error paths — what happens when the dependency throws, times out, or returns garbage.
Idempotency & concurrency — only when the code is retried or runs in parallel.

What NOT to test

Framework or library internals — trust them; test your use of them.
Trivial getters/setters and pass-through wrappers with no logic.
The same logic at three levels — pick one level and assert it well.
Implementation details that aren't part of the contract — they make refactors painful.

A test plan that says "this part needs no test, here's why" is more credible than one that tries to test everything.

이 저장소의 다른 Skills

같은 저장소

agent-memory-patterns

meaganewaller/rosetta

Use when designing memory or persistent context for an agent — deciding what to persist vs. recompute, how to retrieve only what's relevant, and how to summarize/compact history to fit the context window. Use when an agent forgets, bloats its context, or repeats work.

2026-06-171

configure-rosetta

meaganewaller/rosetta

Interactive installer for Rosetta. Guides users through selecting and installing skills and language-specific rules at user-level or project-level, verifies paths, and optionally optimizes installed files.

2026-06-171

continuous-learning

meaganewaller/rosetta

Instinct-based learning system that observes sessions via hooks, creates atomic instincts with confidence scoring, and evolves them into skills, commands, and agents.

2026-06-171

designing-llm-evals

meaganewaller/rosetta

Use when building or reviewing an evaluation for an LLM feature — assembling a representative test set, choosing pass criteria (exact match, programmatic checks, rubric, or LLM-as-judge), and catching regressions. Use when asking "how do I know this prompt or model change is better?"

2026-06-171

effective-prompting

meaganewaller/rosetta

Use when writing or reviewing a prompt for an LLM — making it specific, structured, and testable (clear task, role/context, examples, an explicit output contract, decomposition, room to reason) and avoiding the anti-patterns that make prompts brittle. Provider-agnostic.

2026-06-171

iterative-retrieval

meaganewaller/rosetta

Pattern for progressively refining context retrieval to solve the subagent context problem.

2026-06-171

name	test-design-heuristics
description	Use when deciding what to test for a change. Covers the test pyramid, risk-based prioritization, boundary and equivalence partitioning, the edge cases worth checking, and — just as important — what not to test.

Test design heuristics

The goal of a test is to catch a regression that matters, cheaply. Optimize for signal per test, not for a coverage number.

Pick the level (the pyramid)

Unit — fast, many, isolated. Pure logic, branching, transformations. Most tests live here.
Integration — fewer. Real boundaries: a DB, a queue, an HTTP client, the file system. Test the seam, not the whole world.
End-to-end — fewest. One or two happy-path journeys that prove the pieces connect.

Push each behavior to the lowest level that can meaningfully exercise it.

Prioritize by risk

Find the cases

Equivalence classes — one representative per class of input, not every value.
Boundaries — 0, 1, n, n+1, max, just-over-max. Off-by-one lives here.
Empty / null / missing — empty list, null field, absent config, zero-length string.
Error paths — what happens when the dependency throws, times out, or returns garbage.
Idempotency & concurrency — only when the code is retried or runs in parallel.

What NOT to test

Framework or library internals — trust them; test your use of them.
Trivial getters/setters and pass-through wrappers with no logic.
The same logic at three levels — pick one level and assert it well.
Implementation details that aren't part of the contract — they make refactors painful.

A test plan that says "this part needs no test, here's why" is more credible than one that tries to test everything.