单元测试 - 相同的方法但不同的测试数据

Question

这是关于单元测试的非常基本的问题。

我有一个方法，例如GetOrderDetails，它调用Repository来获取订单详细信息。 我有一个模拟存储库，可以设置为返回库存响应。

为了测试GetOrderDetails方法，我至少会使用以下情况 -

存储库调用失败

1. 带有错误代码
2. 有一个例外

存储库调用成功

1. 返回零结果
2. 返回一个结果
3. 返回了多个结果

我应该编写一个测试方法来测试上述场景，还是应该为上述每个场景分别采用单独的测试方法？

我相信，将其分解为多种测试方法至少可以提供以下好处：1。在测试失败的情况下更高的隔离度2.测试方法中的代码量少于3.每个测试方法将具有单个存储库设置职责，例如设置为无结果，或设置为多个结果等

你可以帮忙看看你对此的看法吗？

Answer 1

我会为每个案例编写一个单独的单元测试。 基本上每次在方法中编写一个if或者一个switch ，你正在测试它意味着不同的单元测试来处理每个案例。 这样做的原因是，您的单元测试的安排部分将根据您希望代码采用的路线（不同的模拟期望，属性设置，......）而有所不同。 另外，我建议您按以下三个部分组织单元测试：

// arrange
// -> prepare mock objects, properties, setup expectations

// act
// -> invoke the method your are testing

// assert
// -> assert on the results returned by the method your are testing

Answer 2

我知道有些人可能会建立一个基于数据源中不同条件执行的数据驱动测试方法，但我更喜欢单独的方法，特别是因为这样我就可以沿着MethodName_StateUnderTest_ExpectedResult （命名约定）给它一个有意义的名称。由敏捷/单元测试教练和作家Roy Osherove等人倡导）。 我可以查看名称，并立即知道通过或失败的原因，不必怀疑可能已经通过或失败的变体。 它也有助于我的单元测试不依赖于文件系统。

Answer 3

这确实是一个主观问题，你会得到各种答案。 要记住一些事情。

1. 保持测试代码简短而甜蜜。 我尝试将所有单元测试功能放在一个屏幕上。 如果我能做到这一点，那么我想在那里放任何东西。 只要覆盖方法很短，我肯定会在特定函数中测试多个东西。

2. 复制代码单元测试，只有一个变量差异是维护噩梦。 想象一下，有5个单元测试，每个测试包含40行代码，它们之间的唯一区别是愚蠢的返回值。 如果你这样做，你会在6个月内摸不着头脑。

3. 编写单元测试时使用代码覆盖工具。 我不能过分强调这一点。 它将帮助您识别您未测试的区域。 我发现它也有助于我消除死代码，因为更少的代码是更少的潜在错误。

4. 我在单元测试中使用的最复杂的逻辑是for循环。 这只是为了初始化一个简单的数组，如果它需要特定于测试的东西。 我总是避免单元测试中的if语句。 但是，如果您正在使用数据驱动测试，那么如果需要，可以使用for循环将数据提供给测试。 但是如果for循环很小，也可以随意展开循环。

我希望其中一些建议有所帮助。