单元测试：特定测试和控制流程

Question

我对单元测试和一般的测试还很陌生。我正在使用phpUnit进行开发，但是由于我的问题更笼统/是设计问题，因此实际环境不应该太重要。

我认为，写一个尽可能具体的测试用例是一种好习惯。例如（越晚越好）：

assertNotEmpty($myObject);              // myObject is not Null 
assertInternalType('array', $myObject); // myObject is an array
assertGreaterThan(0, count($myObject)); // myObject actually has entries

如果正确，这是我的问题：

如果要测试的对象的状态取决于外部源（即DB）-甚至一般而言，在测试用例中编写一些流控制是一种可接受的做法吗？

赞：

if (myObject !== null) {
    if (count(myObject) > 0) {
    // assert some Business Logic
    }
    else {
    // assert some different Business Logic  
    }
} 
是在测试用例中允许这种流控制，还是“代码异味”，应予以规避？如果可以的话，这里有什么提示或做法吗？

我对单元测试和一般的测试还很陌生。我正在使用phpUnit进行开发，但是由于我的问题更笼统/是设计问题，所以实际环境不应该太重要。 ...

Answer 1

Paul的答案涉及测试方法的范围和断言，但是您的问题的代码所暗示的一件事是，如果返回的对象具有值X，则将测试A，但是如果其返回值Y，则将测试B。换句话说，您的测试将期望多个值然后根据实际结果测试不同的事物。

Answer 2

在您的测试用例中可以有一些控制流是可以的，但是总的来说，请理解，如果单元测试是不相交的，那么它们将是最佳的，也就是说，它们各自针对不同的事物进行测试。效果很好的原因是，当您的测试用例失败时，您可以从失败的测试用例中准确地看到什么是失败，而不是需要深入研究更大的测试用例以了解出了什么问题。通常的度量标准是每个单元测试用例的单个断言。也就是说，每条规则都有例外，这肯定是其中之一。在您的测试用例中有几个断言并不一定没有错，尤其是当测试用例场景的设置/拆卸特别困难时。但是，您要避免的真正的代码味道是您需要一个“测试”来测试所有代码路径的情况。