概要
このページは筆者が過去に読んだ技術書をもう一度読み返し、情報を整理するために記載しているページです。
書籍についてだったらり、何か技術的な手助けになれたら幸いです。
対象書籍
まとめ
TODO:記載予定
1章なぜ、単体テストを行うのか？
この章では、テストコードの必要性とただテストコードを作成するだけで良くないことが記載されていました。具体的には、テストコードがない、悪いテストコードは変更に弱く開発コストがかかってしまい、いいテストコードでは変更に対するバグを防ぐことを可能なる。
またいいテストコードは、テストコードの有無・コード網羅率・分岐網羅率からは判断することはできず、反対に悪いテストコードかどうか判断する材料にはなることが記載されていました。
後続の章で、いいテストコードとは解説がされていく。
1.1 単体テストの現状
- いい単体テストがあれば、機能追加や新規開発がしやすく品質を高いものが作りやすい
- 逆に悪い単体テストの場合、機能追加に時間がかかりバグの発生リスクが高まる
1.2 なぜ単体テストを行うのか？
- 単体テストを作成することで、プロダクトのコード設計が良くなると言われている
しかし、悪い設計を検知することはできるが、いい設計かどうかは判断することはできない（例：結合度が高いクラスをテストしようとするのは大変だが、疎結合だからといっていい設計とは限らない） - 単体テストを作成することで、開発に費やすコストを下げることができる。しかし悪いテストケースではその足枷にしかならない
- 開発速度が急に落ちる現象を、ソフトウェア・エンドロビーという
- テストにかける時間をかけすぎてもよくなく、必要で効果的なテストケースを用意しないと、テストがあっても開発時間はかかってしまう
※書籍「単体テストの考え方/使い方」から引用
1.3 網羅率(coverage)とテスト・スイートの質との関係
- テストコードの網羅率には、コード網羅率と分岐網羅率が存在する
- 網羅率が低いとテストが不十分と判断できるが、網羅率が高くてもテストケースの質が高いことを担保することはできない
※書籍「単体テストの考え方/使い方」から引用
- コード網羅率は簡単に高くすることができるがコードの質は保証できない
以下のコードの網羅率を確認すると、一枚目は5行に対して4行のテストコードが実行されるので80%の網羅率になるが、2枚目の画像では三項演算子を用いることでコードを1行に変更している。そのためコード網羅率は100%になるが、「true」になる条件のテストが行えていない。
-
分岐網羅率は、コード網羅率の欠点を克服するため条件分岐に目を向けている
上記コードでは、網羅率が50%となりある程度コードの網羅できていることがわかる -
上記2つの方法を用いても、実際にテスト対象のコードが検証されたのか、使用するライブラリ内のコードは計測の対象から外れてしまうため、テスト・スイートの質を評価することはできない。何を確認するのかが大切になってくる
-
網羅率の結果に縛られるのは良くないが、テストが十分に行われていないことを示すものとして見るぐらいがいい
1.4 何がテスト・スイートの質を良くするのか？
- 各テストケースを一つずつ確認していくしていくしかない。自動的に評価できる仕組みはない
- テスト・スイートの質を良くする方法は、3つあるみたい
- テストすることが開発サイクルの中に組み込まれている（テストが成功しないとマージできないなど）
- コードベースの特に重要な部分のみがテスト対象となっている。ビジネスロジックを含む部分、ドメイン・モデルにテストが集中している状態
- 最小限の保守コストで最大限の価値を生み出すようになっている
2章 単体テストとは何か？
TODO: 記載する