Menú
テストの記述ガイドライン。テストを書くとき、テスト設計を考えるとき、テスト戦略を議論するときに使用する。テストの目的、構成、書き方の原則に基づき、信頼性が高く保守しやすいテストを書く。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Preview generated Markdown (plans, design notes, reviews, research reports) in the user's browser. Use when sharing long, structured output — documents with headings, tables, code blocks, or Mermaid diagrams — that is hard to read in the terminal.
OpenAI Codex CLIを使ってコードや計画に対する外部視点のレビューを取得する。計画の妥当性確認、複雑な問題で行き詰まったとき、アーキテクチャ判断のセカンドオピニオン、難しいデバッグのときに使用する。「Codexに聞いて」「セカンドオピニオンが欲しい」などのリクエストにも対応する。
freshターミナルエディタでファイルを開く操作。ユーザーが「freshで開いて」「このファイルをエディタで見たい」「編集したい」と言ったとき、cmux経由でfreshを別ペインに起動してファイルを開く。
cmuxターミナル内での操作スキル。CMUX_*環境変数が存在する場合、cmuxのCLIコマンドを使う前に必ずこのスキルを読む。ペイン分割、コマンド送信、ブラウザ自動化、通知、サブエージェントの隔離実行など、cmux操作全般で使用する。「別ペインで開いて」「横に表示して」「ブラウザで確認して」などのときにも使用する。
k8oが好むUIデザインの方針。UIコンポーネントの作成、画面デザイン、スタイリングの判断時に使用する。ArteOdysseyを使うプロジェクトではコンポーネントやトークンの具体的な使い方を、それ以外のプロジェクトではデザインの方向性を提供する。自由にデザインを作るとき、見た目の判断に迷ったとき、UIレビュー時にも使用する。
Conventional Commitsに従ったアトミックなgitコミットを作成する。変更を論理単位に分割し、独立してrevert可能なコミットを生成する。コードの変更をコミットしたいとき、コミットメッセージを作りたいときに使用する。
| name | testing |
| description | テストの記述ガイドライン。テストを書くとき、テスト設計を考えるとき、テスト戦略を議論するときに使用する。テストの目的、構成、書き方の原則に基づき、信頼性が高く保守しやすいテストを書く。 |
テストの目的は「コスト削減」ではなく、高い信頼性の実行結果に短い時間で到達し、開発者に確信を与え、ソフトウェアの継続的な成長を可能にすること。
テストでは品質は上がらない。品質を上げるのはプログラミング。テストは品質が保たれていることを確認する手段。
テストがもたらす価値は3つ:
「あとで書く」テストは、これらの価値のうち(2)と(3)を大きく損なう。振る舞いを決める前にテストを書くと、テストが仕様を駆動する。
Red → Green → Refactor を小さく速く回す:
「動作するきれいなコード」は1度に書かない。動作させる → きれいにする の2段階に分ける。
Green に進むときの選択肢:
| パターン | やり方 | 使う場面 |
|---|---|---|
| 仮実装 (Fake It) | 期待値をベタ書きで返す | 最初の一歩、不安なとき |
| 三角測量 (Triangulation) | 2つ目・3つ目のテストで一般化を強制 | 仮実装からの脱却、複雑な分岐 |
| 明白な実装 (Obvious Implementation) | いきなり本実装を書く | ロジックが自明で自信があるとき |
不安なら仮実装から。自明なら明白な実装で。途中で詰まったら一段階戻す。
全てのケースを試すのは不可能。バグが潜みやすい所に優先して書く。
不具合は境界（0、1、最大、最小、空、オーバーフロー）に集まる。n < 10 のテストなら、9, 10, 11 を試す。
入力空間を「同じ振る舞いをするはずのグループ」に分け、各グループから代表を1つ選ぶ。全網羅より、クラス分けして代表を押さえる方が効率的。
すべてのコードに同じ密度でテストを書かない。複雑な分岐・外部境界・過去に壊れた所・仕様変更の多い所にテストを集中する。トリビアルな getter/setter にテストはいらない。
テストを分類するときは、スコープ（単体/統合/E2E）よりもサイズで考える。
| サイズ | 制約 | 特性 |
|---|---|---|
| Small | 単一プロセス、メモリ内 | 高速、決定的、安定 |
| Medium | 単一マシン（DB、ファイル可） | やや遅い、不安定性のリスク |
| Large | 制約なし（外部サービス可） | 遅い、不安定、高コスト |
テストピラミッド: Smallを多く、Mediumを中程度、Largeを少なく。アイスクリームコーン（Largeが多い状態）は避ける。
テスト設計のトレードオフを評価する5軸:
全てを最大化はできない。プロジェクトの状況に応じてバランスを取る。
テストが失敗したとき、それは本物の問題であるべき。
偽陽性が多いテストスイートは、やがて無視されるようになる。
// ❌ 実装に結合（内部stateの値を確認）
expect(component.state.count).toBe(1);
// ✅ 振る舞いを確認（ユーザーが見る結果）
expect(screen.getByText('1')).toBeInTheDocument();
テストコードにプロダクトコードと同じロジックを書かない。
// ❌ 自作自演: テスト側でも同じ計算をしている
const expected = (130 / (1 + (8 / 100))) * (8 / 100);
expect(item.taxAmount()).toBe(expected);
// ✅ 期待値はリテラルで書く
expect(item.taxAmount()).toBe(9.629629629629629);
// ❌ 情報が少ない
expect(result === 40).toBe(true);
// ✅ 失敗時に期待値と実際の値がわかる
expect(result).toBe(40);
テスト間の実行順序に依存しない。各テストが単独で実行できる状態を保つ。
結果が不安定なテスト（同じコードで成功/失敗が変わる）は即座に対処する。放置するとテストスイート全体の信頼性が崩壊する。
// Arrange: 準備
const cart = createCart();
cart.addItem({ name: 'Widget', price: 100 });
// Act: 実行
const total = cart.getTotal();
// Assert: 検証
expect(total).toBe(100);
1つのテストで1つの振る舞いを検証する。複数の検証を詰め込まない。テスト名は検証する振る舞いを表現する。
テストが書きにくいコードは、設計に問題がある兆候。テスト容易性を下げている要素を特定し、切り出す（Humble Objectパターン）。
テスト容易性を下げる要素:
これらを境界に押し出し、コアロジックをテストしやすくする。
詳細は references/test-doubles.md を参照。