「単体テストの考え方/使い方」のアウトプット ~Part1~
本記事について
Vladimir Khorikov著作の「単体テストの考え方/使い方」を読むにあたり、内容を咀嚼しながらアウトプットすることを目的とする。
引用
はじめに
この本はソフトウェア開発をする上でテストが存在することの価値や運用のしやすさに目が向けられており、単体テストによるバグの見つけ方やデータの作り方等について書かれたものではない。
一般的な入門書：テストでバグを見つけることにフォーカス
この本：ソフトウェア開発をする上でのテストが存在することの価値や運用のしやすさにフォーカス
→ 単体テストに関するベストプラクティスとよく目にするアンチパターンについて詳しく掘り下げていく。
単体テストに関する書籍やオンライン上の情報には欠点がある
→ 単体テストの基礎を知ることだけに目を向け、その後のことにはほとんど目を向けていない。
単に単体テストを作成するのではなく、その労力が最大限価値あるテストを作成することを目指すべきであり、この本では最大限の価値をもたらせるようになるまでのステップを説明する。
第1部 単体テストとは
第一章 なぜ、単体テストを行うのか？
単体テストについて技術的なことを学べば終わりではない。
→ 開発者はテストにかける労力をできるだけ抑えて、テストから最大限の価値を引き出さなくてはならない。
労力をできるだけ抑えてテストから最大限の価値を引き出すことができないと、プロジェクトが失敗していく。
→ 費やした労力や単体テストの量に関係なく、膨大なバグと保守コストを抱えてしまうことになるため。
この章では、良い単体テストと悪い単体テストについて学び、単体テストに対する費用対効果の分析方法と状況に応じた適切な単体テストのテクニックを学ぶ。
1.1 単体テストの現状
単体テストの重要性は理解され、必ず実施されるものとして認識されるようになった。
→ 単体テストに関する議論は「単体テストを書くべきか？」から「良い単体テストを書くとはどういう意味なのか？」に移ってきている。
しかし、この議論の移りが単体テストに関して混乱を招いている。
混乱による影響
自動化されたテストケースを用意していも、必ずしも望ましい結果が得られるわけではない。
新機能の実装が終わらないにも関わらず、実装済みの機能に新たなバグが発生することも珍しくはない。
→ プロジェクトの助けとなるはずの単体テストが機能しておらず、事態が悪化してしまう。
良いテストと悪いテストの違いは個人の好みの違いではなく、参加しているプロジェクトが成功するか失敗するかの鍵となるもの。
→ テストの質によってプロジェクトが成功するか失敗するかが決まる。
「良いテストが何か」という議論がされることはあまりない。
多くの書籍は、読者が単体テストの基礎を学ぶところまでしか扱っておらず、費やした労力に見合った結果を引き出せる単体テストを作れるようになる段階まで教えていない。
1.2 なぜ、単体テストを行うのか？
「単体テストのプラクティスを実施すれば、設計は優れたものになる」というのは間違いではないが、副産物に過ぎない。
単体テストをすることで成し遂げたいのは「ソフトウェア開発のプロジェクトの成長を持続可能なものにする」こと。
テストを行うプロジェクトと行わないプロジェクトとの違い。
テストを行わない方は、最初はすぐに成長していくが時間が経つにつれて成長が望めなくなる。
上の図はソフトウェア・エントロピーの増加によるもの。
コードベースに対して何らかの変更を加えることは、そのコードベースにエントロピーをを増やすことを意味している。
もし、適切なコード整理やリファクタリングをしていなければ、ソフトウェアはすぐに複雑になり、一つのバグを修正するのに多くのバグが発生してしまうといった安定な状態が失われることになる。
テストがあることで、コードの変更によって生じる多くの退行を検出するセーフティ・ネットがプロジェクトに備わることになる。
しかし、テストを用意するのは最初はそれなりの労力が必要になる。
1.2.1 何がテストの質を良くし、何がテストの質を悪くするのか？
単にテストを作成すれば良いという訳ではない。
→ 作成されたテストの質が悪ければ、テストが無いのと一緒。
全てのテストケースは平等に作られているわけでは無い
ソフトウェア全体の質を向上する価値のあるテストケースもあれば、そうでは無いのもある。
→ 質が悪ければ退行を検知できなかったり、テストに時間がかかりすぎて簡単に保守できなくなる。
→ 「単体テストを行なった」という事実を作るために書いているとこのようなことが起こる。
テストケースを増やしただけでは十分ではなく、作成する単体テストの価値とその維持にかかるコストを考慮しなければいけない。
ここでいうコストとは、
- プロダクションコードのリファクタリングに伴ってテストもリファクタリングするコスト
- プロダクションコードを変更するたびにテストを実施するコスト
- テストが間違って失敗した際にその対処をするコスト
- プロダクションコードの振る舞いを理解するために、テストコードを読むコスト
続き
Discussion