ユニットテストのリファクタリング耐性について

単体テストの本を読んでいてあまり頭の中にまとまってないなと思い、記事化することで整理していこうと思う。

リファクタリングへの耐性について

リファクタリングへの耐性とは、リファクタリングを行ったときにテストが壊れずにリファクタリングが行えるかということである。

耐性が高ければリファクタリングをしてもテストが壊れずに実行でき、耐性が低ければテストが壊れてしまう。

テストが壊れてしまうというのはどういうことか？
ここではふるまいは合っているのに、テストが失敗してしまう状態をテストが壊れたと定義します。

ふるまいは合っているが、テストが失敗してしまう。
なぜこんなことが起きてしまうのか？

偽陽性が起きる原因

ふるまいは合っているが、失敗してしまうテスト偽陽性と呼びます。
偽陽性はもともと医療用語ですが、考え方は同じです。
参考: https://www.jslm.org/committees/infection/20200427.pdf

感染していないが、検査陽性になることを指します。

話をテストに戻しますと、テストで偽陽性が起こってしまう原因はテストケースが内部処理と密接に結びついているからです。

例えばデータを更新する処理で、データが更新されることを確認すればいいのですが、更新するときのコードの書き方をチェックしてしまうことで、書き方を変えただけで、結果は合っているのにテストは失敗してしまうという状況になってしまいます。

偽陽性を防ぐには

テストで内部処理をチェックするのではなく、最終的な結果のみを検証することで、壊れにくいテストを書くことができます。
フロントエンドテストであれば、生成されるDOMの検証やClassの検証、バックエンドであれば、データベースの値の検証等になります。