このスキルは factory 関数、カスタムレンダーユーティリティ、モック戦略など、開発者がTDD原則に従って保守性が高くDRYなテストを書けるようにする、Jestテストパターンをすぐに使える状態で提供します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「testing-patterns」を使用しています。 ユーザーデータ用のfactory関数を作成
期待される結果:
```typescript
interface User {
id: string;
name: string;
email: string;
role: 'admin' | 'user';
}
const getMockUser = (overrides?: Partial<User>): User => ({
id: '123',
name: 'John Doe',
email: 'john@example.com',
role: 'user',
...overrides,
});
```
「testing-patterns」を使用しています。 カスタムレンダー関数を教えてください
期待される結果:
```typescript
export const renderWithTheme = (ui: React.ReactElement) => {
return render(
<ThemeProvider>{ui}</ThemeProvider>
);
};
```
「testing-patterns」を使用しています。 テストはどのように構造化すれば良いですか？
期待される結果:
describeブロックを使用して関連するテストをグループ化してください: describe('ComponentName', () => { describe('Rendering', () => {...}); describe('User interactions', () => {...}); describe('Edge cases', () => {...}); });
セキュリティ監査
安全Security review completed. All 42 static findings are false positives triggered by the static analyzer misinterpreting: (1) markdown code formatting backticks as shell commands, (2) TypeScript generics like Partial<X> as cryptographic patterns, and (3) the word 'APIs' as network reconnaissance. The skill is legitimate Jest testing documentation with no security concerns.
品質スコア
作れるもの
テストインフラストラクチャの設定
ThemeProviderなどの必要なプロバイダーでコンポーネントをラップするカスタムレンダー関数とfactoryユーティリティを作成し、すべてのテストでのボイラープレートを減らします。
保守性の高いユニットテストの記述
factory関数を使用して一貫性のあるテストデータを生成し、テストの読みやすさ、保守性、データ構造変更時の更新を容易にします。
TDD手法の適用
red-green-refactorサイクルを適用し、まず失敗するテストを書き、次にそれをパスするための最小限の実装を行い、テストが開発を駆動することを保証します。
これらのプロンプトを試す
Reactコンポーネントの基本的なテストファイルのセットアップを手伝ってください。ThemeProviderでコンポーネントをラップするカスタムレンダー関数の作り方を教えてください。
getMockUserというfactory関数を作成し、id、name、email、roleのデフォルト値を持つユーザオブジェクトを返してください。Partial型を使って特定のプロパティをオーバーライドする方法も教えてください。
Jestで 'utils/analytics' のようなモジュールをモックする方法を教えてください。テストでモックにアクセスする方法と、モックの戻り値をモックする方法を含めるでください。
新機能を追加するためのTDDワークフローを教えてください。まず失敗するテストを書き、次にそれをパスするための最小限の実装を示すことから始めてください。
ベストプラクティス
- propsとデータには常にfactory関数を使用して、テストをDRYで一貫性のあるものに保つ
- 実装の詳細ではなく、パブリックAPIを通じて動作をテストする
- テスト哪些説明的な名前を使用して@Testされる動作を明確に伝える
回避
- 実際のコンポーネントの動作ではなくモックの動作をテストすることを避ける
- テスト間でテストデータを複製せず、factory関数を使用する
- リファクタリング時に変更的可能性のある実装の詳細をテストすることを避ける