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

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

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

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

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

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

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

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

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

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

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

• Jestの非同期テストパターンをわかりやすく解説

• Jestを愛する理由：開発者エクスペリエンス

• Jestを愛する理由：テストフレームワーク

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