保守可能なテストの作成 : 複数のアサート - 複数のアサートを避ける

こんにちは😄
今日は、R. Osherove が彼の偉大な本 The Art of Unit Testing で私たちに与えたアドバイスについて話し続けます.今日は、複数のアサートについて、複数のアサートを避ける理由について簡単に説明します.

ケースの複数のアサート

実際、私たちは時々それを目にしますが、私たちのコードベースでこれを作成したのは私たちだと思います.しかし、2つのケースがあります.最初にコード例を見てください(これも本から😉)

[Test]
public void CheckVariousSumResultsOgnoringHigherThan1001()
{
   Assert.AreEqual(3, Sum(1001,1,2));
   Assert.AreEqual(3, Sum (1,1001,2));
   Assert.AreEqual(3, Sum (1,2,1001);
}

単体テスト用のツールを使用した場合、最初の assert が Fails である場合、他の 2 つは実行されないことがわかっています.そのため、2つのケースは次のようになります👇

他のアサートの出力は必要ありません

この場合、満足して続行できます😄

他のアサートの出力が必要です

これは、各アサートがユース ケースの異なるものをテストしているため、時々発生するケースです.したがって、エラーが発生した場合、エラーが発生したユースケースの小さな世界では正確に見つけることができません. 😏

ロイの考え

これはロイが言うことです:

This applies only when you’re asserting on multiple concerns. It wouldn’t hold if you were testing that you got a person with name X, age Y, and so on, because if one assert failed, you wouldn’t care about the others. But this would be a concern if you’re expecting an action to have multiple end results. For example, it should return 3 and change system state. Each one of these is a feature and should work independently of other features

対処方法

3 つの解決策があります.

アサートごとに個別のテストを作成します.

パラメータ化されたテストを使用します.
詳しく読みたい方は parameterized tests

Try...Catch ブロックを使用します.

順序は使用法で、1 番目は 2 番目よりも優れており、2 番目は 3 番目よりも優れています😸.

彼らについて私が思うこと

あなたにとってそれが同じかどうかはわかりませんが、私は最近、フロントエンドで徹底的に作業しています😩、他の2つのソリューションの場合、それはある種の困難です.だから私は毎日最初の解決策(アサートごとに個別のテストを作成する)を使用し、強制テスト分離の原則を尊重するように強制します.

😄読んでくれてありがとう.
The Grace of JESUS のユニット テストに関する次の記事では、オブジェクトを比較するユニット テストでの複数のアサートの別の側面について説明します.
よろしくお願いします😊