这是关于单元测试的非常基本的问题。
我有一个方法,例如GetOrderDetails调用Repository来获取订单详细信息。我有一个模拟存储库,可以设置为返回库存响应。
为了测试GetOrderDetails方法,我至少会使用以下情况 -
存储库调用失败
存储库调用成功
我是否应该编写单个测试方法来测试上述场景,还是应该为上述每种场景分别采用单独的测试方法?
我相信,将其分解为多种测试方法至少会带来以下好处 1.测试失败时的隔离度更高 2.测试方法中的代码量较少 3.每个测试方法都有一个存储库设置职责,例如设置无结果,或设置多个结果等
请你帮忙解决一下你对此的看法吗?
答案 0 :(得分:8)
我会为每个案例编写一个单独的单元测试。基本上每次在您正在测试的方法中编写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
答案 1 :(得分:3)
我知道有些人可能会建立一个基于数据源中不同标准执行的数据驱动测试方法,但我更喜欢单独的方法,特别是因为这样我可以按照 MethodName_StateUnderTest_ExpectedResult (由敏捷/单元测试教练和作者Roy Osherove等人倡导的命名约定)。我可以查看名称,并立即知道通过或失败的原因,不必怀疑可能已经通过或失败的变体。它也有助于我的单元测试不依赖于文件系统。
答案 2 :(得分:2)
这确实是一个主观问题,你会得到各种答案。 要记住一些事情。
保持测试代码简短而甜蜜。我尝试将所有单元测试功能放在一个屏幕上。如果我能做到这一点,那么我想在那里放任何东西。只要覆盖方法很短,我肯定会在特定函数中测试多个东西。
重复代码单元测试,只有一个变量差异是维护噩梦。想象一下,有5个单元测试,每个测试包含40行代码,它们之间的唯一区别是愚蠢的返回值。如果你这样做,你将在6个月内摸不着头脑。
在编写单元测试时使用代码覆盖工具。我不能过分强调这一点。它将帮助您识别您未测试的区域。我发现它也有助于我消除死代码,因为更少的代码是更少的潜在错误。
我在单元测试中使用的最复杂的逻辑是for循环。这只是为了初始化一个简单的数组,如果它需要特定于测试的东西。我总是避免单元测试中的if语句。但是,如果您正在使用数据驱动测试,那么如果需要,可以使用for循环将数据提供给测试。但是如果for循环很小,也可以自由展开循环。
我希望其中一些建议有所帮助。