actionscript-3 - 複雑な動作をテストするときに、単体テストで複数のアサーションを使用しても問題ありませんか？

Question

これが私の具体的なシナリオです。

ArcGIS APIforFlex内でクラスQueryQueueをラップするクラスがあります。QueryTaskこれにより、実行のために複数のクエリタスクを簡単にキューに入れることができます。呼び出しQueryQueue.execute()は、キュー内のすべてのタスクを繰り返し処理し、それらのexecuteメソッドを呼び出します。

すべての結果が受信されて処理されるQueryQueueと、完了したイベントがディスパッチされます。私のクラスへのインターフェースはとてもシンプルです。

public interface IQueryQueue
{
    function get inProgress():Boolean;
    function get count():int;

    function get completed():ISignal;
    function get canceled():ISignal;

    function add(query:Query, url:String, token:Object = null):void; 
    function cancel():void;
    function execute():void;
}

QueryQueue.executeメソッドが成功したと見なされるには、いくつかのことが発生する必要があります。

1. task.execute各クエリタスクで1回だけ呼び出す必要があります
2. inProgress = true結果が保留中の間
3. inProgress = false結果が処理されたとき
4. completed結果が処理されたときにディスパッチされます
5. canceled呼び出されることはありません
6. キュー内で実行される処理は、クエリ結果を正しく処理およびパッケージ化します

私が苦労しているのは、これらのテストを読み取り可能で論理的で保守可能なテストに分割することです。

論理的には、1つの状態、つまり成功した実行状態をテストしています。これは、上記の＃1から＃6をアサートする1​​つの単体テストが真であることを示唆します。

[Test] public mustReturnQueryQueueEventArgsWithResultsAndNoErrorsWhenAllQueriesAreSuccessful:void

ただし、テストの名前は、テストに合格したと見なされるために真でなければならないすべてのことを説明しているわけではないため、有益ではありません。

オンライン（こことprogrammers.stackexchange.comを含む）を読むと、単体テストには（ガイドラインとして）1つのアサーションのみが必要であると主張するかなりの規模のキャンプがあります。その結果、テストが失敗した場合、何が失敗したかを正確に知ることができます（つまり、inProgressがtrueに設定されていない、完了が複数回表示されるなど）。

[Test] public mustInvokeExecuteForEachQueryTaskWhenQueueIsNotEmpty():void
[Test] public mustBeInProgressWhenResultsArePending():void
[Test] public mustNotInProgressWhenResultsAreProcessedAndSent:void
[Test] public mustDispatchTheCompletedEventWhenAllResultsProcessed():void
[Test] public mustNeverDispatchTheCanceledEventWhenNotCanceled():void
[Test] public mustReturnQueryQueueEventArgsWithResultsAndNoErrorsWhenAllQueriesAreSuccessful:void
// ... and so on

これは、テストで多くのコードが繰り返されることになる可能性がありますが、適切なメソッドを使用することで最小限に抑えることができsetupますteardown。

この質問は他の質問と似ていますが、検証が必要な複数の状態と動作を示す複雑な単体テストシナリオの適切な表現であると思うため、この特定のシナリオに対する回答を探しています。他の質問の多くには、残念ながら、例がないか、例が複雑な状態と動作を示していません。

Answer 1

In my opinion, and there will probably be many, there are a couple of things here:

1. If you must test so many things for one method, then it could mean your code might be doing too much in one single method (Single Responsibility Principle)
2. If you disagree with the above, then the next thing I would say is that what you are describing is more of an integration/acceptance test. Which allows for multiple asserts, and you have no problems there. But, keep in mind that this might need to be relegated to a separate section of tests if you are doing automated tests (safe versus unsafe tests)
3. And/Or, yes, the preferred method is to test each piece separately as that is what a unit test is. The closest thing I can suggest, and this is about your tolerance for writing code just to have perfect tests...Is to check an object against an object (so you would do one assert that essentially tests this all in one). However, the argument against this is that, yes it passes the one assert per test test, but you still lose expressiveness.

Ultimately, your goal should be to strive towards the ideal (one assert per unit test) by focusing on the SOLID principles, but ultimately you do need to get things done or else there is no real point in writing software (my opinion at least :)).

Answer 2

Let's focus on the tests you have identified first. All except the last one (mustReturnQueryQueueEventArgs...) are good ones and I could immediatelly tell what's being tested there (and that's very good sign, indicating they're descriptive and most likely simple).

The only problem is your last test. Note that extensive use of words "and", "with", "or" in test name usually rings problems bell. It's not very clear what it's supposed to do. Return correct results comes to mind first, but one might argue it's vague term? This holds true, it is vague. However you'll often find out that this is indeed pretty common requirement, described in details by method/operation contract.

In your particular case, I'd simplify last test to verify whether correct results are returned and that would be all. You tested states, events and stuff that lead to results building already, so there is no need to that again.

Now, advices in links you provided are quite good ones actually, and generally, I suggest sticking to them (single assertion for one test). The question is, what single assertion really stands for? 1 line of code at the end of test? Let's consider this simple example then:

// a method which updates two fields of our custom entity, MyEntity
public void Update(MyEntity entity)
{
    entity.Name = "some name";
    entity.Value = "some value";
}

This method contract is to perform those 2 operations. By success, we understand entity to be correctly updated. If one of them for some reasons fails, method as a unit is considered to fail. You can see where this is going; you'll either have two assertions or write custom comparer purely for testing purposes.

Don't be tricked by single assertion; it's not about lines of code or number of asserts (however, in majority of tests you'll write this will indeed map 1:1), but about asserting single unit (in the example above, update is considered to be an unit). And unit might be in reality multiple things that don't make any sense at all without eachother.

And this is exactly what one of questions you linked quotes (by Roy Osherove):

My guideline is usually that you test one logical CONCEPT per test. you can have multiple asserts on the same object. they will usually be the same concept being tested.

It's all about concept/responsibility; not the number of asserts.

Answer 3

I am not familiar with flex, but I think I have good experience in unit testing, so you have to know that unit test is a philosophy, so for the first answer, yes you can make a multiple assert but if you test the same behavior, the main point always in unit testing is to be very maintainable and simple code, otherwise the unit test will need unit test to test it! So my advice to you is, if you are new in unit testing, don't use multiple assert, but if you have good experience with unit testing, you will know when you will need to use them