単体テストで何をテストする必要がありますか？

私は大学を卒業したばかりで、来週どこかで大学を始めています。単体テストを見てきましたが、あまり使用しませんでした。誰もがそれらについて話すので、私はいくつかのことをすべきだと思いました。

問題は、何をテストすべきかわからないことです。一般的なケースをテストする必要がありますか？エッジケース？機能が適切にカバーされていることを知るにはどうすればよいですか？

特定のケースで機能が機能することをテストで証明することはできますが、機能が機能することを証明することはまったく役に立たないという恐ろしい気持ちが常にあります。

これまでの私の個人的な哲学は次のとおりです。

1. 可能なすべての一般的なケースをテストします。これは、何らかの変更を加えた後にそのコードが壊れたときにわかります（これは、自動化された単体テストの最大のメリットです）。
2. おそらくエラーがあると思われるいくつかの非常に複雑なコードのエッジケースをテストします。
3. バグを見つけたら、修正する前にそれをカバーするテストケースを書く
4. 誰かが殺す時間があるときはいつでも、重要度の低いコードにエッジケーステストを追加します。

これまでの多数の回答の中で、当面の質問に対する回答の重要な考慮事項である等価分割と境界値分析に触れた人はいません。他の答えはすべて有用ですが、定性的ですが、ここで定量的であることが可能であり、望ましいです。@fishtoasterはいくつかの具体的なガイドラインを提供します。テストの定量化の裏で覗くだけですが、同値分割と境界値分析により、より良い結果が得られます。

で同値分割、あなたが期待される成果に基づいてグループにすべての可能な入力のセットを分割します。1つのグループからの入力は同等の結果を生成するため、このようなグループは等価クラスと呼ばれます。（同等の結果は同一の結果を意味しないことに注意してください。）

簡単な例として、小文字のASCII文字を大文字に変換するプログラムを考えます。他のキャラクターは恒等変換を行う必要があります。つまり、変更しないでください。同等クラスへの可能な内訳の1つを次に示します。

| # |  Equivalence class    | Input        | Output       | # test cases |
+------------------------------------------------------------------------+
| 1 | Lowercase letter      | a - z        | A - Z        | 26           |
| 2 | Uppercase letter      | A - Z        | A - Z        | 26           |
| 3 | Non-alphabetic chars  | 0-9!@#,/"... | 0-9!@#,/"... | 42           |
| 4 | Non-printable chars   | ^C,^S,TAB... | ^C,^S,TAB... | 34           |

最後の列は、すべてを列挙した場合のテストケースの数を報告します。技術的には、@ fishtoasterのルール1により、52のテストケースが含まれます。上記の最初の2行のテストケースはすべて「一般的なケース」に該当します。@fishtoasterのルール2は、上記の行3および4からも一部またはすべてを追加します。ただし、同値分割テストでは、各同値クラスのいずれかのテストケースで十分です。「a」または「g」または「w」を選択した場合、同じコードパスをテストしています。したがって、52個以上ではなく合計4個のテストケースがあります。

境界値分析では、わずかな改良を推奨しています。本質的には、同等クラスのすべてのメンバーが同等ではないことを示唆しています。つまり、境界の値も、それ自体がテストケースに値すると見なされる必要があります。（これを正当化する簡単な理由の1つは、悪名高いoff-by-oneエラーです！）したがって、各等価クラスに対して、3つのテスト入力を持つことができます。上記の入力ドメインを見て、ASCII値についてある程度の知識があれば、これらのテストケースの入力を思いつくかもしれません。

| # | Input                | # test cases |
| 1 | a, w, z              | 3            |
| 2 | A, E, Z              | 3            |
| 3 | 0, 5, 9, !, @, *, ~  | 7            |
| 4 | nul, esc, space, del | 4            |

（3つ以上の境界値を取得するとすぐに、元の等価クラスの描写を再検討することをお勧めしますが、これは単純であったため、改めて説明しませんでした。）したがって、境界値分析では、徹底的なテストを行うための128のテストケースと比較して、17のテストケース-完全なカバレッジの信頼性が高い。（言うまでもなく、組み合わせ論は、徹底的なテストは実際のアプリケーションでは単に実行不可能であると規定している！）

おそらく私の意見はあまり人気がありません。しかし、ユニットテストで経済的になることをお勧めします。ユニットテストが多すぎる場合、実際のコーディングではなくテストの維持に半分以上の時間を費やすことになります。

腸内の気分が悪いもの、または非常に重要かつ/または初歩的なもののテストを書くことをお勧めします。IMHO単体テストは、優れたエンジニアリングと防御的なコーディングに代わるものではありません。現在、私は多かれ少なかれ使用できないプロジェクトに取り組んでいます。本当に安定していますが、リファクタリングするのは苦痛です。実際、1年以内に誰もこのコードに触れたことがなく、そのベースとなっているソフトウェアスタックは4年前のものです。どうして？ユニットテストが散らかっているため、正確にはユニットテストと自動化された統合テストです。（キュウリなどを聞いたことはありますか？）そして、ここが最良の部分です：この（まだ）使い物にならないソフトウェアは、テスト駆動開発の先駆者である会社によって開発されました。：D

だから私の提案は：

• 基本的なスケルトンを開発した後にテストの作成を開始します。そうしないと、リファクタリングが苦痛になる場合があります。他の人のために開発する開発者は、最初から要件を取得することはありません。

• ユニットテストを迅速に実行できることを確認してください。統合テスト（キュウリなど）がある場合、少し時間がかかっても問題ありません。しかし、長期にわたるテストは面白くない、と私は信じています。（人々は、C ++の人気が低下した理由をすべて忘れています...）

• このTDDスタッフはTDDエキスパートに任せてください。

• はい、予期しない場所に応じて、エッジケースに集中することもあれば、一般的なケースに集中することもあります。ただし、常に予期しないことが予想される場合は、ワークフローと規律を再考する必要があります。;-)

テスト駆動開発で最初にテストする場合、最初に失敗した単体テストを作成せずに機能を追加することはないため、カバレッジは90％以上の範囲になります。

事後にテストを追加する場合は、Michael Feathersによる「レガシーコードで効果的に作業する」のコピーを入手して、コードにテストを追加する方法とコードをリファクタリングする方法の両方を検討することをお勧めしませんよりテストしやすくします。

テスト駆動開発のプラクティスに従うことを開始すると、プロセスをガイドし、テスト対象を自然に理解できるようにガイドがソートします。開始する場所：

テストが最初に来る

テストを書く前にコードを決して書かないでください。説明については、Red-Green-Refactor-Repeatを参照してください。

回帰テストを書く

バグに遭遇したときはいつでも、テストケースを書き、失敗することを確認してください。失敗したテストケースを介してバグを再現できない限り、実際にはそれを発見できていません。

赤緑リファクタリング繰り返し

赤：実装しようとしている動作の最も基本的なテストを書くことから始めます。このステップは、作業中のクラスまたは関数を使用するサンプルコードを記述することと考えてください。コンパイル/構文エラーがなく、失敗することを確認してください。これは明らかなはずです。コードを書いていないので、失敗しなければなりませんよね？ここで学ぶべき重要なことは、テストが少なくとも1回失敗しない限り、パスした場合、何らかの偽りの理由で行ったことが原因でテストが成功するかどうかを確認できないことです。

Green：実際にテストに合格する最も単純で愚かなコードを記述します。賢くなろうとしないでください。あなたは明らかにエッジケースが、アカウントのテストテイクがあることを見ていても、していないそれを処理するコードを記述（：あなたはそれを後で必要になりますが、エッジケースを忘れないでください）。アイデアは、コードのすべての部分、すべてif、すべてtry: ... except: ...をテストケースによって正当化する必要があるということです。コードはエレガント、高速、または最適化する必要はありません。テストに合格するだけです。

リファクタリング：コードをクリーンアップし、メソッド名を正しく取得します。テストがまだ合格しているかどうかを確認します。最適化。テストを再度実行します。

繰り返します：テストでカバーできなかったエッジケースを覚えていますか？それで、今がその大きな瞬間です。その状況をカバーするテストケースを作成し、失敗を監視し、コードを作成し、合格し、リファクタリングします。

コードをテストする

特定のコードに取り組んでおり、これがまさにテストしたいものです。これは、ライブラリ関数、標準ライブラリ、またはコンパイラをテストしてはならないことを意味します。また、「世界」のテストを避けるようにしてください。これには、外部Web API、データベース集約的なものなどの呼び出しが含まれます。モックアップを試みることができるときはいつでも（同じインターフェースに従うが、静的な定義済みデータを返すオブジェクトを作成します）。

単体テストの場合は、設計されていることを実行することをテストすることから始めます。それはあなたが書く最初のケースであるべきです。デザインの一部が「迷惑メールを渡すと例外をスローする必要がある」場合、それもデザインの一部であるため、テストします。

それから始めます。最も基本的なテストの実行経験を積むと、それで十分かどうかを学び始め、テストが必要なコードの他の側面を確認し始めます。

標準的な答えは、「壊れる可能性のあるすべてをテストする」ことです。

簡単すぎて破れないのは何ですか？データフィールド、脳死プロパティアクセサー、および同様の定型的なオーバーヘッド。他の要素は、おそらく要件の特定可能な部分を実装し、テストされることでメリットが得られる可能性があります。

もちろん、走行距離と作業環境の慣行は異なる場合があります。