EnzymeはReact 18をサポートしていないため、既存の単体テストは使用できず、それらが提供する基礎的な信頼性を危険にさらしていた、とSergii Gorbachov氏はQCon San Franciscoで述べた。彼は、テストカバレッジの継続性を確保するために、SlackがすべてのEnzymeテストをReact Testing Library（RTL）に移行した方法を示した。
React Testing Libraryは業界で認められている選択肢であり、React 18で公式にサポートされている他の選択肢はなかった。そのため、ベストプラクティスに沿った、わかりやすい決断ができたとGorbachov氏は言う。
Enzymeのアプローチは、ステート、プロップス、実装の詳細など、内部コンポーネントの詳細をテストすることに重点を置いていた。React Testing Libraryに移行することで、実際の環境でユーザーがコンポーネントとどのようにやりとりし、どのように動作するかをシミュレートすることに重点を置いた、異なる方法論が導入されたとGorbachov氏は言う。
彼らはまず、大規模言語モデル（LLM）をスタンドアローンのツールとして使用し、完全に変換された機能テストを生成するためにLLMに依存した。このアプローチは部分的な成功を収めたが、テストの複雑さによってその有効性は変わるとGorbachov氏は述べた。
次に、LLMをより大きなパイプラインに統合し、抽象構文木（AST）変換と組み合わせ、検証、リンティング、最初の試みを修正するための反復フィードバックのステップを組み込んだ、とGorbachov氏は説明した。
このハイブリッドアプローチは、両方の手法の長所を併せ持ち、80％の変換成功率を達成するのに役立ち、テストの品質を維持しながら効率を大幅に改善しました。
生成されたコードの品質を評価するために、彼らは、codemodの機能性（信頼性とエラー処理）、インポートの変換（EnzymeのインポートをRTLの同等のものに置き換える）、レンダリング（EnzymeのレンダリングをRTLのものに変換）、Enzymeのメソッド（Enzymeのメソッドを置き換えるか、注釈を追加）、アサーション（RTL互換のものに更新）、JS/TSロジック（テストの機能を維持）を評価する詳細な品質評価基準を作成した。
各難易度（簡単、中程度、複雑）から3つのEnzymeテストファイルを選択し、進捗を測定するために手動で評価しました。難易度は、テストケースの数、インポート、Enzymeメソッド、アサーションなどの特徴に基づいて決定され、テストケースの比重が高く、複雑さの評価を平均化することで、ファイルをいずれかの難易度に分類しました。
彼らはファイルを自動的に変換し、人間が変換したファイルをベンチマークとして、品質評価基準を使って結果を評価した。彼らのツールは平均して80％の精度を達成したが、より複雑なケースでは手作業による調整が必要だったとGorbachov氏は述べた。
決定論的手法とAIを組み合わせることで、リアルタイムフィードバックの欠如や事前・事後処理への依存といった限界を克服できた、とGorbachov氏は言う。ASTベースの変換、注釈、入念に作成されたプロンプトを統合することで、人間のワークフローに倣ってコンテキストをモデル化し、LLMのそのままの機能よりも変換成功率を20～30％向上させた、と彼は付け加えた。
LLMは高複雑度の非構造化タスクを処理するのに優れているが、決定論的なタスクにはLLMを使わない方が良い、とGorbachov氏は説明した。
生成されたコードの実行と検証を含む我々のアプローチは、単体テスト生成、コード近代化、可読性改善などのプロジェクトに転用可能で、完全なエンドツーエンドのフローを可能にします。
このアプローチを再利用し、他のタイプのプロジェクトでも同様のパイプラインを構築するために、Gorbachov氏は、Enzyme to RTL codemod、完全な実装のための convert-test-filesワークフロー、およびSlackでのEnzymeからReactテスティング・ライブラリへのAIによる変換に関するブログ投稿を参照した。
InfoQは、React Testing Libraryへの移行についてSergii Gorbachov氏にインタビューした。
InfoQ: 自動テストをどのように適応させたか？
Sergii Gorbachov: For example, consider this code:
<div> <button onClick={toggle}>Toggle</button> <p>{isOn ? "Switch is ON" : "Switch is OFF"}</p> </div>With Enzyme, we might test this behavior like this:
wrapper.setState({ isOn: false }); expect(wrapper.find('p').text()).toBe('Switch is ON');This directly manipulates the component’s internal state to assert the result. In RTL, we simulate user interaction instead:
userEvent.click(screen.getByText('Toggle')); expect(screen.getByText("Switch is ON")).toBeInTheDocument();This approach focuses on verifying the outcome of a user’s action and makes sure the component behaves as expected from their perspective, rather than its internal workings.
InfoQ: 抽象構文木codemodと大規模言語モデルを使うことで、どのような利点が得られたか？
Gorbachov: Using Abstract Syntax Tree (AST) codemod and Large Language Models (LLM) significantly enhanced the test conversion process. The AST codemod our team created handled straightforward code conversions, as well as added annotations for complex scenarios where rules were too ambiguous to define programmatically.
For instance:
Will be transformed into:expect(component.find('div')).toHaveLength(2);// Conversion suggestion: .find('div') --> Use component rendered DOM to get the appropriate selector and method: screen.getByRole('selector') or screen.getByTestId('<data-id=...>') expect(component.find('div')).toHaveLength(2);This annotation was created specifically for the LLM and provided detailed and relevant guidance to help the model generate accurate conversion for this specific instance. Most such instances were annotated in the original files, which were used as the source code to convert. By including partially converted pseudocode with annotations along with tailored instructions in the LLM prompts, we reduced the ambiguity and minimized hallucinations often seen in AI approaches that rely solely on prompts.