Skills: 自動テストスキル
最終更新:2026-08-31
テストはコードのセーフティネット——Skills がこのネットをより速く、より密に、よりスマートに編み上げます。
1. テスト Skill のタイプ
(1) テスト生成
ソースコードからテストを自動生成:
YAML
---
name: test-generator
description: "ユニットテストを自動生成"
triggers:
- keyword: "generate-test|gen-test|テスト生成"
tools:
- Read
- Grep
- Glob
- Write
---
MARKDOWN
## 生成フロー
1. ソースファイルを読み込み、関数シグネチャとロジックを分析
2. 境界条件とエラーパスを特定
3. Write でテストファイルを作成
4. Bash でテストを実行して検証
(2) テスト実行
プロジェクトのテストを自動検出して実行:
| フレームワーク | 検出方法 | 実行コマンド |
|---|---|---|
| pytest | pyproject.toml | pytest |
| Jest | package.json | npx jest |
| Go | go.mod | go test ./... |
| Rust | Cargo.toml | cargo test |
(3) 失敗診断
テストが失敗した時、原因を自動分析:
MARKDOWN
## 診断フロー
1. 失敗したテスト出力を読み込む
2. 失敗したアサーションとエラースタックを特定
3. 関連ソースコードを読み込む
4. 失敗原因を分析
5. 診断レポートと修正提案を出力
2. テスト生成戦略
(1) 関数レベルのテスト
PYTHON
# ソースコード
def divide(a: float, b: float) -> float:
if b == 0:
raise ValueError("Division by zero")
return a / b
PYTHON
# 自動生成テスト
def test_divide_normal():
assert divide(10, 2) == 5.0
def test_divide_negative():
assert divide(-10, 2) == -5.0
def test_divide_zero():
with pytest.raises(ValueError):
divide(10, 0)
def test_divide_float():
assert divide(7, 2) == 3.5
(2) テストカバレッジの観点
| 観点 | テストタイプ | 例 |
|---|---|---|
| 正常パス | Happy path | 正常入力で期待結果が返る |
| 境界条件 | Boundary | 空文字列、ゼロ、最大値 |
| エラーパス | Error path | 無効な入力で期待例外が発生 |
| 並行安全性 | Concurrency | マルチスレッドでの共有リソースアクセス |
3. カバレッジ分析
(1) カバレッジの収集
BASH
# Python
pytest --cov=src --cov-report=term-missing
# JavaScript
npx jest --coverage
# Go
go test -coverprofile=coverage.out ./...
(2) カバレッジレポート
TEXT
📖 参照専用
カバレッジレポート
├── 総カバレッジ:72%
├── 未カバレッジファイル:
│ ├── src/auth/__init__.py (0%) ← エントリファイル、テストが必要
│ ├── src/utils/validators.py (45%) ← 一部関数が未テスト
│ └── src/api/routes.py (60%) ← エラーハンドリングが未カバー
└── 提案:validators.py のテストを優先的に追加
4. テスト Skill の実践
▶ 例:TDD アシスタント Skill
Alice はチームがテスト駆動開発を実践するための TDD アシスタント Skill を作成しました:
YAML
---
name: tdd-assistant
description: "TDD アシスタント:テストを先に書き、その後実装"
triggers:
- keyword: "tdd|test-driven|テスト駆動"
tools:
- Read
- Write
- Edit
- Bash
---
MARKDOWN
## TDD フロー
1. 要件を理解する
2. 失敗するテストを書く(RED)
3. Bash でテストが失敗することを確認
4. Edit で最小限の実装を書く(GREEN)
5. Bash でテストが通ることを確認
6. Edit でリファクタリングと最適化(REFACTOR)
7. Bash でテストが依然として通ることを確認
Bob は言います:「TDD の最大の敵は惰性——Skills がプロセスを固定化することで、開発者は『テスト先かコード先か』と悩む必要がなく、ただフローに従えばいい。」
❓ よくある質問
Q 自動生成テストの品質は十分ですか?
A 出発点としては十分ですが、境界条件やビジネスロジックのテストは手動で補充する必要があります。Skill 生成テストは正常パスと一般的な境界をカバーし、複雑なシナリオは人間の設計が必要です。
Q Skills は失敗したテストを自動修正できますか?
A 試みることはできますが、修正の前に診断することをお勧めします。単純なアサーションエラーは自動修正可能ですが、複雑なロジックエラーは修正方向の人工確認が必要です。
Q テストカバレッジと開発スピードのバランスは?
A コアモジュールは 80% 以上、ユーティリティ関数は 60% 以上、新機能はクリティカルパステストを先に書き、徐々に補充する方針をお勧めします。
📖 まとめ
- 3つのテスト Skill タイプ:生成、実行、診断
- 生成戦略:正常パス+境界条件+エラーパス
- カバレッジ分析:収集→レポート→優先的に補充
- TDD フロー:RED→GREEN→REFACTOR、Skills がワークフローを固定化
📝 練習問題
- 基礎問題(難易度⭐):プロジェクトのテストフレームワークを自動検出してテストを実行する Skill を作成してください。
- 応用問題(難易度⭐⭐):指定関数に対して正常/境界/エラーの3タイプのテストを生成する Skill を作成してください。
- チャレンジ問題(難易度⭐⭐⭐):RED-GREEN-REFACTOR サイクルを完全に実装し、各段階でステータスレポートを出力する TDD アシスタント Skill を作成してください。