skanehira

writing-tests

@skanehira/writing-tests
skanehira
80
4 forks
Updated 1/6/2026
View on GitHub

TDD方法論に従ってテストを作成します。テストファイルの配置(コロケーション)、命名規則、テスト構造のベストプラクティスに従います。React/TypeScript、Go、Rustで適切なパターンを使い分けます。「テストを書いて」「テストを作成」「単体テストを追加」などのリクエストで起動します。

Installation

$skills install @skanehira/writing-tests
Claude Code
Cursor
Copilot
Codex
Antigravity

Details

Pathclaude/skills/writing-tests/SKILL.md
Branchmain
Scoped Name@skanehira/writing-tests

Usage

After installing, this skill will be available to your AI coding assistant.

Verify installation:

skills list

Skill Instructions


name: writing-tests description: TDD方法論に従ってテストを作成します。テスト対象コードの分析、AAA/Given-When-Thenパターンの適用、正常系・エッジケース・エラー系のカバレッジを確保します。「テストを書いて」「テストを作成」「単体テストを追加」などのリクエストで起動します。

テスト作成

TDD方法論に従ってテストを作成する。

参照ルール

  • テストルール: rules/core/testing.md(AAA、命名規則、テストダブル)
  • 設計原則: rules/core/design.md(コロケーション)
  • TDDルール: rules/core/tdd.md

ワークフロー

ステップ1: テスト対象の確認

テスト対象のコードを読み込み、以下を把握する:

  • 対象の機能/メソッドの責務
  • 入力と出力の型
  • エッジケースと境界条件
  • 依存関係(モックが必要か)

ステップ2: リファレンスの読み込み(必須)

Claude指示: テストを書く前に、必ず対応するリファレンスファイルをReadツールで読み込んでください。

プロジェクトの言語を特定し、以下のリファレンスをReadツールで読み込む:

言語/フレームワークリファレンス
React + TypeScriptreferences/react-typescript.md
Goreferences/go.md
Rustreferences/rust.md
// 例: Goプロジェクトの場合
Read(file_path=".claude/skills/writing-tests/references/go.md")

リファレンスを読まずにテストを書くことは禁止です。

ステップ3: テストファイルの配置

テストは実装の近くに配置する(コロケーション)。 詳細は rules/core/design.md を参照。

ステップ4: テスト命名

テスト名には3要素を含める。詳細は rules/core/testing.md を参照。

ステップ5: テスト構造

AAA (Arrange-Act-Assert) パターンを基本とする。 詳細は rules/core/testing.md を参照。

ステップ6: テストの種類と優先度

テスティングトロフィー(優先順位):

  1. 単体テスト(基盤): 高速、集中、多数
  2. 統合テスト(中間): コンポーネント間の相互作用
  3. E2Eテスト(頂点): 最小限だが重要なユーザーフロー

ステップ7: モック

依存性注入を活用してテスト可能にする。 テストダブルの種類は rules/core/testing.md を参照。

必須テストケース

  • 正常系: 期待通りの入力で期待通りの出力
  • エッジケース: 境界値、空の入力、最大値/最小値
  • エラー系: 不正な入力、例外処理

セルフレビュー

テスト作成後、以下のチェックリストで確認する。

  • テスト名が3要素(何を、条件、結果)を含んでいる
  • AAA/Given-When-Thenパターンに従っている
  • 正常系・エッジケース・エラー系をカバー
  • テストが独立していて他のテストに依存しない
  • モックが適切に使用されている
  • テストが高速に実行できる

More by skanehira

View all
ddd-modeling
82

ドメインエキスパートとの対話を通じてユビキタス言語(用語集)とドメインモデルを作成する。新規プロジェクト開始時のドメイン理解、既存システムのリファクタリング前のモデル整理、チーム内での用語統一が必要な場合に使用。「DDDでモデリングしたい」「ドメインモデルを作成」「用語集を整理」「ユビキタス言語を定義」などのリクエストで起動。

slc-ideation
82

SLC(Simple, Lovable, Complete)フレームワークに基づいてプロダクトアイデアの壁打ちを行います。対話的な質問を通じてアイデアを洗練し、SLCの3要素を満たすまで繰り返し検証します。最終的にプロダクト仕様書を生成します。「プロダクトアイデアを壁打ちしたい」「新規プロダクトの企画」「アイデアをSLCで検証」などのリクエストで起動します。

reviewing-skills
80

Claude Codeスキルを公式ベストプラクティスに基づいてレビューします。SKILL.mdファイルのレビュー、スキル品質のチェック、スキル構造の検証、改善提案が必要な場合に使用します。「このスキルをレビューして」「スキル品質をチェック」「SKILL.mdを検証」「このスキルを改善」などのリクエストで起動します。

planning-tasks
80

承認済みの設計書(DESIGN.md)からTDD準拠のTODO.mdを作成します。analyzing-requirementsスキルで設計が完了・承認された後に使用します。developingスキルで実装できる形式のタスクリストを生成します。