菜单
良い単体テストの基本規範(Khorikov『単体テストの考え方/使い方』準拠)を扱う。 test-catalog の手法カタログの一部。古典学派とロンドン学派の使い分け、観察可能な 振る舞いのテスト、良いテストの4本柱(退行保護・リファクタリング耐性・高速フィード バック・保守性)、出力ベース/状態ベース/コミュニケーションベースの検証スタイルの 優先順位を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの 索引経由で手法が選定された後にこのスキルを直接参照する。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
内部実装を見ず、入出力仕様だけから入力空間の分割でテストケースを機械的に導くブラックボックス技法群。 test-catalog の手法カタログの一部。同値分割(Equivalence Partitioning)、境界値分析(Boundary Value Analysis)、 ドメイン分析テスト(Domain Analysis、多変数の境界on/off/in/out)、デシジョンテーブル(Decision Table、条件の組合せとアクション) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
gitコミット運用ルール。**主目的は論理的に独立した修正を都度・適切な粒度でコミットすること**、および plan モードで実装計画を立てる際に必ずコミット計画を plan 本文に含めること。メッセージ形式は Conventional Commits。「コミットして」「コミット分けて」「コミット計画を立てて」「分けてコミット」「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画」と依頼される、`git commit`を実行する、ExitPlanMode 前に plan を提示する、複数の独立した修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase/squash で履歴を整える、`gh pr create`時にPRタイトルをコミット流儀に揃える等の場面で必ず参照する。変更を約30〜50行の論理単位へ分割してコミットを積む実務手順は micro-commit スキル側が担い、本スキルは粒度の判断基準・plan 段階のコミット計画・メッセージ規約を定める(併用時は本スキルの基準で分割単位を決め、micro-commit で実行する)。
テストが flaky になる要因のうち、処理どうしの協調(タイミング・順序)が定まらないものへの体系的対策。 test-catalog の手法カタログの一部。並行・競合(共有状態への同時アクセス、レース窓の検出と直列化による封じ込め)、 テスト間順序・状態漏れ(実行順シャッフルでの炙り出し、beforeEach/afterEachでの初期化・後始末)、 検出3軸と隔離(quarantine)・retry緑詐称の戒めといった flaky 対策の共通方針 を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
自然言語の要求を EARS 記法 + 状態/ドメインモデルへ構造化し、TLA+ で設計を網羅検査し、 TLC の反例を Gherkin の受け入れ仕様に落とすまでの 3 重フィードバックループの入口(ルーター)。 ユーザーが「ループエンジニアリング」「EARS」「TLA+」「Gherkin」「設計を検証」「状態機械を検査」 「要求を形式化」と言ったとき、または並行・状態遷移・プロトコル設計の正しさを実装前に モデル検査で固めたいときに使用する。起動判断(2 問ゲート)を通った後、工程は loopeng-extract → loopeng-formalize → loopeng-modelcheck → loopeng-gherkin の各スキルへ委譲する。 設計は TLA+、実装の数学的証明は formal-verification(Lean)。
Automatically create conventional commit-style micro-commits by splitting changes into logical units of ~30-50 lines each. Use this skill whenever the user asks to commit, says "コミットして", "commit this", or when a feature, fix, or refactoring task is completed and changes need to be committed. Also trigger when the user mentions "マイクロコミット", "micro commit", "conventional commit", or asks to split changes into smaller commits. If you detect that a coding task has just been completed and there are uncommitted changes, suggest using this skill. Grain-size judgment and plan-stage commit planning are handled by the commit-flow skill; when both apply, commit-flow decides the split and this skill executes it.
test-catalog の手法カタログの一部。非機能テストの測定系(性能テスト、負荷テスト、 ストレステスト、スパイクテスト、ソークテスト/耐久テスト、スケーラビリティテスト、 キャパシティテスト)を検証したいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
| name | good-test-principles |
| description | 良い単体テストの基本規範(Khorikov『単体テストの考え方/使い方』準拠)を扱う。 test-catalog の手法カタログの一部。古典学派とロンドン学派の使い分け、観察可能な 振る舞いのテスト、良いテストの4本柱(退行保護・リファクタリング耐性・高速フィード バック・保守性)、出力ベース/状態ベース/コミュニケーションベースの検証スタイルの 優先順位を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの 索引経由で手法が選定された後にこのスキルを直接参照する。 |
| disable-model-invocation | true |
良い単体テストとは何かを測る基準をまとめる。
出典は Vladimir Khorikov『単体テストの考え方/使い方』(Unit Testing Principles, Practices, and Patterns)。
TDD の手順は tdd-cycle.md(サイクルの運用)と tdd-green-strategy.md(Green の戦略)、テストダブルの使い分けは test-doubles.md を参照。
このファイルは単体テストの基本規範を扱う。
学派の選び方、何を検証対象とするか、テストの価値を測る物差し、検証スタイルの三分類を示す。
脆いテストを避けるためのテスト設計と配置(脆さの回避、モック濫用の回避、Humble Object、四象限、契約による境界)は test-design-quality.md を参照。
各項目は「概要」「目的/いつ使う」「TypeScript example(vitest 想定)」「落とし穴」の構成で示す。
単体テストの「単体」の捉え方をめぐる二つの立場。 古典学派(Detroit / Chicago 学派)は、振る舞いの単位を一単位とし、協力オブジェクトは可能な限り本物を使う。 ロンドン学派(Mockist)は、クラス単位を一単位とし、依存はすべてモックへ差し替えて隔離する。
Khorikov は古典学派を推す。 理由は、ロンドン学派のように協力オブジェクトを一律モック化すると、テストが実装の協調手順へ結合し、リファクタリング耐性を失うからである。 ロンドン学派が有利なのは、依存グラフが深くテスト準備が困難なときに限られる。 ただしその困難さ自体が設計の不備を示すことが多い。
import { describe, it, expect, vi } from "vitest";
import { Order } from "./order";
import { PriceTable } from "./price-table";
// 古典学派: 協力オブジェクト PriceTable は本物を使う
it("classical: uses real collaborator", () => {
const order = new Order(new PriceTable({ apple: 100 }));
expect(order.total(["apple", "apple"])).toBe(200);
});
// ロンドン学派: 協力オブジェクトもモック化して隔離する
it("london: mocks the collaborator", () => {
const priceTable = { priceOf: vi.fn().mockReturnValue(100) };
const order = new Order(priceTable);
expect(order.total(["apple", "apple"])).toBe(200);
});
grep -n "vi.fn\|mock\|jest.fn" <test> で、そのテストが差し替えている協力者を全部洗い出す。網羅の単位を何に取るかで、網羅が崩れにくいか脆いかが決まる。 古典学派に寄せ、網羅対象を「振る舞いの単位」(公開された結果や副作用)に取る。 こうすると内部のクラス分割やヘルパー抽出といったリファクタリングで網羅が崩れない。 ロンドン学派に寄せて協力者を一律モック化すると、行カバレッジの数字は出る。 しかしその網羅は実装の協調手順へ結合し、内部構造を変えた途端に赤くなる。 網羅率は同じでも、後者は変更のたびに作り直しを強いる無駄な網羅になる。 モックに寄せてよいのは、依存グラフが深くテスト準備が困難な箇所だけに限る。 原則は、網羅の母集合を実装の手順ではなく観察可能な振る舞いの集合に置くことだ。
テストは、クライアントから観察できる振る舞い(公開された結果や、外部に与える副作用)だけを検証し、実装の詳細(private メソッド、内部の中間状態、呼び出し手順)には触れない。
常に守るべき原則である。 観察可能な振る舞いをテストすれば、内部を入れ替えてもテストは緑のままで、リファクタリングを支えられる。 逆に実装詳細を検証するテストは、振る舞いが正しくても内部変更で壊れ、偽の警報(false positive)を出す。 迷ったら問う。「このテストは利用者が気にする結果を確かめているか、それとも内部の作り方を確かめているか」。
import { describe, it, expect } from "vitest";
import { Stack } from "./stack";
// 良い: 観察可能な振る舞い(pop の戻り値)を検証する
it("pops the last pushed value", () => {
const s = new Stack<number>();
s.push(1);
s.push(2);
expect(s.pop()).toBe(2);
});
// 悪い: 内部配列という実装詳細に触れる。配列を連結リストへ替えただけで壊れる
// expect((s as any).items).toEqual([1, 2]);
grep -n "as any\|\[.private.\]\|@ts-ignore" <test> で、private や内部フィールドをこじ開けている箇所を洗う。ヒットは実装詳細への結合の証拠。網羅対象の母集合を「公開された振る舞いの集合」に固定する。 入力と観察可能な出力の組を数え上げ、その全パターンを踏むことを網羅基準とする。 private メソッドや中間状態、呼び出し手順は網羅対象に含めない。 これらを網羅対象に含めると、網羅率を上げるほど実装変更で崩れる脆い網羅になる。 private を網羅したくなったら、それは公開すべき振る舞いか分割の対象かの信号だ。 網羅の達成チェックは「未検証の公開振る舞いが残っていないか」で行う。 「未呼び出しの private が残っていないか」で測ると、網羅の的を実装詳細へずらしてしまう。
Khorikov は良い単体テストを四つの柱で測る。
テストの価値を評価し、何を直すか決める物差しに使う。 要点は、前三者が同時に最大化できないトレードオフの関係にあることだ。 退行保護と高速性を両立させると、広い範囲を高速に回すために実物の依存をモックへ替えがちで、リファクタリング耐性が下がる。 リファクタリング耐性は実装詳細に触れないことで得られるが、これは譲ってはならない柱とされる。 したがって実務では、リファクタリング耐性を固定し、残る退行保護と高速性のあいだで均衡を探る。
import { describe, it, expect } from "vitest";
import { parseAmount } from "./amount";
// 退行保護: 異常系まで検出する。リファクタリング耐性: 戻り値だけ見て内部に触れない
// 高速: I/O なしの純粋関数。保守性: 入出力が一目で読める
describe("parseAmount", () => {
it("parses a valid amount", () => expect(parseAmount("1,000")).toBe(1000));
it("rejects a negative amount", () => expect(() => parseAmount("-1")).toThrow());
});
grep -n "mock\|vi.fn" <test> のヒットが純粋関数に掛かっていれば、退行保護を削ったモックの疑い。網羅とは退行保護を厚くする営みであり、これは高速性とトレードオフの関係にある。 広い網羅を高速に回そうと実物をモックへ替えると、リファクタリング耐性が下がる。 そこで耐性は譲れない柱として固定し、網羅の厚みは保護と速度の均衡で決める。 網羅率を追うために実装詳細へ結合し、耐性を削ってはならない。 具体的には、網羅対象を観察可能な振る舞いに保ったまま退行保護を上げる。 速度が問題になったら、モック追加でなく対象を純粋関数へ割って網羅を取り直す。 固定する柱(耐性)と均衡を探る柱(保護と速度)を分けて考えるのが要点だ。
検証スタイルの三分類。
ひとつ上の「観察可能な振る舞いのテスト」とは軸が違う。観察可能な振る舞いは何を検証対象に選ぶか(対概念は実装詳細)を決める原則で、こちらは選んだ振る舞いをどう検証するか(対概念は他の検証手段)の分類である。観察可能な振る舞いを対象に据えたうえで、その振る舞いが戻り値に出るなら出力ベース、状態に出るなら状態ベース、外部への通信に出るならコミュニケーションベースで確かめる、という関係になる。
Khorikov は出力ベースを最良とする。 最も脆くなりにくく、リファクタリング耐性と保守性が高いからである。 状態ベースは次点。 コミュニケーションベースは脆さを招きやすいため、管理下にないプロセス外依存に限って使う。 設計を関数型寄り(副作用を端へ追い出す)に保つほど、出力ベースで書ける割合が増える。
import { describe, it, expect, vi } from "vitest";
import { calcTax } from "./tax";
import { Wallet } from "./wallet";
import { Notifier } from "./notifier";
// 出力ベース: 戻り値だけを見る(最も望ましい)
it("output-based", () => expect(calcTax(1000)).toBe(100));
// 状態ベース: 操作後の状態を見る
it("state-based", () => {
const w = new Wallet(1000);
w.withdraw(300);
expect(w.balance).toBe(700);
});
// コミュニケーションベース: 外部への通信を検証する(プロセス外依存に限る)
it("communication-based", () => {
const sms = { send: vi.fn() };
new Notifier(sms).alert("hi");
expect(sms.send).toHaveBeenCalledWith("hi");
});
toHaveBeenCalled 系があればコミュニケーションベース、状態フィールドの参照があれば状態ベース、戻り値のみなら出力ベース。grep -n "toHaveBeenCalled" <test> の各ヒットが掛かる協力者を、プロセス内かプロセス外かで仕分ける。プロセス内協力者へのコミュニケーションベースは脆さの証拠。網羅を出力ベースで取れる割合を最大化すると、最も頑健な網羅になる。 出力ベースの網羅は入力と戻り値の組を数え上げるだけで、実装詳細に結合しない。 設計を関数型寄り(副作用を端へ追い出す)に保つほど、出力ベースで網羅できる範囲が広がる。 状態ベースの網羅は次点で、操作後の状態を確かめる箇所に使う。 コミュニケーションベースの網羅は脆いので、管理下にないプロセス外依存に限定する。 網羅設計の目安は、まず出力ベースで取れる所を全部取り、残りを状態ベースで覆い、最後に外部通信だけをコミュニケーションベースで網羅することだ。 この順で配分すると、脆い網羅をプロセス外依存の最小限へ閉じ込められる。
ここまでは単体テストの基本規範を扱った。
脆いテストを避けるためのテスト設計と配置(脆さの回避、モック濫用の回避、Humble Object、四象限、契約による境界)は test-design-quality.md を参照。