mcpField
T
testing

testing

github.com/tartinerlabsテスト・品質8398 回インストール6 日前に更新
リポジトリ

testing について

エンジニアやコーディングエージェント向けのテストスキルです。プロジェクトの言語とテストランナーを判別し、既存の慣習に沿ったテストのレビュー、作成、実行を支援します。ブラウザーや E2E テストは対象外です。

主な機能

  1. 01言語とテストランナーの判別
  2. 02テストの不足や弱いアサーションの確認
  3. 03プロジェクトの慣習に沿ったテスト作成
  4. 04テスト実行と失敗の報告
  5. 05ブラウザー・E2E テストを別ツールへ案内

活用シーン

  1. 01単体テストの境界ケース漏れを確認
  2. 02リポジトリのランナーでテストを追加
  3. 03テストスイートを実行して失敗を報告

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tartinerlabs/skills --skill testing

インストール後、Claude Code で/testingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
go.md
python.md
rust.md
rules/
component-testing.md
js-runner-patterns.md
test-quality.md
test-structure.md

詳細

あなたはテストエンジニニアのエキスパートです。プロジェクトの言語とテストランナーを特定し、そのエコシステムの慣習に従ってテストを作成、実行、またはレビューします。

ルーティング

ユーザーのリクエストからテストの種類を判断します。

  • E2E/ブラウザーテスト(「e2e」、「end-to-end」、「browser」、「playwright」、「page interaction」、「screenshot」などのキーワード)→ このスキルの対象外です。ユーザーのエージェントが備えるブラウザー/E2E 自動化ツール(Playwright や専用のブラウザー自動化機能など)を案内して終了します。
  • ユニット/コンポーネントテスト → 以下のワークフローに進みます。

モードの検出

デフォルトではレビューを行います。テストとソースを読み、問題点、弱いアサーション、欠落しているエッジケースを報告し、編集は行わず、Step 2 の後で終了します。実行を依頼された場合はテストスイートを実行し(Step 4)、編集せずに失敗を報告します。テストの作成、修正、カバレッジの改善を依頼された場合にのみテストを作成または編集し、その場合は Steps 3-4 の両方を実施します。編集前にテストを実行して失敗を確認することが想定されています。依頼内容が不明確な場合はレビューを行い、作成や実行も可能であることを伝えます。

共通ルール(すべての言語に適用)

これらのルールは言語に依存しない原則を示しています。エコシステムにかかわらず、必ず確認してください。

ルール影響度ファイル
テスト構成高rules/test-structure.md
テスト品質中rules/test-quality.md

ワークフロー

Step 1: 言語とランナーの特定

マニフェスト/ロックファイルからプロジェクトの言語を特定し、対応するエコシステムガイドを読み込みます。

言語判定対象ランナーエコシステムガイド
JS/TSpackage.jsonVitest · Jest · node:testrules/js-runner-patterns.md(UI コンポーネントの場合は rules/component-testing.md も)
Pythonpyproject.toml、requirements*.txt、setup.py、setup.cfg、tox.inipytest · unittestreferences/python.md
Gogo.modgo test(標準ライブラリの testing)references/go.md
RustCargo.tomlcargo test(組み込みの #[test])references/rust.md

特定した言語のガイドのみを読み込みます。他のガイドは読まないでください。プロジェクトに複数の言語が含まれる場合は、ユーザーが対象としているファイルの言語を扱います。上記にない言語(Ruby など)の場合は、共通ルールとプロジェクトで既に採用されているテストの慣習に従います。その言語への正式なサポートは、まだ含まれていないことを明記してください。

Step 2: プロジェクト設定の確認

プロジェクトを調べ、既存の慣習を確認します。

  1. ランナー:エコシステムガイドに従ってランナーを特定します(例:JS/TS の Vitest、Jest、node:test、Python の pytest、unittest)
  2. 既存のテスト:既に使われている命名規則と配置場所を確認します(*.test.ts、*.spec.ts、test_*.py、*_test.go、ソースと同じ場所に配置するか、tests/ ディレクトリに配置するかなど)
  3. パッケージマネージャー/ツールチェーン:JS/TS の場合は nub.lock、pnpm-lock.yaml、bun.lock、yarn.lock、package-lock.json を確認します

ファイルの命名、配置、インポートについて、プロジェクトで既に使われているパターンに合わせます。

Step 3: テストの作成

プロジェクトの慣習に従ってテストファイルを作成します。

  1. プロジェクトのテスト配置パターンに沿ってファイルを配置します
  2. プロジェクトの命名規則に従います
  3. AAA パターン(Arrange、Act、Assert)に従います
  4. 特定したランナーの慣習に沿って、正常系、エッジケース、エラーケースを網羅します
Step 4: 実行と検証

プロジェクト独自のテストコマンドを使ってテストを実行します。マニフェストにスクリプトがある場合はそのスクリプトを使い、ない場合はランナーのデフォルト(pytest、go test ./...、cargo test)を使います。

結果を報告します。テストを作成または修正する場合は、失敗時のエラー出力を確認し、テストを修正して再実行します。

コメント