メニュー
テストの粒度選択のうち、1サービス内部の層(単体テスト/Unit Test、結合テスト/ Integration Test)を扱う。 test-catalog の手法カタログの一部。依存を切り離した最小単位のロジック・分岐・境界 ・例外の網羅、複数モジュールや実依存(DB、キュー、別サービス)との接続部のずれの 検証を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引 経由で手法が選定された後にこのスキルを直接参照する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | levels |
| description | テストの粒度選択のうち、1サービス内部の層(単体テスト/Unit Test、結合テスト/ Integration Test)を扱う。 test-catalog の手法カタログの一部。依存を切り離した最小単位のロジック・分岐・境界 ・例外の網羅、複数モジュールや実依存(DB、キュー、別サービス)との接続部のずれの 検証を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引 経由で手法が選定された後にこのスキルを直接参照する。 |
| disable-model-invocation | true |
対象の粒度によるテストの分類のうち、1サービス内部の粒度(単体、結合)を扱う。 下に行くほど対象が広く、実行が遅く、本物の環境に近い。 ISO/IEC/IEEE 29119 が用語の基準だが、現場では俗称が混在するため、各手法で「何を本物にし、何を差し替えるか」を明確にして選ぶ。 サービスを箱とみなすレベル(コンポーネント、コントラクト)は levels-service.md を参照。
関数、メソッド、クラスといった最小単位を、依存を切り離して検証する。
ロジックの分岐、境界、例外を高速かつ大量に回したいときに使う。 外部 I/O やフレームワークの挙動そのものを確かめたい局面では使わない(それは結合より上の責務)。
import { describe, it, expect } from "vitest";
// 検証対象: 純粋関数。依存なしなのでそのまま呼べる
function applyDiscount(price: number, rate: number): number {
if (rate < 0 || rate > 1) throw new RangeError("rate out of range");
return Math.round(price * (1 - rate));
}
describe("applyDiscount", () => {
it("割引を適用して四捨五入する", () => {
expect(applyDiscount(1000, 0.1)).toBe(900);
});
it("境界: rate=1 は 0 円", () => {
expect(applyDiscount(1000, 1)).toBe(0);
});
it("異常系: 範囲外の rate は例外", () => {
expect(() => applyDiscount(1000, 1.5)).toThrow(RangeError);
});
});
モックを積み上げて実装の呼び出し順をなぞるテストは、リファクタで即壊れる割に欠陥を捕まえない。 private メソッドを直接叩こうとするのは設計のにおい。公開された振る舞いで検証する。
このレベルは「対象単位そのもののロジック網羅」を集約する層。 分岐、境界、例外の網羅はここで取り切り、上の層へ持ち上げない。
単体の作業の本体は「対象の公開された振る舞いを列挙し、各振る舞いに手法を当て、coverage で到達を裏取りする」ことだ。次の順で進める。
blackbox-partition.md)、境界は境界値、入力の組合せはデシジョンテーブル、異常系は無効同値クラスへ振る。1振る舞いに最低1ケース。tdd-cycle.md に従い、列挙した行を上から1本ずつ失敗テスト→最小実装で緑にする。三角測量が要る分岐は2本目を足す。grep 等で対象テストに外部 I/O・接続のアサート(DB/HTTP/ファイル)が無いことを確認する。あれば層違い。複数のモジュールや、コードと実依存(DB、キュー、別サービス)の境界をまたいで検証する。
単体では見えない接続部のずれ(SQL の方言、シリアライズ、トランザクション境界)を捕まえたいときに使う。 ロジックの全分岐を網羅する用途には向かない(遅く、組み合わせ爆発する)。
import { describe, it, expect, beforeAll, afterAll } from "vitest";
import Database from "better-sqlite3";
import { UserRepo } from "./user-repo";
let db: Database.Database;
let repo: UserRepo;
beforeAll(() => {
// 本物の DB エンジンを使う。スキーマのずれをここで検出する
db = new Database(":memory:");
db.exec("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL)");
repo = new UserRepo(db);
});
afterAll(() => db.close());
describe("UserRepo", () => {
it("保存した行を取得できる", () => {
const id = repo.insert("alice");
expect(repo.findById(id)?.name).toBe("alice");
});
});
共有 DB を使い回してテスト間で状態が漏れると、実行順で結果が変わる不安定なテストになる。 in-memory で代用すると本番 DB との方言差を見逃すことがある。重要な経路は本物のエンジンで確認する。
このレベルは「モジュール境界と実依存との接続のずれ」を網羅対象に取る層。 全ロジック分岐は対象にしない(それは単体)。接続経路を代表で踏むことに集中する。
結合の作業の本体は「対象がまたぐ接続経路を数え上げ、各境界に代表ケースを1本ずつ当てる」ことだ。分岐の全網羅(=単体)に流れないよう、経路の数を先に確定させてから書く。
UserRepo × {挿入, 取得, 更新, 削除}、PaymentClient × {課金, 返金}。1セルが1経路。テストダブルへ差し替える協力者の振り分けは test-doubles.md の手順2(管理下/管理外)に従う。test-doubles.md の Testcontainers)で状態検証する。in-memory 代用は方言差が出ない境界に限る。vitest --sequence.shuffle 等)で緑か。落ちれば共有状態の汚染(flakiness-concurrency.md)。strategy-allocation.md。内部実装を見ず、入出力仕様だけから入力空間の分割でテストケースを機械的に導くブラックボックス技法群。 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 スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。