在测试复杂行为时，可以在单元测试中使用多个断言吗？

这是我的具体场景。

我有课QueryQueue包裹着QueryTaskArcGIS API for Flex 中的类。这使我能够轻松地将多个查询任务排队执行。呼唤QueryQueue.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;
}

For the QueryQueue.execute方法要被认为成功必须满足几件事情。

1. task.execute每个查询任务必须且仅调用一次
2. inProgress = true在结果待定期间
3. inProgress = false当结果被处理时
4. completed处理结果后调度
5. canceled从未被调用过
6. 队列内完成的处理正确处理并打包查询结果

我正在努力将这些测试分解为可读的、逻辑的和可维护的测试。

从逻辑上讲我正在测试一个state，即执行成功状态。这表明一个单元测试将断言上面#1 到#6 为真。

[Test] public mustReturnQueryQueueEventArgsWithResultsAndNoErrorsWhenAllQueriesAreSuccessful:void

然而，测试的名称并不能提供任何信息，因为它没有描述被视为通过测试必须真实的所有内容。

在线阅读（包括here https://stackoverflow.com/questions/735737/multiple-assertions-when-unit-testing-constructor and at 程序员.stackexchange.com https://softwareengineering.stackexchange.com/questions/7823/is-it-ok-to-have-multiple-asserts-in-a-single-unit-test）有一个相当大的阵营主张单元测试应该只有一个断言（作为指导）。因此，当测试失败时，您确切地知道失败的内容（即 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 and teardown方法。

虽然这个问题与其他问题类似，但我正在寻找这个特定场景的答案，因为我认为它很好地代表了复杂的单元测试场景，展示了需要验证的多种状态和行为。不幸的是，许多其他问题没有示例，或者示例没有展示复杂的状态和行为。

在我看来，可能会有很多，这里有几件事：

1. 如果您必须为一种方法测试如此多的事情，那么这可能意味着您的代码可能在一种方法中做了太多事情（单一责任原则） http://en.wikipedia.org/wiki/Single_responsibility_principle
2. 如果您不同意上述内容，那么我接下来要说的是，您所描述的更多的是集成/验收测试。它允许多个断言，并且你在那里没有问题。但是，请记住，如果您正在进行自动化测试（安全测试与不安全测试），则可能需要将其归入单独的测试部分
3. 和/或者，是的，首选方法是单独测试每个部分，因为这就是unit测试群岛。我能建议的最接近的一件事是关于你对编写代码只是为了进行完美测试的容忍度......就是对照一个对象检查一个对象（所以你会做一个断言，基本上测试这一切）。然而，反对这一点的论点是，是的，它通过了每个测试一个断言的测试，但你仍然失去了表达能力。

最终，你的目标应该是努力实现理想（每个断言一个断言）unit测试）通过关注坚实的原则 http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29，但最终你确实需要把事情做好，否则编写软件就没有意义了（至少我认为:)）。