test-architect
テスト戦略の立案、カバレッジ分析、エッジケースの特定、不安定なテストの診断ができます。テストスイートの設計時にご利用ください。テストの実行(devops-engineer)、TDD、コードレビュー(honest-review)には対応していません。
description の原文を見る
Test strategy, coverage analysis, edge case identification, flaky test diagnosis. Use when designing test suites. NOT for running tests (devops-engineer), TDD, or code review (honest-review).
SKILL.md 本文
テストアーキテクト
テスト戦略の設計、カバレッジギャップの分析、エッジケースの識別、不安定なテストの診断、テストスイートアーキテクチャの監査を行います。
適用範囲: テスト設計と分析のみ。テストの実行やCI/CD (devops-engineer)、コードレビュー (honest-review)、またはTDDワークフローには対応していません。
ディスパッチ
| $ARGUMENTS | アクション |
|---|---|
design <feature/module> | 機能またはモジュールのテスト戦略とピラミッドを設計 |
generate <file/function> | テストケースを生成(コンテキストに基づいて戦略テキストまたは実際のテストコード) |
gaps | カバレッジレポートからカバレッジギャップを分析 |
edge-cases <function> | 関数の体系的なエッジケース識別 |
flaky | ログとコードから不安定なテストを診断 |
review | テストスイートアーキテクチャを監査 |
| 空 | 例を含むモードメニューを表示 |
正規用語
すべてのモードで以下の用語を正確に使用してください:
| 用語 | 定義 |
|---|---|
| テストピラミッド | 層状のテスト配分: ユニット(ベース)、統合(中)、E2E(トップ) |
| カバレッジギャップ | テストカバレッジがないコードパス(複雑性リスクで加重) |
| エッジケース | 境界条件、null/空、型強制、オーバーフロー、Unicode、並行処理での入力 |
| 不安定なテスト | 同一実行でも非決定的な成功/失敗動作を示すテスト |
| ミューテーションスコア | テストスイートによって検出された注入されたミューテーションのパーセンテージ |
| テスト戦略 | 何をテストするか、どのように、どのレイヤーで、どのツールで実施するかを定義したドキュメント |
| プロパティベーステスト | 生成された入力に対して不変性を主張するテスト(Hypothesis/fast-check) |
| テスト隔離 | テストがミュータブル状態または実行順序の依存関係を共有しないことの保証 |
| フィクスチャ | 制御された状態を提供する再利用可能なテストセットアップ/ティアダウン |
| テストサーフェス | テストカバレッジが必要なパブリックインターフェース、コードパス、状態のセット |
モード1: 設計
/test-architect design <feature/module>
サーフェス分析
- 機能/モジュールコードを読み、テストサーフェスをマップします: パブリックAPI、内部パス、状態遷移、エラー条件。
- 複雑性を分類します: シンプル(純粋関数)、中程度(I/O、状態)、複雑(分散、並行、マルチサービス)。
ピラミッド設計
- テストピラミッドを設計します:
- ユニットレイヤー: 純粋ロジック、変換、バリデータ。目標: テストの70〜80%。
- 統合レイヤー: データベース、API、ファイルI/O、サービス境界。目標: 15〜25%。
- E2Eレイヤー: 重要なユーザーフローのみ。目標: 5〜10%。
- 各レイヤーについて、以下を含む具体的なテストケースをリストアップします: 説明、入力、期待出力、根拠。
- 言語/エコシステムに基づいてフレームワークとツールを推奨します。
- 出力: ピラミッド図、ケースリスト、優先順序を含む構造化戦略ドキュメント。
参考: references/test-pyramid.md を読んでレイヤーガイダンスを確認してください。
モード2: 生成
/test-architect generate <file/function>
- ターゲットファイル/関数を読み、シグネチャ、依存関係、副作用を識別します。
- 出力形式を決定します:
- ターゲット用のテストファイルが存在する場合: 既存パターンに合わせて実際のテストコードを生成。
- テストファイルが存在しない場合: ケース説明を含むテスト戦略テキストを生成。
- ユーザーが
--codeを指定する場合: 常にテストコードを生成。
- 以下をカバーするテストケースを生成します:
- ハッピーパス(期待される入力と出力)
- エラーパス(無効な入力、例外、タイムアウト)
- エッジケース(関数が型付きパラメータを持つ場合、edge-case-generator.py を実行)
- 境界条件(最小/最大値、空コレクション、null)
- フレームワーク規約に従います: references/framework-patterns.md を読んでpytest/jest/vitestパターンを確認してください。
- 出力: カテゴリごとに明確なセクションヘッダーを付けたテストケースまたはテストコード。
モード3: ギャップ
/test-architect gaps
- カバレッジレポートを検索します:
coverage.json、coverage.xml、.coverage(Python/coverage.py)lcov.info、coverage/lcov.info(JS/lcov)htmlcov/、coverage/ディレクトリ
- カバレッジアナライザーを実行します:
uv run python skills/test-architect/scripts/coverage-analyzer.py <report-path> - JSON出力を解析します。複雑性加重リスクでギャップをランク付けします。
- 各ギャップについて、以下を評価します:
- どのコードがテストされていないか、なぜ重要か
- 複雑性スコア(循環複雑度プロキシ)
- 推奨テストタイプ(ユニット/統合/E2E)
- 優先度(P0: セキュリティ/認証、P1: コアロジック、P2: ユーティリティ、P3: 見た目)
- 10以上のギャップがある場合、ダッシュボードをレンダリングします:
templates/dashboard.html を一時ファイルにコピー <script id="data"> タグにギャップデータJSONを注入 ブラウザで開く - 出力: 優先度付けされたギャップリストと推奨アクション。
参考: references/coverage-analysis.md を読んで解釈ガイダンスを確認してください。
モード4: エッジケース
/test-architect edge-cases <function>
- 関数を読み、パラメータタイプ、戻り値タイプ、制約を抽出します。
- エッジケース生成器を実行します:
uv run python skills/test-architect/scripts/edge-case-generator.py --name "<function_name>" --params "<param1:type,param2:type>" - JSON出力を解析します。生成されたカテゴリを確認します:
- Null/空: None、""、[]、{}、0、False
- 境界: 最小/最大int、float制限、文字列長制限
- 型強制: "123" vs 123、True vs 1、None vs "null"
- オーバーフロー: 大きな数値、深いネスト、長い文字列
- Unicode: 絵文字、右から左へのテキスト、ゼロ幅文字、結合マーク
- 並行: 競合状態、デッドロック、古いデータの読み取り
- 各エッジケースについて: 入力値、期待される動作、根拠を提供します。
- 現在のコードが失敗する可能性が高いケースをフラグします(ガード、検証なし)。
参考: references/edge-case-heuristics.md を読んでカテゴリの詳細を確認してください。
モード5: 不安定
/test-architect flaky
ログ収集
- テスト結果ログを検索します:
- CIログ、pytest出力、jest出力
.pytest_cache/、test-results/- ログパスが見つからない場合はユーザーに確認
- 不安定なテストアナライザーを実行します:
uv run python skills/test-architect/scripts/flaky-test-analyzer.py <log-path>
根本原因の分類
- JSON出力を解析します。不安定なテストごとに:
- 失敗数対成功数
- 失敗パターン(タイミング、順序、リソース、状態)
- 可能性の高い根本原因分類:
- タイミング: sleep/タイムアウト依存、競合状態
- 順序: テスト実行順序の依存関係
- リソース: 外部サービス、データベース、ファイルシステム
- 状態: テスト間の共有ミュータブル状態
- 環境: プラットフォーム固有、タイムゾーン、ロケール
- 根本原因ごとに修正戦略を推奨します。
- 失敗頻度と影響範囲で優先度を付けます。
参考: references/flaky-diagnosis.md を読んで根本原因パターンを確認してください。
モード6: レビュー
/test-architect review
- テストスイートをスキャンします。マップ: テストファイル数、フレームワーク、ディレクトリ構造。
- アーキテクチャの次元を評価します:
- ピラミッドバランス: ユニット:統合:E2Eテストの比率
- 隔離: 共有状態、グローバルフィクスチャ、テスト順序の依存関係
- 命名: 一貫性、説明力、規約への準拠
- カバレッジ分布: 均一対クラスタ化
- フィクスチャ健全性: 重複、複雑性、セットアップ/ティアダウンバランス
- アサーション品質: 特定のアサーション対汎用assertTrue
- 速度: 遅いテストを識別(>1秒ユニット、>10秒統合)
- 確定性: 潜在的な不安定性の指標
- レポートが存在する場合、カバレッジアナライザーを実行します。
- ソースコードと相互参照します:
- テストされていないパブリックAPI
- 削除/名前変更されたコードのテスト(孤立したテスト)
- 不足している負のテストケース
- 出力: 次元ごとのスコア、調査結果、推奨事項を含むアーキテクチャ監査レポート。
参考: references/test-suite-audit.md を読んでスコア基準を確認してください。
リファレンスファイル
一度に1つのリファレンスファイルをロードしてください。すべてのリファレンスをコンテキストに事前ロードしないでください。
| ファイル | コンテンツ | 読む時機 |
|---|---|---|
| references/test-pyramid.md | テストピラミッドレイヤー、配分目標、アンチパターン | モード1(設計) |
| references/framework-patterns.md | pytest、jest、vitestパターンと規約 | モード2(生成)、モード6(レビュー) |
| references/coverage-analysis.md | カバレッジレポート解釈、複雑性加重 | モード3(ギャップ) |
| references/edge-case-heuristics.md | データタイプ別エッジケースカテゴリ、生成戦略 | モード4(エッジケース) |
| references/flaky-diagnosis.md | 不安定なテストの根本原因、修正戦略、予防パターン | モード5(不安定) |
| references/test-suite-audit.md | テストアーキテクチャスコアリングルーブリック、品質の次元 | モード6(レビュー) |
| references/property-testing.md | HypothesisとFast-checkを使用したプロパティベーステスト | モード1(設計)、モード2(生成) |
| references/mutation-testing.md | ミューテーションテスト計画設計、ツール統合 | モード1(設計)、モード6(レビュー) |
| スクリプト | 実行時機 |
|---|---|
| scripts/coverage-analyzer.py | モード3(ギャップ) -- カバレッジレポートを解析 |
| scripts/edge-case-generator.py | モード4(エッジケース) -- 関数シグネチャからエッジケースを生成 |
| scripts/flaky-test-analyzer.py | モード5(不安定) -- 不安定指標のテストログを解析 |
| テンプレート | レンダリング時機 |
|---|---|
| templates/dashboard.html | モード3(ギャップ) で10以上のギャップがある場合 -- カバレッジギャップビジュアライゼーション |
クリティカルルール
- テストを実行しない -- 設計と分析のみ。コマンドを提案しても実行しない。
- ソースコードを修正しない -- テストアーキテクチャは助言的であり、実装ではない。
- 常に各テストケースに正しいテストレイヤー(ユニット/統合/E2E)を推奨する。
- エッジケースは根拠を含める -- 「これを試す」ではなく「なぜこれが重要か」。
- カバレッジギャップは行数ではなくリスクで優先度を付ける。
- 不安定なテスト診断は修正を推奨する前に根本原因カテゴリを識別する。
- フレームワーク推奨はプロジェクトの既存スタックに合わせる。
- プロパティベーステストは不変性が特定可能な場合のみ推奨。
- 一度に1つのリファレンスファイルをロード -- すべてのリファレンスを事前ロードしない。
- すべての調査結果はそれが適用される特定のファイルと関数を引用する。
- テスト生成は存在する場合、プロジェクトの既存テストパターンに従う。
- ダッシュボードレンダリングには10以上のギャップが必要 -- 小さいギャップセットではレンダリングしない。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- wyattowalsh
- リポジトリ
- wyattowalsh/agents
- ライセンス
- MIT
- 最終更新
- 2026/5/9
Source: https://github.com/wyattowalsh/agents / ライセンス: MIT