情報のソースとしてユニットテストを使用する方法

私の同僚は、アジャイル開発に関するセミナーにかつて、ユニットテストを技術文書として使用することが可能だと聞いていました。クラスの使用方法の例として単体テストを使用するようなもの。

Googleのクイック検索でTDDとドキュメントが提供されました。これにより、それが可能であることが証明されます。しかし、コードを見ると、明らかにそのような方法で単体テストを実装できていないことがわかります。

私の意見では、ユニットテストは、モックおよび偽のクラスと関数の助けがあっても、最小限のユニットとしてコードをテストするためにあります。

したがって、質問は次のとおりです。

• クラス（またはクラスのセット）の使用方法を示すのは、機能テストのタスクではありませんか？
• 単体テストを技術文書として使用できる場合、そのような単体テストの実装方法に関するガイドラインはありますか？

TDDを適用する場合、作成した各ユニットテストはクラスの機能に対応します。したがって、テストを作成すると、実際にはクラスの機能、依存関係、例外、およびクラスのドキュメントも作成されます。

TDDを適用しない場合でも、単体テストはクラスとその機能についてのアイデアを提供します。ユニットテスト名は非常にわかりやすいので、ほとんどドキュメントを作成する必要はありません。

のようなユニットテストを考えてください

public void Customer_Service_Can_Register_New_Customers(){...}
public void Customer_Service_Cannot_Register_Customers_With_Duplicate_Emails(){...}

これらは自己記述的な方法であり、読みも簡単です。したがって、それらはドキュメントとしても機能します。

ユニットテストは、適切に記述されている場合、クラスまたはメソッドなどのドキュメントとして機能します。

よく書かれたものは、何がテストされているかを簡単に理解できるため、理解を深めることができますが、貧弱なテストであっても、テストされているものがどのように機能するか、作者がテストするために何が重要であると考えたのかについて読者にいくつかのアイデアを与えます。

ヘック、私は外部ライブラリの単体テストを書くことで知られています。テストが必要なためではなく、ライブラリの理解が正しいことを確認したいからです。そして、将来的に、私が物事をどのように使用しているかについて誰かが質問した場合、テストコードの中に私の理解があります。

機能テストは機能全体を理解するのに役立ちますが、単体テストはコードの小さな範囲（単一のメソッドなど）を理解するのに役立ちます。

優れた単体テストは、優れた技術ドキュメントとしても機能します。また、優れたシンプルで有用なテストを作成するために役立ついくつかのことがあります。私が遭遇した2つの最も重要なポイントは

• すべてのテストが独立していることを確認してください。テストのサブセットを任意の順序で実行できるはずです。

• 各テストで1つだけをテストするようにしてください。これにより、テストを特定のシンプルなものに保つことができますが、脆弱ではありません。

合格基準/文書化としてのテストのアイデアは素晴らしいものです。ただし、単体テストはユーザーストーリーではなく、アーキテクチャ/コードの設計に重点を置く傾向があります。より高いレベルのユースケースまたは要件を文書化しようとすると、扱いにくい場合があります。私は（まだ）それについて詳しく調べていませんが、ビヘイビア駆動開発がその問題を解決するかもしれません。

ドキュメンテーションやユニットテストがそれよりも優れているよりも、例を学ぶ方がはるかに簡単だと思います。それだけでなく、たとえば、ユニットで何をしてはいけないかを示してくれます。

ただし、それらが唯一のドキュメント形式ではありません。脳はすべて異なる働きをすることを認識しなければなりません。これは、ドキュメントとしてJUST単体テストを使用することをお勧めする人や、コードが完全に見落としていることの1つだと思います。さらに痛ましいのは、単一の脳でも異なる媒体から異なることを学ぶという事実です。コードを見たりAPIドキュメントを読んだりするだけではなく、クラス図とはまったく異なるものを学びます。

しかし、結局のところ、ダイアグラムとAPIドキュメントがすべて揃っている場合は、おそらく失敗しています。例が必要です。何かが使用されているのを確認する必要があります。私はこれをコードで検索するかもしれませんが、私が行き詰まっている他の例が欠けているかもしれませんが、これは良いユニットテストほど多くを私に教えてくれません。

今日のテストはすべて、用語の混乱であり、人によって意味が少し異なり、定義は時間とともに変化しています。

たとえば、TDDは以前はBDDと呼ばれていたものでした。違いは、テスト駆動開発による単体テストが、テスト方法（通常は自動化ツールによって生成される）へのはるかに細かいアプローチであるためです。以前はTDDでしたが、クラスのサイズのユニットをテストするためのやや粗い方法でしたが、現在は機能テストと呼ばれています。

（なんらかの形式の）テストを使用できるという考えは、ユーザーがコードのユニットをどのように使用するかのように見えるテストを作成できるということです。これは、ドキュメントとテストの例になります。

たとえば、単純なネットワーククラスがある場合（たとえば）。各メソッドを個別にテストするのではなく、クラスがテストを必要とするユニットであることをテストすることをお勧めします。次に、ユニットテストでは、メソッドを呼び出してオブジェクトを初期化し、ホストとポートを設定し、メソッドを呼び出してデータを送信し、場合によってはメソッドも呼び出して受信します。

構成された状態にオブジェクトを設定し、いくつかの作業を実行させることによってオブジェクトをテストする単一の「単体テスト」に収まるすべてのもの。単体テストをさらに行うと、不良データが含まれますが、それらをドキュメントに含める必要はありません。

これは今日の単体テストとは見なされませんが、すべてユニットの定義に帰着します。