backend-test-writer
Use when generating tests for backend code (Express routes, MongoDB models, Node services) - analyzes file type, detects test framework from package.json, generates comprehensive tests with setup/teardown and edge case coverage
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
バックエンドテストライター
MERNスタックコード用の包括的なバックエンドテストを生成します。ファイルタイプを分析し、プロジェクトの慣例を検出し、実際に実行されるテストを作成します。
哲学: スマートなデフォルト、ゼロコンフィグ。プロジェクトからすべてを検出します。
ワークフロー
進捗をコピーして追跡します。
- [ ] フェーズ0: インフラストラクチャチェック
- [ ] フェーズ1: ターゲットファイルの分析
- [ ] フェーズ2: テストの生成
- [ ] フェーズ3: サマリーの報告
フェーズ0: インフラストラクチャチェック
テストを生成する前に、セットアップを確認します。
package.jsonでテストフレームワーク(Jest/Vitest/Mocha)を確認します。- なければ、「Jest + Supertestをセットアップしますか?」とプロンプトを表示します。
mongodb-memory-server(統合テストに必要)を確認します。- テストファイルの慣例(colocated vs
__tests__/vstests/)を検出します。
停止条件: テストフレームワークがなく、ユーザーがセットアップを拒否した場合。
フェーズ1: ターゲットファイルの分析
| パターン | タイプ | テストアプローチ |
|---|---|---|
routes/, *.routes.js |
ルート | 統合(Supertest + 実際のDB) |
controllers/ |
コントローラー | 統合 |
services/ |
サービス | ユニット(モックされた依存関係) |
models/, *.model.js |
モデル | ユニット(バリデーションテスト) |
middleware/ |
ミドルウェア | ユニット(モックされたreq/res/next) |
utils/, helpers/ |
ユーティリティ | ユニット(純粋関数) |
上書き: ユーザーは--unitまたは--integrationを指定できます。
フェーズ2: テストの生成
ファイルを順次処理し、進捗を表示します。ユーザーはいつでも停止できます。
各テストに含まれるもの:
- 検出されたフレームワーク用の適切なインポート
- セットアップ/ティアダウン(DB接続、クリーンアップ)
- 包括的なカバレッジ:
- 成功ケース(ハッピーパス)
- バリデーションエラー(400)
- 見つからない(404)
- 保護されている場合の認証失敗(401/403)
- エッジケース(重複、空、null)
参照: 完全なコード例については、test-patterns.mdを参照してください。
フェーズ3: レポート
Generated: X test files
Coverage: Y test cases total
Next: Run `npm test` to verify
クイックリファレンス
| ファイルタイプ | インポート | DBセットアップ |
|---|---|---|
| ルート | supertest, mongodb-memory-server |
リアル(インメモリ) |
| サービス | jest |
モック |
| モデル | mongoose |
モック |
| ミドルウェア | jest |
なし |
テスト構造パターン
describe('[Resource] [Method]', () => {
describe('success cases', () => {
it('should [expected behavior]', async () => {});
});
describe('validation errors', () => {
it('should return 400 for [invalid case]', async () => {});
});
describe('edge cases', () => {
it('should handle [edge case]', async () => {});
});
});
チェックリスト
インフラストラクチャ(最初に確認)
- [ ]
package.jsonにテストフレームワークがあること - [ ] テストスクリプトが定義されていること(
"test": "jest") - [ ] Supertestがインストールされていること(統合テスト)
- [ ] mongodb-memory-serverがインストールされていること(DBテスト)
ファイルごとの生成
- [ ] 既存のテストを最初に確認すること(見つかった場合はギャップ分析)
- [ ] ファイルタイプに応じた正しいインポート
- [ ] セットアップ/ティアダウンが含まれていること
- [ ] ハッピーパスがテストされていること
- [ ] エラーケースがテストされていること(400、404、401)
- [ ] エッジケースがテストされていること(ドメイン固有:日付→DST/タイムゾーン、金額→精度など)
- [ ] アサーションに秘密情報がないこと
- [ ] Async/awaitが適切に処理されていること
- [ ] 各テストに優先度が割り当てられていること(P0=クリティカル、P1=重要、P2=あれば良い)
- [ ] 複雑な入力に対してテストヘルパーファクトリが提案されていること
よくある間違い
| 間違い | 修正 |
|---|---|
| テストでサーバーを起動する | アプリをインポートし、Supertestに処理させる |
| DBクリーンアップがない | afterEachにdeleteMany({})を追加する |
| 実装をテストする | HTTPインターフェースを通じて動作をテストする |
| async/awaitの欠落 | 非同期操作をawaitする |
| 統合テストでのモック | 統合には実際のDBを使用する |
ガイドライン
- 未読のコードのテストは生成しない
- インフラストラクチャチェックをスキップしない
- ハッピーパスのみを生成しない
- テスト間のクリーンアップを忘れない
参照ファイル
特定のパターンを実装する際にロードします。
| いつ | 参照 |
|---|---|
| 任意のテストを作成する際 | test-patterns.md |
| テストインフラストラクチャをセットアップする際 | test-setup.md |
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Backend Test Writer
Generate comprehensive backend tests for MERN stack code. Analyzes file type, detects project conventions, produces tests that actually run.
Philosophy: Smart defaults, zero config. Detect everything from project.
<workflow>
Workflow
Copy and track progress:
- [ ] Phase 0: Infrastructure check
- [ ] Phase 1: Analyze target files
- [ ] Phase 2: Generate tests
- [ ] Phase 3: Report summary
Phase 0: Infrastructure Check
Before generating tests, verify setup:
- Check
package.jsonfor test framework (Jest/Vitest/Mocha) - If none → prompt: "Set up Jest + Supertest?"
- Check for
mongodb-memory-server(needed for integration tests) - Detect test file convention (colocated vs
__tests__/vstests/)
Stop if: No test framework and user declines setup.
Phase 1: Analyze Target Files
| Pattern | Type | Test Approach |
|---|---|---|
routes/, *.routes.js |
Route | Integration (Supertest + real DB) |
controllers/ |
Controller | Integration |
services/ |
Service | Unit (mocked deps) |
models/, *.model.js |
Model | Unit (validation tests) |
middleware/ |
Middleware | Unit (mock req/res/next) |
utils/, helpers/ |
Utility | Unit (pure functions) |
Override: User can specify --unit or --integration.
Phase 2: Generate Tests
Process files sequentially with progress. User can stop anytime.
Each test includes:
- Proper imports for detected framework
- Setup/teardown (DB connection, cleanup)
- Comprehensive coverage:
- Success cases (happy path)
- Validation errors (400)
- Not found (404)
- Auth failures (401/403) if protected
- Edge cases (duplicates, empty, null)
Reference: See test-patterns.md for complete code examples.
Phase 3: Report
Generated: X test files
Coverage: Y test cases total
Next: Run `npm test` to verify
</workflow>
<quick-reference>
Quick Reference
| File Type | Imports | DB Setup |
|---|---|---|
| Route | supertest, mongodb-memory-server |
Real (in-memory) |
| Service | jest |
Mocked |
| Model | mongoose |
Mocked |
| Middleware | jest |
None |
Test Structure Pattern
describe('[Resource] [Method]', () => {
describe('success cases', () => {
it('should [expected behavior]', async () => {});
});
describe('validation errors', () => {
it('should return 400 for [invalid case]', async () => {});
});
describe('edge cases', () => {
it('should handle [edge case]', async () => {});
});
});
</quick-reference>
<checklists>
Checklists
Infrastructure (Check First)
- [ ] Test framework in
package.json - [ ] Test script defined (
"test": "jest") - [ ] Supertest installed (integration tests)
- [ ] mongodb-memory-server installed (DB tests)
Per-File Generation
- [ ] Check for existing tests first (gap analysis if found)
- [ ] Correct imports for file type
- [ ] Setup/teardown included
- [ ] Happy path tested
- [ ] Error cases tested (400, 404, 401)
- [ ] Edge cases tested (domain-specific: date→DST/timezone, money→precision, etc.)
- [ ] No secrets in assertions
- [ ] Async/await handled properly
- [ ] Priority assigned to each test (P0=critical, P1=important, P2=nice-to-have)
- [ ] Test helper factories suggested for complex inputs
</checklists>
<common-mistakes>
Common Mistakes
| Mistake | Fix |
|---|---|
| Starting server in tests | Import app, let Supertest handle it |
| No DB cleanup | Add afterEach with deleteMany({}) |
| Testing implementation | Test behavior through HTTP interface |
| Missing async/await | Await async operations |
| Mocking in integration tests | Use real DB for integration |
</common-mistakes>
<guidelines>
Guidelines
- Don't generate tests for unread code
- Don't skip infrastructure check
- Don't generate only happy paths
- Don't forget cleanup between tests
</guidelines>
<references>
Reference Files
Load when implementing specific patterns:
| When | Reference |
|---|---|
| Writing any test | test-patterns.md |
| Setting up test infrastructure | test-setup.md |
</references>