この文書はTotT: Refactoring Tests in the Redの翻訳です。
いいテストのセットが適切にあれば、コードのリファクタリングは簡単になる。リファクタリング後にテストを走らせ、コードがパスすることを確認することで、素早く多くの確信を得ることができる。
一連のテストが大きくなるにつれ、重複が現れ始めるのは普通だ。コードと同様に、テストも分かりやすくメンテナンスしやすい状態を維持するのが理想的である。そこで、テストもリファクタリングしたくなるだろう。
しかしながら、テストのリファクタリングは難しい。だって、テストのテストは用意していないだろう？
どのようにしてテストのリファクタリングが安全であり、間違ってアサーションの一つを消してしまっていないかを知るのだろうか？
意図的にテスト対象のコードを壊せば、テストが失敗し、アサーションが依然として働いていることが分かる。例えば、CombineHarvesterTestのメソッドをリファクタリングしているとして、CombineHarvesterに手を入れ、返り値が間違ったものにすればよい。
テストが失敗する理由が期待通りアサーションが失敗しているからかどうかを確認しよう。そうであれば（注意深く）失敗しているテストをリファクタリングできる。もし、あるときテストがパスし始めたら、テストが壊れているということがすぐに分かる。やり直そう！リファクタリングが終わったら、テスト対象のコードをもとに戻し、再びテストがパスするかどうかを確認しよう。
(revertが助けになる。テストはrevertしないように！）1
大事な点を再確認しよう：
リファクタリングが終わったら… テスト対象のコードをもとに戻すのを忘れないこと！
まとめ
-
プロダクトコードをテストを通しながらリファクタリングする。そうすることで、プロダクトコードが意図通りに動作しているかどうかを判別できる。
-
テストコードをテストを失敗させながらリファクタリングする。そうすることで、テストコードが意図通りに動作しているかどうかを判別できる。