なぜテストコードを書くべきなのか
なぜテストコードを書くべきなのか。それはテストを書く事によって得られるメリットがたくさんあるからです。
テストコードを書くとたくさん良いことがあるのでまとめてみました。
この記事が少しでも参考になれば幸いです。
メリット
- 機能やストーリーの受け入れ基準が明確になる。 どうしたら完了と呼べるのか迷う必要がなくなる。
- 自然と疎結合なコンポーネントを書くようになる。 コンポーネントが疎結合になると組み合わせや改良が容易になる。
- 何をするためのコードなのかをテストコードが説明してくれる。
- 網羅的なリグレッションテスト（回帰テスト）を行える。 デグレする不安の日々から開放されます。言語やライブラリのバージョン変更時は特にありがたみを感じる。
- 安心してリファクタリングができる。 テストコードを書いていないと、バグってしまうのを気にしてリファクタリングを躊躇してしまいますよね。
- 仕様がまだ頭の中に残っているうちにエラーの検出や考慮ができる。 日が経つほどにエラーパターンなどを忘れていってしまいます。
- 必要以上のメソッドなどを作らなくなる。
- 実装フローの一貫性を確立できる。 （エラーになるテストを書く） → （OKになるように実装） → （リファクタリング）。このフローをテンポよく実施できる。
- 人間と違ってテストの確認漏れがない。
- 人間と違って早い。 他に人にテストしてもらうとなったら、放置されたりで2日後にNG報告とかよくある。
- DevOpsのライフサイクルにセキュリティを組み込み安全なデプロイを可能にする。 ストーリーの完了基準と同様にデプロイするための基準にもなってくれる。
テストコードは完璧ではない
「テストコードを書くだけで本番でバグが出なくなるのか？」という疑問があるでしょう。正直に言うと本番でバグが出ることはあります。
本番環境で動かしてみまないとわからない問題というのは割とあります。諦めましょう。
一応そのためのバグフィルターという考えがあるがそれはまた今度。
でもテストコードを書くことで、バグを減らすことは可能です。今後同じバグを出さないようにすることもできます。
テストコードは難しくない
実装とは別に余分にコードを書かなくちゃいけない、何を書くのかよくわからない。などの思いからテストコードを書くことが大変に思えるでしょう。
確かにコード量は増えます。でもそれによって手動で何度もテストする必要がなくなります。早い段階でバグを発見できるので修正が楽です。
なのでトータルで見ると生産性は上がります。そして、必要な機能をチームが理解しそれを予定通り確実に実装する助けになります。
それに（エラーになるテストを書く） → （OKになるように実装） → （リファクタリング）のリズムをつかんでしまえば、テストコードを書くのは辛くありません。むしろテストを通すという小さな目標ができるのでモチベーションが上がります。
テストを最後にまとめてやってはいけない
本番に近い環境ですべてを結合したテストのほうが忠実性は高いです。なので実装をすべて終わらせてから、そういった環境でまとめてテストをしたくなります。
そのほうが無駄なテストをしなくて良いように感じるでしょう。
でも実際はバグがどこで起こったのか追跡するのが大変です。DBの値が間違っているのか、サービスの実装が間違っているのか、共通ライブラリが間違っているのか。
一つ一つ確認していくのは地味に時間がかかります。
それに画面からDBまでを結合した状態のテストコードを書くのはちょっとした変更ですぐ壊れるので保守がしづらいです。作れば作るほどコストが指数関数的に増えます。
そしてほとんど真実を語らないテストが出来上がり「狼と羊飼い」のように誰もテストを信じなくなります。最終的にテストコードは役に立たないという悲しい結論になるでしょう。
開発工程の後ろに行けば行くほど、バグの修正による影響範囲も大きくなります。そのため慎重な調査が必要になり修正コストも高くなります。
以上の理由により、最後にまとめて大量にテストをするのはオススメしません。最後のテストはなるべく重要な目的に絞った少ないテストを行うべきです。
そして開発工程の早い段階であればあるほど、修正にかかるコストは低くなります。
仕様理解を促す
新しいソフトウェアや機能を作る問ことは、新しい業務や仕様、技術などについて知らなければいけないということです。単純なシステムでもない限り避けては通れません。
魅力的で画期的なソフトウェアであればあるほど、思いもよらないことであふれるはずです。
保守を頼まれたけど「担当したことない機能だから仕様がわからない」ということもよくあります。ソフトウェアが大きくなればなるほど一人ですべての機能を把握することは不可能になってきます。
ではどうやってそれらの仕様を学ぶのでしょうか？
最も良い方法は、頻繁にフィードバックを得ることです。既存のテストコードを読み、大まかな仕様を把握し、そして新しい仕様をテストコードに書きます。
テストでエラーが出れば実際の仕様と自分の認識の違いに気づくことができます。そうやって既存仕様を学ぶことができます。
またテストコードによってリリース頻度が上がれば、それだけ顧客やエンドユーザーからのフィードバックの機会も増えます。本当に必要な仕様が早い段階で判明して、よりよい機能を作ることができます。
さいごに
今後はテストのやり方などについて記事を書いていければと思います。
レッツテストライフ！
Discussion