Arrange-Act-Assertの古典的なテストパターンに関しては、Actの前にカウンターアサーションを追加することがよくあります。このようにして、通過するアサーションがアクションの結果として実際に通過していることがわかります。
これは、red-green-refactorの赤に似ていると思います。テスト中に赤いバーが表示された場合にのみ、緑色のバーは、違いをもたらすコードを記述したことを意味します。合格したテストを作成すると、どのコードでもそれを満たします。同様に、Arrange-Assert-Act-Assertに関しても、最初のアサーションが失敗した場合、どのActも最終的なAssertを通過したことになるので、実際にはActについて何も検証していません。
テストはこのパターンに従っていますか？なぜですか、なぜそうではありませんか？
明確化の更新：最初のアサーションは基本的に最終アサーションの反対です。それはアレンジが機能したという主張ではありません。Actがまだ機能していないという主張です。
回答:
これは最も一般的なことではありませんが、独自の名前を付けるのに十分一般的です。この手法は、ガードアサーションと呼ばれます。490ページの詳細な説明は、Gerard Meszaros 著の優れたxUnit Test Patterns（強く推奨）にあります。
通常、私はこのパターンを使用しません。私が確認する必要があると思う前提条件を検証する特定のテストを作成する方が正しいためです。このようなテストは、前提条件が満たされない場合は常に失敗するはずです。つまり、他のすべてのテストに組み込む必要はありません。1つのテストケースで検証できるのは1つだけなので、これにより、問題をより適切に分離できます。
特定のテストケースで満たす必要のある前提条件が多数ある場合があるため、複数のGuardアサーションが必要になる場合があります。すべてのテストでそれらを繰り返す代わりに、各前提条件に対して1つ（そして1つだけ）のテストを行うことで、テストコードをより管理しやすくなります。
Arrange- Assume -Act-Assert として指定することもできます。
次の例のように、NUnitにはこれに対する技術的なハンドルがあります。http： //nunit.org/index.php？p = theory＆r = 2.5.7
ここに例があります。
public void testEncompass() throws Exception {
Range range = new Range(0, 5);
assertFalse(range.includes(7));
range.encompass(7);
assertTrue(range.includes(7));
}
Range.includes()単にtrueを返すように書いたのかもしれません。私はしませんでしたが、持っているかもしれないと想像することができます。または、他の方法でそれを間違って書いた可能性があります。私はTDDで私が実際にそれを正しく理解したことを願って期待します-それincludes()はうまくいく-しかし多分私はしなかった したがって、最初のアサーションは健全性チェックであり、2番目のアサーションが本当に意味があることを確認します。
それ自体を読んで、assertTrue(range.includes(7));「変更された範囲に7が含まれていることを表明する」と言っています。最初のアサーションのコンテキストで読むと、次のように述べています。「include （）を呼び出すと、7が含まれることをアサートします。また、includeはテストしているユニットなので、これは（小さい）値だと思います。
私は自分の答えを受け入れています。他の多くは、セットアップのテストについての私の質問を誤解しました。これは少し違うと思います。
Arrange-Assert-Act-Assertテストでは、常に2つのテストにリファクタリングすることができます。
1. Arrange-Assert
そして
2. Arrange-Act-Assert
最初のテストはアレンジフェーズで設定されたものに対してのみアサートし、2番目のテストはアクトフェーズで発生したものに対してのみアサートします。
これには、失敗したのがアレンジフェーズかアクトフェーズかについてより正確なフィードバックを提供できるという利点がArrange-Assert-Act-Assertありますが、オリジナルではこれらが混同されているため、より深く掘り下げて、どのアサーションが失敗したのか、なぜ失敗したのかを正確に調べて、失敗したのはアレンジまたはアクトでした。
また、テストをより小さな独立したユニットに分離しているため、ユニットテストの意図をよりよく満たします。
最後に、異なるテストで同様のArrangeセクションが表示された場合は、これらを共有ヘルパーメソッドに引き出して、将来的にテストがより乾燥して保守しやすくなるようにしてください。
私は今これをやっています。異なる種類のAAAA
Arrange - setup
Act - what is being tested
Assemble - what is optionally needed to perform the assert
Assert - the actual assertions
更新テストの例：
Arrange:
New object as NewObject
Set properties of NewObject
Save the NewObject
Read the object as ReadObject
Act:
Change the ReadObject
Save the ReadObject
Assemble:
Read the object as ReadUpdated
Assert:
Compare ReadUpdated with ReadObject properties
その理由は、ACTがReadUpdatedの読み取りを含まないようにするためです。これは、ACTが行為の一部ではないためです。行為は変化し、保存するだけです。だから本当に、アサーションのためのARRANGE ReadUpdated、私はアサーションのためにASSEMBLEを呼び出しています。これは、ARRANGEセクションの混乱を防ぐためです。
ASSERTにはアサーションのみを含める必要があります。これにより、アサートを設定するACTとASSERTの間にASSEMBLEが残ります。
最後に、アレンジで失敗した場合、これらの些細なバグを防止/発見するために他のテストが必要であるため、テストは正しくありません。私が提示するシナリオでは、READとCREATEをテストする他のテストがすでにあるはずです。「Guardアサーション」を作成すると、DRYが壊れてメンテナンスが作成される可能性があります。
私はすでにこのテクニックについて読んだことがあります-おそらくあなたから-しかし、私はそれを使用しません。主に、ユニットテストのトリプルAフォームに慣れているためです。
今、私は興味があります、そしていくつかの質問があります：テストをどのように記述しますか？あなたはこのアサーションを失敗させますか？
おそらくコードをリファクタリングした後で失敗することがありますか？これは何を教えてくれますか？おそらく、それが役に立った例を共有できます。ありがとう。
失敗したテストを調査するとき、これを以前に行いました。
かなり頭をひっかいた後、原因は「アレンジ」中に呼び出されたメソッドが正しく機能していなかったことが原因であると判断しました。テストの失敗は誤解を招くものでした。アレンジ後にアサートを追加しました。これにより、実際の問題を強調する場所でテストが失敗しました。
テストのアレンジ部分が長すぎて複雑な場合、コードのにおいもここにあると思います。
一般的に、「アレンジ、アクト、アサート」はとても好きで、個人的な基準として使用しています。ただし、ここで忘れがちなことの1つは、アサーションが行われたときに私がアレンジしたことをアレンジしないことです。ほとんどの場合、ガベージコレクションなどを介してほとんどのことが自動的になくなるので、これはそれほど煩わしさを引き起こしません。ただし、外部リソースへの接続を確立している場合は、完了したらそれらの接続を閉じることをお勧めします。アサーションを使用するか、多くの場合、サーバーまたは高価なリソースがどこかにあり、他の誰かに渡すことができるはずの接続または重要なリソースを保持しています。これは、TearDownやTestFixtureTearDownを使用しない開発者の1人である場合に特に重要です。1つ以上のテスト後にクリーンアップする。もちろん、「アレンジ、アクト、アサート」は、私が開いたものを閉じなかった私の責任ではありません。「dispose」が推奨する適切な「A-word」同義語がまだ見つからないため、この「gotcha」についてのみ言及します。助言がありますか？
WikipediaのDesign by Contractに関する記事をご覧ください。アレンジアクトアサートホーリートリニティは、同じ概念のいくつかをエンコードする試みであり、プログラムの正確さを証明することを目的としています。記事から：
The notion of a contract extends down to the method/procedure level; the
contract for each method will normally contain the following pieces of
information:
Acceptable and unacceptable input values or types, and their meanings
Return values or types, and their meanings
Error and exception condition values or types that can occur, and their meanings
Side effects
Preconditions
Postconditions
Invariants
(more rarely) Performance guarantees, e.g. for time or space used
これを設定するのに費やされた労力とそれが付加する価値の間にはトレードオフがあります。AAAは必要な最小限の手順を思い出させるのに役立ちますが、追加の手順を作成することをだれにも妨げるものではありません。
次のようなことをしていると思うので、このパターンは使用しません。
Arrange
Assert-Not
Act
Assert
アレンジパーツが正しく動作していることがわかっているため、アレンジパーツのすべてをテストするか、テストを必要としないほど単純にする必要があることを意味しているため、無意味かもしれません。
あなたの答えの例を使う：
public void testEncompass() throws Exception {
Range range = new Range(0, 5);
assertFalse(range.includes(7)); // <-- Pointless and against DRY if there
// are unit tests for Range(int, int)
range.encompass(7);
assertTrue(range.includes(7));
}
例のすべてを本当にテストしたい場合は、次のようなテストを試してください。
public void testIncludes7() throws Exception {
Range range = new Range(0, 5);
assertFalse(range.includes(7));
}
public void testIncludes5() throws Exception {
Range range = new Range(0, 5);
assertTrue(range.includes(5));
}
public void testIncludes0() throws Exception {
Range range = new Range(0, 5);
assertTrue(range.includes(0));
}
public void testEncompassInc7() throws Exception {
Range range = new Range(0, 5);
range.encompass(7);
assertTrue(range.includes(7));
}
public void testEncompassInc5() throws Exception {
Range range = new Range(0, 5);
range.encompass(7);
assertTrue(range.includes(5));
}
public void testEncompassInc0() throws Exception {
Range range = new Range(0, 5);
range.encompass(7);
assertTrue(range.includes(0));
}
そうでないと、エラーの可能性が非常に多く失われるためです。たとえば、範囲の後、範囲には7のみが含まれます。範囲の長さのテストもあります（ランダムな値も含まれていないことを確認するため）。範囲内に5を含めることを完全に試みるための別の一連のテスト...何が期待されますか-範囲内の例外、または範囲は変更されませんか？
とにかく、ポイントはあなたがテストしたい行為に何らかの仮定がある場合、それらを独自のテストに入れます、そうですか？