単体テスト生成の高速化とコード品質の向上

最近、単体テストの自動生成用に設計された AI エージェントである Early について詳しく知る機会がありました。私は TypeScript と ExpressoTS Framework を定期的に使用する人間として、Early がどのようにワークフローを合理化できるかに興味を持っていました。私が開発していた @expressots/share.

第一印象

Early について最初に衝撃を受けたのは、既存のコードベースの単体テストを自動的に生成する機能でした。テストを最初から作成するのではなく、生成されたテストを改良し、コードの堅牢性とテスト容易性を向上させることに集中できました。この変化により、私の開発プロセスは大幅に加速されました。私が気づいたもう 1 つの興味深い側面は、生成されたコードの 83% が調整を何も行わずにそのまま動作し、コード カバレッジが増加したことです。時間を大幅に節約できます。

時間の節約とカバー範囲の拡大

わずか 8.5 時間で、次のことができました:

• 約 3,000 行のコードの単体テストを生成します。
• 問題を修正し、コードのテスト容易性を強化します。
• 96 回のテストで合計コード カバレッジ 88% を達成。

これらすべてを 1 日で達成できたという事実は驚くべきことでした。単体テストの理想的なシナリオは、実際に関数を開発している間に単体テストを実行することです。すでにライブラリを用意していたので、コードをテスト可能にするためにいくつかの調整が必要だったので、後で実行しました。

肯定的な結果

エッジケーステストの自動生成。たとえば、パラメータが必要な場合でも、空の文字列を含むシナリオの単体テストを生成しました:

export function printSuccess(message: string, component: string): void {
  stdout.write(chalk.green(`${message}:`, chalk.bold(chalk.white(`[${component}] ✔️\n`))));
}

当初、私はこのような単純な関数で空の文字列のテストを作成しなかったでしょう。しかし、Early のアプローチは防御的なプログラミングの実践を促進し、私が見落としていた可能性のあるエッジケースに対処するよう促しました。

潜在的な問題の検出

生成されたテストを改良しているときに、型の不一致の問題が発生しました:

問題: jest.fn() は any を返しますが、process.exit は何も返さないため、TypeScript で型の不一致が発生します。
解決策: process.exit シグネチャと一致するようにモックを変更し、型の正確性を確保します。
この発見をきっかけに、型安全性を向上させるためにコードを調整するようになり、Early が他の方法では気づかれないかもしれない微妙な問題を特定するのにどのように役立つかを強調しました。

改善すべき領域

全体的に良い経験ができたにもかかわらず、いくつかの課題に直面しました。これらの課題に対処すれば、Early の使いやすさが向上する可能性があります。

• ライブラリのバージョンの互換性。場合によっては、非推奨の Jest メソッドを使用して初期に生成されたテスト。例:

Jest 29.7 の使用

expect(Compiler.loadConfig()).rejects.toThrowError("process.exit() was called with code 1");

// 修正版

expect(Compiler.loadConfig()).rejects.toThrow("process.exit() was called with code 1");

• テスト生成のカスタマイズ オプション エッジケース用のテストを生成することは有益ですが、シナリオによっては必要ない場合もあります:

観察: 空の文字列を含む、考えられるすべての入力に対してテストを生成すると、過剰になる場合があります。

提案: テスト生成のレベルをカスタマイズするオプションを導入し、開発者が必要に応じて防御的なプログラミング テストをオプトインできるようにします。

• VSCODE 拡張機能のユーザー インターフェイスの機能強化 Early ツールと他のツールの間を移動すると、UI のいくつかの制限が明らかになりました:

テスト結果の可視性: どのテストが成功したか失敗したかを確認するには、Early と Jest を切り替える必要がありました。

ファイル ツリーの状態: 他のアプリケーションから切り替えると、Early のプロジェクト階層が崩壊し、フォルダーを繰り返し開く必要があります。
提案: Jest の構造を反映して、Early 内にテスト結果を表示するように UI を改善します。ファイル ツリーの状態を維持すると、ユーザー エクスペリエンスも向上します。

• モッキングとタイプセーフティ jest.fn() が any を返す問題は、より正確なモックの必要性を示唆しています:

観察: モックで型を使用すると、型の不一致が発生し、マスクのバグが発生する可能性があります。
提案: モック生成を改良して正確な署名を使用し、型安全性を高め、手動修正の必要性を減らします。

結論

全体的に見て、Early での私の経験は非常に肯定的でした。このツールのおかげで単体テストのプロセスが大幅に加速され、テストを最初から作成するのではなく、テストを改良することに集中できるようになりました。また、エッジケースを考慮してコードの堅牢性を向上させることも奨励されました。

改善の余地がある領域は比較的小さく、使いやすさとカスタマイズ性の向上を中心に展開されています。これらに対処すれば、このツールはソフトウェア開発においてさらに強力な味方となるでしょう。

Early チームの素晴らしい仕事に敬意を表します。このツールがどのように進化するか楽しみです。ツールをさらに改良するためにフィードバックを提供し続けたいと思っています。