自分が担当するプロジェクトでは、参画した時点でテストコードが書かれており、新規コード追加時にテストコードを書く文化が浸透していました。前職ではそのような文化はなく苦労もあったので、自動テストがある程度書かれており、新規コードでは書いていく非常に良いことだと思い、その価値や良さを感じています。
一方で、新しく参画した人や新卒エンジニアに関してはテストコードを書くことが**当たり前になりすぎているんじゃないか？**と感じました。
テストを**「書かされていると感じている方」や、「いまいちテストコードを書く意味がわからないという方」**は本記事を読んで少しでもテストをポジティブに捉えてもらえると幸いです。
🤔なぜテストコードを書くのか
結論から言うと、プロダクトのコードの質を高めるための手段の1つと私は捉えています。
コードの質を高めるための手段は他にも様々ありますが、そのうちの有効なツールの一つがテストだと考えます。
テストコードを書くことで、プログラムの振る舞いを担保することができ、これが質の向上に繋がっていきます。
🍀テストコードの7つの恩恵
では、テストコードを書くことによって具体的にどんな効果があるのか考えてみました。
1. テストそのものの自動化による工数の削減
動作検証が自動化されることにより、リリース時のみでなく今後同じ箇所を検証する時間が削減されます。多くの箇所で使われたり、変更の多いプログラムであるほど、その効果は大きくなります。最も分かりやすい恩恵です。
ただし、手動のテストが全てなくなる訳ではありません。向き不向き、コストパフォーマンスの良し悪しもあるのであくまで手段の１つです。
2. 不具合の未然防止につながる
コードを生成する上でテストも同時に実装するため、開発の過程でも不具合率は減少する可能性はあります。実際新規コードに対してテストコードを書くようになってから、バックエンド側での不具合の発生率はかなり減少しました。
また、後々に対象のコードに影響のある箇所を修正してバグが発生してしまった際に、過去に書いたテストのおかげで早期発見に繋がります。これによって将来の不具合を防止するという効果も期待できます。（何度か書いててよかったーを経験しました）
3. プログラムの振る舞いがテストコードという形で明文化される
私は過去、手動でテストをした際にエクセルなどでテストケースを洗い出し、そのテスト表を元にテストしたりします。しかし、経験上なかなかこうしたドキュメントはその場限りになってしまい、再度使われることは少ないです。
※実装担当者のみしかテストパターンを把握しておらず、退職後誰も触れられない、なんてことも経験してきました。
しかし、テストコードとして書かれていれば、そのコードそのものがドキュメントのような役割も持ちますし、さらにそのテストを再現させることもコマンド一つで済むという利点があります。結果として、属人化の解消にもつながる側面を持っています。
4. リファクタリングのハードルが下がる
コードの質を高めるためにはテストだけでなく、そもそものコードを改善する必要があります。その際、テストコードがある程度の振る舞いを担保してくれていることで、難易度がかなり下がります。当然それでも怖い面はありますが、テストコードなしの1000行越えのスパゲッティコードを直接リファクタリングするよりも、遥かにハードルは下がると思います。
このように、テストコードを書いてあることで間接的ながら、コードの質を高めることに大きく貢献してくれると言えると思います。
5. バージョンアップや脆弱性対応への対応ハードルが下がる
かなりテストカバレッジ率が高く、成熟したプロジェクトの話になりますが、バージョンアップなどの影響範囲の大きい作業のハードルが下がります。仮にテストコードが書かれていなかったら、全体に大きく影響のある作業はリスクが高すぎてよっぽどの理由がないとやりたくないです。
GitHubのRailsのバージョンアップの話などは、社内でもかなり話題になりました。
6. コードの質に対する1つの指標になる
テストコードが書かれていると、テストのカバレッジ率（全体のコードのうち、どれだけの実行コードをテストコードが担保しているか）を数値化して出力できるので、定点観測ができるようになります。その結果、指標として検収条件や組織目標としてプログラムの質に対する定量的な指標を作ることができます。
7. モジュールを適切に分割するようになる（かもしれない）
副産物的なものですが、自分は新しい関数を作るときに、テストをどうやってやるかを考えています。その結果、テストしやすい単位でモジュールを分割するようになりました。
下記の記事が非常におもしくわかりやすかったので気になる方はこちらをどうぞ！
テストしやすい「純粋」な関数とは？ - Qiita
🚫 受け身な理由で書かれたテストコードは危険を孕んでいる
テストコードを書く上でのありがちな理由として、
- 検収条件にC0/C1(テストカバレッジ）が90%とあるから
- 会社のルールとして決まっているから
などがあると思います。
カバレッジをあげることに固執しすぎたり、仕方なく書かれたテストコードは、不具合の発見、コードの明文化、プログラムの質の向上といった本来享受したかったテストコードを書く意義そのものが抜け落ちてしまい、ただ通るだけのテストになってしまっている場合があります。（わたしもそうなっていたことがあります）
カバレッジ率を意識することや、テストコードを当たり前のように書く文化は決して悪くはありませんが、なんのためにテストコードを書いているのかを忘れてしまうと、価値の低いテストコードになってしまったり、最悪の場合テストコード自体が技術的負債にもなり得てしまいます。
🤔改めて、なぜテストコードを書くのか？
プロダクトのコードの質を高める１つの手段として、つまりは上記に述べたような効果も認識した上で、テストコードを活用するのが良いと思います。
組織やチーム内でこれについて議論してみるのも効果的かもしれません。テストコードを書く目的が明確になれば、テストコードをポジティブに捉えられると思います。
まとめ
自分も偉そうなことを言える立場ではありませんが、少なくとも今は**テストコードを書くことに対してポジティブに捉えられています。**これを読んだ方々が少しでもテストコードを書くことを前向きに捉えてもらえることを祈ります！
それでは、良いテストライフを！