シンプルなテストまたはより複雑なテスト？

Question

TDDの学習を開始し、テストを書くためのさまざまなアプローチについていくつかの誤解を受けました。

いくつかの記事では、すべてのケースに対して新しいテストを書くべきだと言われています。したがって、1つのメソッドに対して2つ以上のテストを行うことができます。

私が見たもう1つのアプローチは、より複雑なテストをいくつかのステップで記述することです。たとえば、次のようにします。書き込みテスト - >失敗 - >書き込みコード - >成功 - >現在のテストの変更（新しいアサーションの追加） - >失敗 - >書き込みコード - >成功 - このステップの後、テストは単一のメソッドの全体的なロジックをカバーしています。

TDDを使用するアプローチの賛否両論は何ですか？

Answer 1

新しいテストケースを作成する必要がなく（それらの名前が付いてくるので）、既存のテストケースに複数のアサーションを追加するのは簡単ですが、より小さなテストを書くことを好むでしょうより具体的です。主な利点は、テストが失敗した場合に、より良い情報を得ることです。

私は不自然な例を考え出すことができるかどうかを見てみましょう：あなたが見ることができるように、試験方法のための良い名前を発明することは難しい本当にある

[Fact] 
public void TestEverything() 
{ 
    var foo = new Foo(); 
    Assert.Equal(42, foo.TheAnswer); 
    Assert.Equal(string.Empty, foo.Log); 
    foo.DoSomething(); 
    Assert.Equal("something was done", foo.Log); 
} 


[Fact] 
public void TheAnswer_AfterCreation_ShouldAdhereToTheHitchhikersGuide() 
{ 
    var foo = new Foo(); 
    Assert.Equal(42, foo.TheAnswer); 
} 

[Fact] 
public void Log_AfterCreation_ShouldBeEmpty() 
{ 
    var foo = new Foo(); 
    Assert.Equal(string.Empty, foo.Log); 
} 

[Fact] 
public void Log_DoSomething_ShouldLogSomething() 
{ 
    var foo = new Foo(); 
    foo.DoSomething(); 
    Assert.Equal("something was done", foo.Log); 
} 

（と私は特に最後のものに悪い仕事をしてくれました） TestEverythingが失敗したという情報の代わりに、テストハーネスからかなり素敵な説明を得ることができます（挑戦：それをより良い名前にしようとします;-)）