testing

Name: testing
Author: iuliandita

github.com/iulianditaテスト・品質1049 回インストール今日更新

リポジトリ

testing について

testingは、ユニット、統合、E2E、アクセシビリティ、パフォーマンステストの作成・構成・保守を支援するスキルです。網羅率の数値ではなく、変更に見合ったテストで回帰を検出することを重視します。

主な機能

01各テスト層のガイダンス
02変更に応じたテスト選定
03既存フレームワークに沿ったテストパターン
04不安定なテストの原因調査
05フィクスチャ、モック、テストデータの指針

活用シーン

01バグ修正の回帰テスト追加
02機能変更に必要なテストの選定
03不安定または失敗するテストの診断
04テスト基盤とカバレッジゲートの計画

インストール

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

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

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

同梱ファイル

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

references/

agent-hygiene.md

e2e-accessibility.md

language-patterns.md

output-contract.md

詳細

テスト：実際のバグを見つけるテストを書く

ユニット、統合、E2E、アクセシビリティ、パフォーマンスの各レイヤーで、テストを作成、構成、保守します。目標は、カバレッジの数値を増やすためだけに存在するテストではなく、リグレッションを検出し、動作を文書化し、CI で高速に実行できるテストです。

対象バージョン（2026年10月）：

Vitest 5.0.5、Jest 30.5.2
Playwright 1.64.1、Cypress 16.1.1（Vitest と Cypress はどちらもメジャーアップグレードです。移行に関する注意事項を確認してください）
pytest 9.2.0、pytest-cov 7.1.0
Go 1.27.3（testing 標準ライブラリ、testing/synctest GA）
Rust 1.99.0（cargo test、cargo-nextest 0.9.150）
Testing Library 16.3.3（@testing-library/react）
axe-core 4.14.0（@axe-core/playwright）
Grafana k6 2.3.0

セキュリティチェック（2026-10-28）：GHSA-2h32-95rg-cppp は、API トークンを露出させ、ローカルコードの実行につながる可能性がある、重大なブラウザーランナーのスクリプトインジェクションです。影響を受けるのは @vitest/browser >=4.0.17,<4.1.6 および >=5.0.0-beta.0,<5.0.0-beta.3 です。修正バージョンは 4.1.6 と 5.0.0-beta.3 です。ブラウザーパッケージは安定版ランナーとバージョンをそろえ、サーバーが稼働中に信頼できないランナーの URL を開かないでください。後続の重大なブラウザーモードのアドバイザリー（GHSA-g8mr-85jm-7xhm、GHSA-p63j-vcc4-9vmv）により、4.x の最低バージョンは 4.1.10、3.x の最低バージョンは 3.2.7 に引き上げられています。10月21日のアドバイザリーで、これらはさらに引き上げられています： GHSA-p458-7748-mcp3（server.fs.deny のバイパスにより .env、鍵、API トークンが提供される問題。@vitest/ui／@vitest/browser <5.0.5）および GHSA-qxg6-89mg-rqv8（モック登録コードのインジェクション。@vitest/mocker <4.1.12 および 5.0.x <5.0.3）。最低バージョンは 5.0.5 と 4.1.12 です。3.x には修正リリースがないため、使用を終了してください。

使用する場面

新しいテストの作成（ユニット、統合、E2E、アクセシビリティ、パフォーマンス）
不安定なテストや失敗するテストのデバッグ
プロジェクトのテストアーキテクチャの設計（フィクスチャ戦略、ファクトリーパターン、テストデータ）
CI でのテストインフラストラクチャの設定（並列化、シャーディング、カバレッジゲート）
テストツールの選定、またはテストフレームワーク間の移行
変更を保護するために必要な、最小限のテストセットの選定
既存のテストスイートへのアクセシビリティテストやビジュアルリグレッションテストの追加

使用しない場面

特定済みのアプリケーションのボトルネックのプロファイリングと最適化 — performance-debugging を使用してください。
ブローカーの確認応答、再配信、デッドレター、またはリプレイのセマンティクス — message-queues を使用してください。
コードレビューの一環として既存テストの品質や正確性を確認する場合 — code-review を使用してください。
セキュリティに特化したテスト（ペネトレーションテスト、OWASP チェック） — security-audit を使用してください。
冗長または雑然としたテストコードの整理 — code-simplification を使用してください。
テスト以外でのアドホックなウェブ閲覧、スクレイピング、ページ操作 — ホストのブラウジングツールを使用してください。
CI/CD パイプラインのアーキテクチャ（テストジョブはパイプライン内で実行されますが、パイプライン設計の領域は ci-cd です） — ci-cd を使用してください。
エンジンレベルのデータベーステストパターン — databases を使用してください。
LLM プロンプトの作成または改善 — prompt-generator を使用してください。
テスト以外でのインフラストラクチャや構成の検証 — terraform、ansible、または kubernetes を使用してください。
AI／ML モデルの評価や LLM 出力のスコアリング — llm-app-development を使用してください。
アプリケーションテストの範囲を超えるインフラストラクチャレベルの負荷テストやカオステスト — クラスター単位のカオステストには kubernetes を、パイプラインに統合された負荷テストのオーケストレーションには ci-cd を使用してください。

比例性

変更の規模に合わせてテストスイートを調整します。すべての関数をテストしたり、テスト数を追い求めたりする必要はありません。

動作ごとにテストを1つ用意し、現実的な失敗ケース（不正な入力、境界値、エラーパス）も含めます。同じ動作に対する異なる入力は、個別のテストではなく1つのパラメータ化テストにまとめます。
グルーコード、配線、設定、ゲッター、フレームワークや型システムですでに保証されている動作のテストは省略します。
新しいテストがおよそ5件を超える場合、またはテストのほうがテスト対象のコードより長い場合は、それぞれのテストが必要な理由を明示するか、削除します。
バグ修正では、修正前に失敗する回帰テストを1つ用意します。テストスイートは不要です。
動作が壊れたときに失敗するテストを、必要最小限の数にします。

AI のセルフチェック

AI ツールは、テストに関する同じ間違いを繰り返し犯します。生成したテストコードを返す前に、次のリストに照らして確認してください。

パフォーマンス

高速な単体テストを、統合テスト、ブラウザテスト、パフォーマンステストのスイートから分離します。
フィクスチャとテストデータビルダーを使い、コストの高いセットアップの繰り返しを避けます。
共有状態、ポート、データベース、クロックを分離してから、シャーディングや並列化を行います。

ワークフロー

このチェックリストをコピーして、進捗を記録します：

ステップ 1：対象範囲と既存のフレームワークを特定する
ステップ 2：テスト層を選ぶ
ステップ 3：テストを書く（バグ修正の場合は、修正前に失敗することを確認する）
ステップ 4：影響を受けるチェックに合格する。テスト対象の動作が原因ではない失敗は、ステップ 3 を通じて修正する

ステップ 1：対象範囲を決める

状況に応じて：

新機能 → すべての関数ではなく、重要な動作をコードと並行して、またはコード作成後にテストする
バグ修正 → まずバグを再現する失敗テストを1つ書き、その後に修正する
既存の未テストコード → 100％のカバレッジではなく、重要な処理経路を優先する
テストインフラストラクチャ → ランナー、CI 設定、カバレッジゲートをセットアップする

設定ファイル（vitest.config.ts、jest.config.*、pyproject.toml、Cargo.toml、*_test.go、playwright.config.ts）から、プロジェクトで既に使われているテストフレームワークを特定します。それに合わせてください。理由なく2つ目のテストランナーを導入しないでください。

ステップ 2：テストレイヤーを選ぶ

レイヤー	テスト対象	速度	使用する場面
ユニット	単独で動作する単一の関数／モジュール	ms	純粋なロジック、ユーティリティ、データ変換、状態機械
インテグレーション	複数のモジュールと実際の依存関係	秒	API ハンドラー、データベースクエリ、サービス境界
E2E	UI を通じたユーザーフロー全体	秒〜分	重要な経路、購入フロー、認証、オンボーディング
アクセシビリティ	WCAG 準拠、スクリーンリーダーとの互換性	秒	変更が及ぶ、ユーザー向けのコンポーネント／ページ
ビジュアル	スクリーンショットの比較	秒	スタイル変更後の UI コンポーネント
パフォーマンス	負荷、レイテンシー、スループット	分	リリース前、アーキテクチャ変更後

ピラミッドが示すのはテストの配置であり、ノルマではありません。 不具合を検出できる範囲で、各チェックを最も低コストなレイヤーに配置してください。レイヤーを埋めるためだけにテストを書かないでください。ピラミッドを逆転させる（ユニットテストでカバーできるロジックを遅い E2E チェックでテストする）と、CI に 45 分かかるようになり、失敗も無視されるようになります。動作が壊れた場合に失敗する、必要最小限のテストを優先してください。

ステップ 3：テストを書く

以下の言語ごとのパターンに従ってください。共通する原則：

Arrange-Act-Assert（または Given-When-Then）：

// Arrange: set up test data and dependencies
// Act: call the thing being tested
// Assert: verify the outcome

テストの命名：関数ではなく、シナリオを説明してください。

# Bad:  test_calculate_total
# Good: test_calculate_total_applies_discount_when_cart_exceeds_100
# Good: it("returns 401 when token is expired")

ステップ 4：検証する

変更した動作に適したチェックと、リポジトリで必須とされるすべてのチェックを実行します。必要な場合、または影響範囲に応じて実施が妥当な場合は、テストスイート全体を実行してください。元に戻せて影響が小さい編集をそのまま反映するテストは追加しないでください。合格したチェックを再実行したり、範囲を広げたりするのは、新たな変更、失敗、または未解決の懸念がある場合に限ってください。
新しいテストが、テスト対象の動作以外の理由で失敗する場合は、テストまたはフィクスチャを修正してステップ 3 に戻ります
カバレッジの差分は、見落とした動作を見つける手がかりとして確認し、目標値にはしないでください。新しいコードがあるからといって数値を追う必要はありません。また、カバレッジを理由にテストを追加してはいけません
可能であれば CI でも実行してください。ローカルでは合格するのに CI では失敗するテストが、最も厄介です

TDD ワークフロー

任意です。事前に動作が明確に定義されているバグ修正や複雑なロジックには、レッド・グリーンを使用してください。これは、テストなしでコードを書いてはいけない、またはすべての関数にテストが必要、という意味ではありません。調査やプロトタイピングでは省略してください。

レッド：失敗するテストを書く（適切な理由で失敗することを確認します）
グリーン：テストに合格するための最小限のコードを書く（見た目が悪くてもかまいません）
リファクタリング：動作を変えずに整理する（テストは引き続き合格します）

TDD が特に効果的なのは、純粋関数、データ変換、状態機械、API コントラクト、バグの再現です。

TDD があまり効果的でないのは、UI レイアウト、探索的なプロトタイピング、ドキュメント化されていない API との連携です。

モック戦略

あらゆる場所をモックするのではなく、境界でモックします。過剰なモックは、実際のコードが壊れていてもテストが通る状態を生みます。

モックする対象	モックしない対象
外部 API（HTTP、gRPC）	独自の純粋関数
データベース（単体テスト時）	データ変換
時刻／日付、乱数値	単純なユーティリティコード
ファイルシステム（現実的でない場合）	テスト対象のモジュール
サードパーティ製 SDK	標準ライブラリ関数

可能な場合はモックよりフェイクを優先します。 インメモリのデータベース実装を使うと、定型の応答を返すモックよりも多くの実際の動作をテストできます。

TTL／時刻に依存するテストでは、注入可能なクロックを使用します - Date.now() や time.Now() を直接呼び出すのではなく、クロック依存関係を渡します。

// Production: clock = () => Date.now()
// Test: clock = () => FIXED_TS + offset
function isExpired(createdAt: number, ttlMs: number, clock = Date.now): boolean {
  return clock() - createdAt > ttlMs;
}
// In test: advance virtual time without sleeping
const fakeNow = vi.fn().mockReturnValue(START);
expect(isExpired(START, 1000, fakeNow)).toBe(false);
fakeNow.mockReturnValue(START + 1001);
expect(isExpired(START, 1000, fakeNow)).toBe(true);

キャッシュ付きフェッチでは、観測可能なパスを網羅します（セットアップが共通する場合は、パラメーター化したテストまたは連続したテストを1つ実施します）。

キャッシュミス：HTTP 境界が1回呼び出され、返された値がキャッシュされます。
キャッシュヒット：キャッシュされた値が返され、HTTP 境界は呼び出されません。
TTL の期限切れ：注入したクロックまたはフェイククロックを進めてから、スリープせずに1回更新されることを検証します。

言語ごとのモックの慣用パターン（Vitest の vi.mock、Jest の jest.mock、pytest の monkeypatch、Go のインターフェース、Rust のトレイトオブジェクト）については、references/language-patterns.md を参照してください。

テストデータとフィクスチャ

ファクトリーパターン（推奨）

適切なデフォルト値とテストごとのオーバーライドを使ってテストデータを作成します。

// TypeScript - factory function
function buildUser(overrides: Partial<User> = {}): User {
  return { id: randomUUID(), name: "Test User", email: "[email protected]", ...overrides };
}

// Python - factory function
def build_user(**overrides) -> User:
    defaults = {"id": uuid4(), "name": "Test User", "email": "[email protected]"}
    return User(**(defaults | overrides))

フィクスチャのルール

テストごとに分離します。 変更可能なフィクスチャを共有すると、実行順序に依存する失敗が発生します。
生のオブジェクトリテラルよりビルダー／ファクトリーを使用します - デフォルト値によってテストが壊れやすくなるのを防げます。
データベースのフィクスチャ：各テストの後にロールバックするトランザクションを使用します（pytest の db フィクスチャ、Jest のロールバックを伴う beforeEach）。共有のステージングデータより、テスト用にシードしたデータベースを優先します。
ファイルのフィクスチャ：一時ディレクトリを使用します（pytest の tmp_path、Go の os.MkdirTemp、Rust の tempfile）。ティアダウン時にクリーンアップします。

アクセシビリティテスト

WCAG 違反を自動的に検出します。手動テストの代わりにはなりませんが、機械的に検出できる問題（代替テキストの欠落、ARIA の不備、コントラスト比、キーボードトラップ）を見つけられます。

@axe-core/playwright を使用します（見つからない場合は、リポジトリのパッケージマネージャーを使って開発依存関係として追加します：npm install -D、pnpm add -D、yarn add -D、または bun add -d @axe-core/playwright）。new AxeBuilder({ page }).withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa"]).analyze() を実行し、違反がゼロであることを検証します。axe のスキャン対象は、変更のたびにアプリ全体とするのではなく、変更が加わるページやコンポーネントに絞ります。既知の問題は .exclude() で除外し、恒久的な例外にするのではなく、技術的負債として記録します。

再現可能なアクセシビリティ回帰チェックはここで管理し、インタラクションデザインとセマンティクスの修正には frontend-design を使用します。手動でのキーボード操作とスクリーンリーダーのカバレッジは、自動スキャンの結果とは別に記録します。

Playwright の E2E パターン、ビジュアル回帰のセットアップ、CI のアクセシビリティゲートについては、references/e2e-accessibility.md を参照してください。

パフォーマンステスト

マイクロベンチマーク（この関数は十分に高速か）と負荷テスト（システムはトラフィックに対応できるか）の2種類があります。

マイクロベンチマーク

Go：func BenchmarkX(b *testing.B) - 標準ライブラリに組み込まれています
Rust：criterion を使った cargo bench（criterion = "0.8"）
JS/TS：vitest bench（Vitest の外では tinybench を直接使用します）
Python：pytest-benchmark（1回限りの測定には timeit）

負荷テスト（k6）

まず検出します：command -v k6 >/dev/null || echo "k6 missing"。

// k6 load test
import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "30s", target: 50 },   // ramp up
    { duration: "1m",  target: 50 },   // sustain
    { duration: "10s", target: 0 },    // ramp down
  ],
  thresholds: {
    checks: ["rate==1"],              // fail the run when any status check fails
    http_req_duration: ["p(95)<500"],   // 95th percentile under 500ms
  },
};

export default function () {
  const res = http.get("http://localhost:3000/api/health");
  check(res, { "status 200": (r) => r.status === 200 });
  sleep(1);
}

明示的な承認なしに、本番環境に対して負荷テストを実行しないでください。専用のインフラストラクチャがない場合は、CI で実行しないでください。

CI 統合

テストの並列化

Vitest/Jest：組み込みのワーカー並列処理を使用します。Vitest は Vite のモジュールグラフを使って、テストファイルを効率的に分散します。
Playwright：CI ランナー間で分割するには --shard=1/4 を使用します。1 台のランナー内で並列実行するには --workers=4 を使用します。
pytest：pytest-xdist と -n auto を使用して、CPU に基づく並列処理を行います。
Go：パッケージごとの並列処理には go test -parallel N、パッケージ単位の並列処理には -p N を使用します。
Rust：テストごとのプロセス分離と並列処理には cargo nextest run を使用します（cargo nextest --version >/dev/null 2>&1 || echo "cargo-nextest missing: cargo install cargo-nextest"）。

不安定なテストの管理

不安定なテストは信頼を損ないます。すぐに修正するか、隔離してください。

特定する：時間の経過に伴うテストの安定性を追跡します（ほとんどの CI システムには、不安定なテストを確認するダッシュボードがあります）
隔離する：マージを妨げない別のジョブに移します。@flaky または skip のタグを付けます。
根本原因を修正する - フレームワークごとの一般的な原因：
- Playwright/Cypress：ナビゲーションやアニメーションでの競合状態。waitForLoadState、 waitForSelector、または Playwright の自動待機を使用します。page.waitForTimeout は避けてください。バックエンドの変動をなくすため、ネットワークリクエストをスタブ化します。テストごとに新しいブラウザーコンテキストを作成し、Cookie、ストレージ、サービスワーカーがテスト間で漏れないようにします。ヘッドレスモード（CI）では、ヘッドありの場合と描画のタイミングが異なります。まず CI と同じヘッドレスブラウザー、OS イメージ、ビューポート、フォント、ワーカー数を使って再現し、描画の違いを切り分ける場合にのみ --headed と比較します。タイムアウトを変更する前に、CI ランナー上の CPU、メモリ、ワーカーの競合を確認してください。
- Vitest/Jest：テストファイル間でモジュールの状態が共有されています。分離するには --pool forks（Vitest）または --runInBand（Jest）を使用します。タイマーの漏れがないか確認してください（vi.useFakeTimers が復元されていないなど）。
- pytest：テスト間でデータベースの状態が漏れています。トランザクションによるロールバックとともに @pytest.mark.usefixtures("db") を使用します。フィクスチャ内でグローバル状態が変更されていないか確認してください。
- Go：t.Parallel() を使うテスト間で、パッケージレベルの状態が共有されています。終了処理には t.Cleanup を使用します。 goleak を使ってゴルーチンのリークを確認してください。
慎重に再試行する：--retries 2（Playwright）や --reruns 2（pytest-rerunfailures）は一時しのぎであり、解決策ではありません。

カバレッジのしきい値

すでにカバレッジのゲートを設定しているプロジェクトでは、これらを CI ゲートの目安として維持してください。それ以外の場合、小さな変更に対して新たにゲートを導入しないでください。妥当なデフォルト値は次のとおりです。

指標	しきい値	理由
行カバレッジ	80%	明らかな漏れを検出します
分岐カバレッジ	70%	テストされていない条件を検出します

しきい値は CI ゲートであり、目標ではありません。数値を上げるためだけにテストを追加してはいけません。vitest --coverage --coverage.thresholds.lines=80、pytest --cov --cov-fail-under=80、または go test -coverprofile としきい値スクリプトを使って適用します。

最小限の CI の例（pytest + GitHub Actions）：

- run: pip install pytest pytest-xdist pytest-cov
- run: pytest -n auto --cov=src --cov-fail-under=80 --tb=short

参照ファイル

references/language-patterns.md - JS/TS（Vitest、Jest）、Python（pytest）、Go（標準 testing パッケージ）、Rust（cargo test）向けの言語固有のテストパターンです。モック、テーブル駆動テスト、非同期テスト、スナップショットテスト、フレームワーク固有のイディオムを扱います。
references/e2e-accessibility.md - Playwright による E2E テスト、ビジュアルリグレッション（スクリーンショット比較、コンポーネントスナップショット）、アクセシビリティテストのパターン、ブラウザーテストの CI 統合について説明します。

出力規約

規約の全文は references/output-contract.md を参照してください。

スキル名： TESTING
成果物の分類： audits
モード： 条件付きです。既存のリポジトリ内容の分析、レビュー、監査、改善を依頼された場合は、references/output-contract.md のレポートの規模と根拠に関するルールを適用し、成果物を docs/local/audits/testing/<YYYY-MM-DD>-<slug>.md に書き込みます。質問への回答、概念の説明、新しい成果物の作成、コンテンツの生成を依頼された場合は、規約に従わず自由に回答します。
重大度の尺度： P0 | P1 | P2 | P3 | info（共通規約を参照。監査／レビューのモードでのみ使用します）。

ルール

AI Self-Check では、テストごとのガード（実装ではなく振る舞いを検証する、sleep() を使わない、状態を分離する、不安定なテストを診断する、スナップショットをレビューする）を扱います。ここでは、次の点を追加します。

フレームワークをテストしないでください。 React が div をレンダリングすることや、Express がハンドラーにルーティングすることをテストするのは、他人のコードをテストしていることになります。自分のロジックをテストしてください。
テストの肥大化。 1 つの振る舞いに対するほぼ重複したテスト、実装を言い換えただけのテスト、モックを使いすぎたテストです。「比例性」を参照してください。

Markdown 対応

ログインしてコメント

基本情報

作者: iuliandita
リポジトリ: iuliandita/skills
カテゴリ: テスト・品質
インストール数: 49
GitHub スター: 10

問題を報告