AIが書いたテストが全て通っても信頼しにくいとき、コードをわざと壊してテストの強さを測るStryker(qiita.com)
書く言語: 韓国語書かれた言語で読む
わかりやすい要約
- テストが全て通っても、そのテストが実際に誤りを検出できるかは分からない。ミューテーションテストは、コードをわざと少しずつ壊してからテストが失敗するかを確認する。失敗すれば検出、通れば見逃しである。Strykerはこの過程を自動で行うツールだ。
- 著者のチームは、会社ごとにデータを自動で絞り込むPrismaクライアント(モデル131個)に適用した。モデルごとの条件を記した定義表は最初から100%で、手書きのクライアントテストは89.74%で補強した後に100%になった。
- 見逃した例の中には、他社の行を削除する試みが、会社ごとのフィルターではなく外部キー制約のために失敗していたテストがあった。レビューの指摘を受けてAIが追加したbind呼び出しは、削除しても動作が同じで不要なコードだと分かった。
- 著者の環境では、ミュータント407個に3分30秒かかり、規模が1,326個に拡大すると24分かかった。関係のないテストまで実行されないよう、実DBのテストだけを指定する必要があり、著者はPRの前に一度実行する方式を考えている。
編集部の意見
O: マルチテナントSaaSで会社ごとのフィルターを担当するバックエンド開発者は、PRの前に、絶対に間違えてはいけないファイルを一つだけ --mutate で指定してStrykerを実行してみることが提案されています。
X: 筆者の環境では、変異が407個で3分30秒、1,326個に増えると24分かかりました。関係のないテストまで実行される問題もあるため、実DBを使うテストだけを指定する必要があります。
書く言語: 韓国語
掲載元
Qiita ↗ / 掲載記事
似たような経験はありますか?そのときどうしたか、一言二言で教えてください。製品に詳しくなくても大丈夫です。