Jestのテストケースをリファクタリングする6つのステップ

著者

2019年9月4日

0 分で読めます

Jestのあまり知られていない機能の1つに、テスト失敗時にコンソールへ表示されるアサーションエラーの処理方法をカスタマイズできる機能があります。キーが想定どおりに存在することを確認するため、オブジェクトをプログラムでループ処理する必要がある次のテストコードを見てみましょう（expect関数を使用します）。

JavaScriptファイルに対応するアプリケーションクラスがあるかを確認するJestテストを表示した、暗色のコードエディター。

テストの書き方に問題はありません。では、チームの開発者がコードを変更した場合を考えてみましょう。ある箇所に新しいファイルを追加したものの、同じプロジェクト内の別の重要な箇所（正しくエクスポートされていることの確認など）に追加し忘れてしまいました。

次にテストを実行すると、失敗します。しかし、ほとんどの人には原因がすぐにわからないでしょう。コードに不慣れなら、何が壊れたのかさえわからないかもしれません。試してみてください。

Jestのテスト失敗を表示するダークテーマのコードエディター。「validatorsをエクスポートする必要がある」というテストで、Received: undefinedと13行目のアサーションエラーが示されています。

そこでJestでは、expectとともにtoHaveProperty()を使うことも求められます。次のようになります。

ファイル名ごとにクラス名を生成し、期待されるプロパティをテストするJavaScriptを表示した、ダークテーマのコードエディター。

これでテストが失敗したとき、少なくともどのプロパティが欠けているかはわかりやすくなります。それでも次のスクリーンショットのように、まだ少しわかりにくいですね。どうすればよいでしょうか？

すべてのバリデータークラスをindex.jsからエクスポートする必要があると示すJestのテスト失敗が表示された、ダークテーマのコードエディター。

この時点では、すでに付いている注釈だけでも十分かもしれません。ご覧のとおり、テスト名から内容は明らかです。ただ、失敗するテストケースは1つしかなく、テストのトレースを見ても、どのバリデーターが使われたのかを明確に判断できません。

コードをリファクタリングしましょう。

index.jsからバリデータークラスがエクスポートされていることを検証するJestテストを表示した、ダークテーマのコードエディター

これで、テストが成功しても失敗しても、何をテストしたのか、何が失敗したのか、そしてその理由が、ずっと明確で直感的にわかるようになりました。

app.test.js内のバリデーターのJestテストが成功したことを示すターミナル出力。ValidateHost.jsとValidateHttps.jsを含む。

ずっとよくなりました！ ???

私と同じくらいJestが好きなら（？）、こちらの記事もぜひご覧ください。

Webセキュリティにも関心があれば、The Secure DeveloperのSlackコミュニティ、またはお好みであればTwitterでぜひお話ししましょう。