単体テストの考え方/使い方-第一章学んだことまとめ

読んだ本

Amazon.co.jp: 単体テストの考え方/使い方 eBook : Vladimir Khorikov, 須田智之: 本

第1章　なぜ、単体(unit)テストを行うのか

• 単体テストの現状について知ってもらうことが目標
• 単体テストをする目標とは？
• 良い単体テストが持つ主な特徴

開発者は単体テストに費やした時間と見合った結果を最大限に引き出せるように努力をしなくてはならない。
⇒テストにかける労力をできるだけ抑え、テストから最大限の価値を引き出さなくてはならない。

このバランスが取れているプロジェクトは

• 成長すること(つまりはプロジェクトが大きくなること？)に対してあまり労力を必要としない
• 保守に対する負担もそれほど大きくはない
• 顧客の要求に速やかに対応できる

1.1 単体テストの現状

作成した単体テストが機能しないとむしろ開発の足を引っ張る形になってしまう。
単体テストを作成するだけではなく、費やした労力に見合った結果を引き出せる単体テストを作成できるようになることが基本を学んだ次の段階になる

1.2 なぜ、単体テストを行うのか？

単体テストの目標は何か？
よく言われるのが「設計がより優れたものになる」というもの。
しかしこれは単なる副産物であり第一目標ではない。

• 単体テストが作成しずらい⇒テスト対象コードが何らかの改善を必要としている
• 単体テストを作成しやすい⇒プロジェクト・コードの質が良いという判断を下すことはできない

単体テストで何を成し遂げるか？
⇒ソフトウェア開発プロジェクトの成長を「 持続可能 」なものにすること

テストを用意しておくことで変更によって生じる退行を検出するセーフティネットがプロジェクトに備わることになる。

テストの質が悪いとテストを全くしない場合と同じ結果になる。
長い目で見ると単体テストの質が悪ければ、テストが全くない場合と実質的に変わらない。

¹テスト・スイートに含まれているケースの質が悪いとテストが間違った理由で失敗することが頻繁に起こり退行をきちんと検出できなかったり、てテストに時間がかかりすぎて簡単に保守できなくなってしまう。

テストケースが多いほど良いと思っている開発者が多く存在するが、その考えは間違いである。
なぜならコードは資産ではなく負債だからです。
コードが増えるということはバグが持ち込まれる可能性が上がる。
コードは最小限にするべきである。

1.3 網羅性とテスト・スイートの質との関係

網羅性(テスト。スイートに含まれているテストケースが実行するプロジェクトコードの割合のこと)
に依存してテスト・スイートの質を評価することは間違いである。
網羅性はテスト・スイートの質が悪いことを示せても、質が良いことを証明することはできないから。
※コード網羅性についてはまとめててつまらなかったので省略

1.4 何がテスト・スイートの質をよくするのか？

テスト・スイートの質をどのように評価すべきか？
結局のところテスト・スイートの評価に関して信頼できる方法は各テスト・ケースを1つずつ評価することしかない。
優れたテストケースには次の特徴がある。

• テストすることが開発サイクルの中に組み込まれている

• コートベースの特に重要な部分のみがテスト対象となっている

• 最小限の保守コストで最大限の価値を生み出すようになっている

テストすることが開発サイクルの中に組み込まれている

• 理想はコード変更を加えるたびにテストが実施されること

コートベースの特に重要な部分のみがテスト対象となっている

• 重要なことは単体テストにかける労力をシステムにとって非常に重要な部分に向けるということ
• ほとんどのアプリケーションでテストに時間を費やして価値のある所はビジネスロジックを含む部分(ドメイン・モデル)の部分になる
• ドメイン・モデルではないコードは以下
  • インフラに関するコード
  • 外部サービスや依存関係にあるもの
  • 構成要素同士を結び付けるコード

ドメインモデルを意識するためにもそれ以外の部分は隔離しておかなかればならない

最小限の保守コストで最大限の価値を生み出すようになっている

単体テストにおいて最も難しい部分は、最小限の保守コストで最大限の価値を生み出すこと。
このことを実現するためには次の2つのことを行えなくてはいけない。

• 価値のあるテスト・ケースを認識できること
• 価値のあるテスト・ケースを作成できること

1.5 本書から学べること

• テスト・スイートに含まれるテスト・ケースを分析する際の基準となる枠組みについて学び、その枠組をつかってどのようにテストケースを分析するのかを見ていく
• 多くのテストケースを新しい視点から評価できるようになる
• より価値をもたらすテストコードとなるようなリファクタリングを行えること

1. 目的や対象ごとにテスト・ケースを集めたもの ↩