私の見方では、あなたには両方の利点があり、あなたは「欠点」（原文のまま）にいます。
利点は、快適で、自分に合ったシステムを用意していることです。製品の妥当性を確認できてうれしいです。おそらく、異なるフレームワークを使用するもののすべてのテストを変更しようとしても、ビジネス上の価値はありません。コードをリファクタリングでき、テストが変更を取得する場合、またはさらに良いことには、テストを変更でき、リファクタリングされるまで既存のコードがテストに失敗する場合、すべてのベースがカバーされます。しかしながら...
ユニットテストAPIが適切に設計されていることの利点の1つは、ほとんどの最新のIDEで多くのネイティブサポートがあることです。これはハードコアVIには影響せず、Visual Studioユーザーをあざ笑うemacsユーザーもいますが、優れたIDEを使用するユーザーの場合は、テストをデバッグして実行することができます。 IDE自体。これは良いことですが、使用するフレームワークによってはさらに大きな利点があり、それはコードのテストに使用される言語にあります。
languageと言うとき、私はプログラミング言語について話しているのではなく、テストコードを物語のように読みやすくする流fluentな構文に包まれた豊富なセットワードについて話しているのです。特に、私はBDDフレームワークの使用を支持しています。私のお気に入りのDotNet BDD APIはStoryQです、しかし、同じ基本的な目的を持つ他のいくつかがあります。これは、要件ドキュメントから概念を取り出し、仕様で記述されている方法と同様の方法でコードで記述することです。しかし、本当に優れたAPIは、テスト内の個々のステートメントをすべてインターセプトし、そのステートメントが正常に実行されたか失敗したかを示すことにより、さらに進化します。これは非常に便利です。早期に戻ることなく実行されたテスト全体を確認できるため、呼び出し全体をデコードすることなく、失敗したテストの部分に注意を集中するだけでデバッグ作業が非常に効率的になります。シーケンス。もう1つの良い点は、テスト出力にこの情報がすべて表示されることです。
私が話していることの例として、以下を比較してください。
アサートの使用：
Assert(variable_A == expected_value_1); // if this fails...
Assert(variable_B == expected_value_2); // ...this will not execute
Assert(variable_C == expected_value_3); // ...and nor will this!
流fluentなBDD APIの使用：（
イタリック体のビットが基本的にメソッドポインターであることを想像してください）
WithScenario("Test Scenario")
.Given(*AConfiguration*) // each method
.When(*MyMethodToTestIsCalledWith*, variable_A, variable_B, variable_C) // in the
.Then(*ExpectVariableAEquals*, expected_value_1) // Scenario will
.And(*ExpectVariableBEquals*, expected_value_2) // indicate if it has
.And(*ExpectVariableCEquals*, expected_value_3) // passed or failed execution.
.Execute();
現在、BDD構文はより長く、より冗長であり、これらの例はひどく不自然ですが、特定のシステム動作の結果としてシステム内で多くのことが変化する非常に複雑なテスト状況では、BDD構文が明確になります。テスト対象の説明、およびテスト構成がどのように定義されているかについての説明。このコードをプログラマ以外の人に見せれば、彼らは何が起こっているかをすぐに理解できます。さらに、両方の場合で「variable_A」がテストに失敗すると、Assertsサンプルは問題を修正するまで最初のアサートを過ぎて実行されませんが、BDD APIはチェーンで呼び出されるすべてのメソッドを順番に実行し、ステートメントの個々の部分にエラーがありました。
個人的には、このアプローチは、テストの言語が顧客が論理要件を語る言語と同じであるという意味で、従来のxUnitフレームワークよりもはるかに優れていると思います。それでも、私は努力をサポートするための完全なテストAPIを発明する必要なしに、同様のスタイルでxUnitフレームワークを使用することができました。例えば：
Nunitの使用：
[Test]
void TestMyMethod()
{
const int theExpectedValue = someValue;
GivenASetupToTestMyMethod();
var theActualValue = WhenIExecuteMyMethodToTest();
Assert.That(theActualValue, Is.EqualTo(theExpectedValue)); // nice, but it's not BDD
}
ユニットテストAPIを使用して調査することにした場合、私のアドバイスは、しばらくの間、多数の異なるAPIを実験し、アプローチについて心を開いておくことです。私は個人的にBDDを支持していますが、あなたのビジネスニーズには、チームの状況に応じて異なるものが必要になる場合があります。ただし、重要なのは、既存のシステムの再推測を避けることです。必要に応じて、別のAPIを使用した少数のテストで既存のテストをいつでもサポートできますが、すべてを同じにするために大規模なテストを書き換えることはお勧めできません。レガシコードが使用できなくなると、そのコードとそのテストを新しいコードで簡単に置き換えることができ、代替APIを使用してテストすることができます。これにより、必ずしも真のビジネス価値をもたらさない大きな努力に投資する必要がなくなります。単体テストAPIの使用に関しては、