テストが2件落ちたとき、すぐコードを直さなかった話

今日は、Next.jsとTypeScriptで作っている業務アプリの認証まわりを直したあと、テスト結果の読み方で判断に迷った話です。

変更後にテスト一式を実行すると、799件のうち797件が通り、2件だけ失敗しました。数字だけを見ると「自分の修正で壊した」と考えてすぐ直したくなります。けれど、落ちたのは認証処理そのものではなく、改行コードを含む文字列の比較でした。

ここでテストを通すためだけに期待値を変えたり、すべての文字列を機械的に正規化したりすると、本来検出したい差分まで消してしまいます。そこで同じ2件を変更前の状態でも実行し、WindowsのCRLFとLinuxのLFの違いによって以前から再現することを確認しました。

そのうえで、今回触った認証関連のテストだけを分けて確認すると63件すべて通過。さらに型チェック、ビルド、変更差分を確認し、「今回の変更による不具合」と「既存の環境差」を切り分けました。最終的には失敗を隠す修正は入れず、検証結果を記録して認証部分だけを進めました。

AIを使うと修正案はすぐ出ますが、テストが赤い理由までAIが自動で正しく判断してくれるわけではありません。大事なのは、通すことよりも、どの変更がどの結果に影響したかを説明できる状態にすることだと改めて感じました。

次は、改行の違いが意味を持たないデータだけ入力時に正規化し、WindowsとLinuxの両方で同じ結果になるテストを追加します。同時に、認証はブラウザ操作まで含めた確認を別に残します。

同じようなNext.js／TypeScriptの不具合調査や既存コードの改修は、ココナラの「Web・業務システム開発」からご相談いただけます。