react18-enzyme-to-rtl
React 18へのアップグレードに伴うEnzymeからReact Testing Library(RTL)への移行パターンを提供します。`shallow`・`mount`・`wrapper.find()`・`wrapper.simulate()`・`wrapper.state()`・`wrapper.instance()`などEnzymeのAPIや、enzymeからimportしているテストファイルを書き直す際に必ず参照してください。実装テストから振る舞いテストへの思想的な転換を含むAPIマッピングを網羅しており、EnzymeのAPIを1対1で置き換えるだけの脆いRTLテストを生まないよう、書き直し前に必ず読み込んでください。
description の原文を見る
Provides exact Enzyme → React Testing Library migration patterns for React 18 upgrades. Use this skill whenever Enzyme tests need to be rewritten - shallow, mount, wrapper.find(), wrapper.simulate(), wrapper.prop(), wrapper.state(), wrapper.instance(), Enzyme configure/Adapter calls, or any test file that imports from enzyme. This skill covers the full API mapping and the philosophy shift from implementation testing to behavior testing. Always read this skill before rewriting Enzyme tests - do not translate Enzyme APIs 1:1, that produces brittle RTL tests.
SKILL.md 本文
React 18 Enzyme → RTL 移行
Enzyme には React 18 アダプタがなく、React 18 をサポートするパスはありません。すべての Enzyme テストは React Testing Library を使用して書き直す必要があります。
哲学的シフト(まずこれを読んでください)
Enzyme は実装をテストします。RTL は動作をテストします。
// Enzyme: コンポーネントが正しい内部状態を持つことをテストする
expect(wrapper.state('count')).toBe(3);
expect(wrapper.instance().handleClick).toBeDefined();
expect(wrapper.find('Button').prop('disabled')).toBe(true);
// RTL: ユーザーが実際に見えて行える動作をテストする
expect(screen.getByText('Count: 3')).toBeInTheDocument();
expect(screen.getByRole('button', { name: /submit/i })).toBeDisabled();
これは 1:1 翻訳ではありません。内部状態またはインスタンスメソッドを検証する Enzyme テストには RTL の同等物がありません。RTL は意図的に内部を公開していないからです。代わりに、目に見える結果を確認するようにテストを書き直してください。
API マップ
各 Enzyme API の完全な前後のコードについては、以下を参照してください:
references/enzyme-api-map.md- 完全なマッピング: shallow、mount、find、simulate、prop、state、instance、configurereferences/async-patterns.md- waitFor、findBy、act()、Apollo MockedProvider、ローディング状態、エラー状態
コア書き直しテンプレート
// すべての Enzyme テストはこの形に書き直されます:
import { render, screen, fireEvent, waitFor } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import MyComponent from './MyComponent';
describe('MyComponent', () => {
it('does the thing', async () => {
// 1. レンダリング (shallow/mount を置き換え)
render(<MyComponent prop="value" />);
// 2. クエリ (wrapper.find() を置き換え)
const button = screen.getByRole('button', { name: /submit/i });
// 3. インタラクション (simulate() を置き換え)
await userEvent.setup().click(button);
// 4. 目に見える出力を断定 (wrapper.state() / wrapper.prop() を置き換え)
expect(screen.getByText('Submitted!')).toBeInTheDocument();
});
});
RTL クエリの優先度(この順序で使用)
getByRole- アクセシブルロール(button、textbox、heading、checkbox など)と照合getByLabelText- ラベルにリンクされたフォームフィールドgetByPlaceholderText- 入力プレースホルダgetByText- 表示されているテキストコンテンツgetByDisplayValue- input/select/textarea の現在の値getByAltText- 画像の alt テキストgetByTitle- title 属性getByTestId-data-testid属性(最後の手段)
getByTestId より getByRole を優先してください。アクセシビリティもテストします。
プロバイダーでのラップ
// コンテキスト付き Enzyme:
const wrapper = mount(
<ApolloProvider client={client}>
<ThemeProvider theme={theme}>
<MyComponent />
</ThemeProvider>
</ApolloProvider>
);
// RTL 同等物(プロジェクトの customRender を使用するかインラインで ラップ):
import { render } from '@testing-library/react';
render(
<MockedProvider mocks={mocks} addTypename={false}>
<ThemeProvider theme={theme}>
<MyComponent />
</ThemeProvider>
</MockedProvider>
);
// またはプロバイダーをラップするプロジェクトの customRender ヘルパーを使用します
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- github
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/github/awesome-copilot / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。