こんにちは、ナイトレイインターン生の保科です。
Wantedlyをご覧の方に、ナイトレイのエンジニアがどのようなことをしているか知っていただきたく、Qiitaに公開している記事をストーリーに載せています。

今回はエンジニアの船津さんの記事です。
少しでも私たちに興味を持ってくれた方は下に表示される募集記事もご覧ください↓↓

今回は、新人エンジニアが「単体テストの考え方/使い方」の第一章を読んだので、備忘録としてまとめてみました。今後、読書録シリーズの続編も出す予定です（予定です）。

では、早速本題へ→

chap.1 なぜ単体テストを行うのか？

単体テストを書くうえで、テストにかける労力をできる限り抑え、テストから得られる効果を最大限に引き出すことが重要。

• 労力と効果のバランスを取るためには、良いテストと悪いテストを見分けることが必要
• • 費用対効果を分析する
  • 状況に応じた単体テストのテクニックを使う
  • アンチパターンを避ける方法を知る

単体テストの現状

単体テストの実施は当たり前。捨て去られること前提のプロジェクトでない限り、必ず書かれる。
現在の課題は、「単体テストを書くべきか」ではなく「良い単体テストを書くとはどういう意味か？」

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

単体テストは、ソフトウェア開発を、持続可能なものにするために行う。

• テストを書かずにプロダクト開発を続けると、コードが劣化しすることによって「ソフトウェアエントロピー（無秩序）」が増加し、コードへの信頼がなくなり、いずれ開発が止まってしまう。しかし、単体テストがあれば、一部のコードの変更による「退行（regression）」を検出することができるため、安定した品質を担保することができる。

• 単体テストの唯一のデメリットは、テストを書く「労力」である。しかし、開発初期からテストを書くことで、「持続のしやすさ」と「成長のしやすさ」を備えることができ、長い目で見て「適切な開発スピード」を維持できるようになる。

*退行： 特定の変更をした後、意図したように動かなくなること。バグ。

何がテストの質を良くし、何がテストの質を悪くするのか？

単体テストはただ書けば良いのではなく、「質の良い」テストを書かなければいけない。たとえば、テストに時間がかかりすぎたり、退行を検出できなかったり、保守コストがかかりすぎた理、間違った理由でテストが失敗することが増えすたりれば、テストの存在によって、プロダクト開発の進行が脅かされる。

また、テストコードの保守コストは、以下のような作業の積み重ねで増加する。

• プロダクションコードのリファクタに伴い、テストコードをリファクタすること
• プロダクションコードを変更するたびに、テストを実施すること
• テストが間違って失敗したとこに、その対処をすること
• プロダクションコードがどのように振る舞うかを理解するために、テストコードを読むこと

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

網羅率：テストケースが実行するプロダクションコードの割合

一般に、網羅率は高いほど良いとされるが、「高ければ良い」わけではない。

• たとえば、網羅率10％であれば、テストが十分でないことがわかるが、網羅率100％だからと言って、テストの品質が良いとは限らない。

コード網羅率と分岐網羅率について

コード網羅率 ： プロダクションコードの総行数に対する、テスト時の実行行数。実行されたコードの行数÷総行数

分岐網羅率 ：プロダクションコードの分岐路に対する、テスト実行時に経由される分岐の数。経由された経路の数÷分岐経路の数

網羅率の問題

1. 網羅率からは、実際にテスト対象のコードが検証されたのかを保証できない

• • 網羅率は、プロダクションコードが「実行された割合」を示すため、その結果が検証されたことを保証していない。
  • 確認不在のテスト：プロダクションコードを実行しているにも関わらず、結果を検証していないテストコード
    

    import pytest
    
    def example(num):
            if num < 5:
                    return "short"
            else:
                    return "long"
    
    def test_example(num):
            actual == example(num) # プロダクトコードを実行

2. 網羅率を算出する際、使用するライブラリなどのコードは計測の対象から外れる

網羅率まとめ

網羅率は、「テストが十分に行われていないこと」を検証するための数値であり、「良いテストであること」を保証するものではない。加えて、高い網羅率を義務付けるような使い方をすると、かえって開発の妨げとなる可能性が高い。

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

テストケースの良し悪しを、定量的に自動で判断する方法は存在せず、結局のところ、１つずつ個人が判断するしかないが、優れたテストスイートの特徴を挙げることは可能である。

1. テストすることが開発サイクルに組み込まれている
   → コードが変更されるたびに、テストを実行する必要がある
2. コードベースの、特に重要な部分のみがテスト対象になっている
   → プロダクションコードのうちの重要な箇所（ドメイン・モデル、ビジネスロジック）のみに、テストの労力をかけることが重要
3. 最小限のコストで、最大限の価値を生み出すようになっている
   → 上記には、以下が必要
   * 価値のあるテストケースを認識できること
   * 価値のあるテストケースを作成できること

感想

個人的に、「テストすることが開発サイクルに組み込まれている」ことが重要だなと感じています。

元々、私が参画しているプロジェクトでは、ユニットテストを書いていませんでしたが、テストを書く習慣がついてからは、予期せぬバグが減ったのはもちろん、自分自身のコードへの理解力が上がったり、プロダクションコードを綺麗に書こうという気持ちが強くなったりしました。
この本の概要を理解できたら、使っているテストフームワークの勉強を体系的にしてみたいなと思ってます。

*今回の本はこちら↓