医療ソフトウェアのケースに基づいたTDDトレーニング中に、「ユーザーが[保存]ボタンを押すと、システムは患者を追加し、デバイスを追加し、デバイスデータレコードを追加する」というストーリーを実装します。
最終的な実装は次のようになります。
if (_importDialog.Show() == ImportDialogResult.SaveButtonIsPressed)
{
AddPatient();
AddDevice();
AddDeviceDataRecords();
}
それを実装する方法は2つあります。
最初のケースでは、if句の条件に何か問題が発生した場合、3つのテストすべてが失敗します。しかし、テストが失敗した場合の2番目のケースでは、何が正確に間違っているのかわかりません。どのような方法を好むでしょうか。
回答:
しかし、テストが失敗した場合の2番目のケースでは、何が正確に間違っているのかわかりません。
これは、テストが生成するエラーメッセージの程度に大きく依存すると思います。一般に、メソッドが呼び出されたことを確認するにはさまざまな方法があります。たとえば、モックオブジェクトを使用すると、テスト中にどのメソッドが呼び出されなかったかを説明する正確なエラーメッセージが表示されます。呼び出しの影響を検知してメソッドが呼び出されたことを確認した場合、説明的なエラーメッセージを生成するのはユーザー次第です。
実際には、オプション1と2の選択は状況にも依存します。レガシープロジェクトで上記のコードを見る場合、条件が満たされたときに3つのメソッドのそれぞれが適切に呼び出されることを確認するために、ケース＃2の実用的なアプローチを選択します。このコードを今開発している場合、3つのメソッド呼び出しは別々の時点で（おそらく互いに数日または数か月離れて）1つずつ追加される可能性が高いため、新しい別個の単体テストを追加します。各呼び出しを確認します。
また、どちらの方法でも、個々のメソッドのそれぞれが想定どおりに機能することを確認するために、個別のユニットテストを行う必要があります。
あなたの例の粒度は、単体テストと受け入れテストの違いのようです。
ユニットテストは、可能な限り少ない依存関係で、機能の単一ユニットをテストします。あなたの場合、4つのユニットテストがあります
ユニットテストは開発者向けであるため、コードが技術的に正しいという自信が得られます。
受け入れテストでは、ユーザーの観点から、組み合わせた機能をテストする必要があります。それらは、ユーザーストーリーに沿ってモデル化し、可能な限り高レベルにする必要があります。したがって、関数が呼び出されたかどうかを確認する必要はありませんが、ユーザーに見える利点が達成された場合：
ユーザーがデータを入力したら、[OK]をクリックして...
受け入れテストは、顧客向け、または顧客とのより良いコミュニケーションを構築するためのものです。
「あなたは何を好む」あなたの質問に答えるために：今、あなたにとってより大きな問題は何ですか、バグと回帰（=>より多くのユニットテスト）または全体像を理解し形式化（=>より受け入れテスト）
それを実装する方法は2つあります。
それは間違っています。
それぞれが1つのメソッド（AddPatient、AddDevice、AddDeviceDataRecords）を検証した3つのテストが呼び出されました
あなたは必要があり、それが動作を確認するためにこれを行います。
3つのメソッドすべてを検証する1つのテストが呼び出されました
あなたはしなければならないも必ずAPIの作品であることを、これを行います。
クラスは、ユニットとして、完全にテストする必要があります。各メソッド。
3つの方法すべてをカバーするテストから始めることはできますが、あまりわかりません。
テストが失敗した場合、何が正確に間違っているのかはわかりません。
正しい。そのため、すべてのメソッドをテストします。
パブリックインターフェイスをテストする必要があります。このクラスは3つのプラス1つのことを行うため（ユーザーストーリーのために1つのメソッドにバンドルされている場合でも）、4つのすべてをテストする必要があります。3つの低レベルと1つのバンドル。
意味のある機能の文の単体テストを記述します。この文はメソッドに何度もマッピングされます（コードを適切に記述している場合）が、多くのメソッドが含まれて大きくなることもあります。
たとえば、システムに患者を追加するには、いくつかのサブルーチン（子関数）を呼び出す必要があると想像してください。
また、これらの各機能の単体テストを記述することもできます。