どうもSuです。ソフトウェア開発ではテストについてもっと力を入れるべきだなと感じています。
ここ数年でテストコードは当たり前のように書く時代になったなと感じます。
一度リリースして終わりというプロジェクトは自分の周りにはほぼなく、基本的にリリースを短いサイクルで繰り返していきます。
その中で手動テストをやっていては、いくら時間があっても足りません。また、テストコードがないことによるリファクタリングのしづらさも継続して開発していくためには良くないと思います。
テストコードがあると、リファクタリングを積極的に行っていても、「テストコードが壊れていないから、大丈夫だな」と安心感を得られるようになり、より理解しやすい、保守しやすいコードを保っていけるのではないかなと思います。
もちろん、テストの網羅性や、本当に充分なテストができているかという別な問題が残っている可能性がありますが、テストコードがあれば、テストコード自体のリファクタリングも可能です。
また、テストコードを書くことによって、「あれ、このパターンは考慮していたっけ？」、「あ、エラーの場合、十分なログが出ていないな、もう少しログの構成を変更してみよう」といった、実装の問題点や改善点を見つけることができたりします。
特にエラーケースは意外と開発中は見落としがちなのではないかなと思います。正常系だけしっかりテストしていたけど、いざ運用でエラーが発生したときのログを見てみると、「あれ、このログじゃ、どんなエラーがどこで発生したか分からないなー」なんてこともあります。
テストは要求されている機能を満たすという観点としてももちろん必要不可欠ですが、保守の面でも問題点を洗い出してくれる良い機会だと自分は捉えています。
さて、話が長くなりましたが、そんな中で、「テストについて他の開発しているチームや会社はどうやっているのだろうか？」、「単体テストは？」、「結合テストは？」、「テスト自動化ってどうやってるのだろうか？」というたくさんの疑問がわいてきました。そこで出会ったのがこの本です。
|
有名な著書なので皆さんも読まれたことがあるかもしれません。
とても分厚い本で、とても高価な本ですね（約5000円します）
ただ、
「たった5000円でGoogleの開発について学べる機会がもらえるなんて、超おトクじゃね！？」
と自分は言えると思います。
もちろん、「Googleの開発なんてウチでは参考にならないよ！」、「結局Googleは開発メインの会社だし、文化も違うから学んだところで使えない」という意見はあると思いますが、「今の環境」という限定的な見方で機会を逃すのはもったいないかなと思いますし、考え方を知っておくと、自分の考え方の幅を広げるいい機会かなと思います。
で、読んでみた感想は、「なるほど！そういう考え方でテストを捉えているのかー」と非常に参考になりました。
例えば
テストされているコードは、リポジトリー提出時に欠陥が少ない。決定的に重要なのは、テストされているコードはその存続期間を通じて欠陥が減少することである。
Googleのソフトウェアエンジニアリング 「11.1.4 コードをテストする利点」「デバッグの減少」
という部分では、テストコードを書く利点について説明されています。
テストコードがあるということは、リリース前、開発中など早い段階で問題が見つけられるということです。その問題を修正することで、開発以降（例えば結合テスト、受入テスト、リリース後など）に発生するデバッグの時間を減少させることができるということですね。
リリース後にバグが発生した場合は、原因調査のデバッグだけではなく、修正、レビュー、リリース準備などをやらないといけないですし、何よりもシステムの利用するユーザに迷惑が掛かります。ユーザが多ければ多いほど、バグが存在している時間が長ければ長いほど、影響は大きくなりますし、もちろんシステムの信頼も崩れます。つまり、実作業以上の損失が発生してしまいますね。
「コード書くの楽しい！」、「でも、テストは面倒だなぁ」と考えてしまうのは、確かにあるかもしれませんが、システム開発はビジネスの中の重要な要素です。このような全体の影響を考えるとテストはとても重要だなと意識せざるを得ないかなと思います。
他にもたくさん良い視点を得られる本でしたので、また、別な記事で書きたいと思います。