按方法或行为拆分测试？

Question

我有一个需要测试的方法，它有多个需要测试的案例，每个案例都需要几行代码来测试。不久，测试函数的长度为50行，很难找到故障。(不，这个函数不能合理地分成相当小且易于测试的方法。)

测试方法是专门针对一个方法，而没有其他测试方法，还是可以让多个测试方法涵盖一个函数的不同方面？示例：

@Test
public void testSomeComplexMethod() {
    // lots of code
}

// or

@Test
public void testSomeComplexMethodAspect1() {
    // a little code that just tests aspect 1
}

@Test
public void testSomeComplexMethodAspect2() {
    // a little code that just tests aspect 2
}

Answer 1

在苏特中有几种测试方法来测试单个方法的行为是完全可以的。事实上，我强烈建议您这样做，除非可以使用某种数据驱动的测试来测试功能(例如，请参阅NUnit的TestCase属性)。

示例类似于您的示例，只使用不同的命名约定：

@Test
public void someComplexMethod_BehavesLikeThis_WhenTheseConditionsApply() {
    // a little code that just tests behavior 'like this' given 'these conditions'
}

以正切的方式离开：

(不，这个函数不能合理地分成相当小且易于测试的方法。)

我很难相信这是真的。函数本身可能很难拆分，但底层代码几乎总是可以被提取到单独的实体中，这些实体可以更容易地进行隔离测试--将原来的函数转换为更多使用新部分的“协调器”。

Answer 2

单元测试的伟大之处在于，如果给定的测试失败，您将确切地知道出了什么问题。

在更高级别的测试中，您没有这个特性--它们有其他目的。

每个单元测试都应该有一个并且只有一个失败的原因(在同样的情况下，您可能需要多个断言来检查这个原因)。如果可以在多个点修改目标函数，并使相同的测试失败，则应尝试拆分测试。这就是突变测试的目的。

国家统计局：

如果您的单元测试框架具有类似PHPUnit的@covers注释这样的特性，那么您应该使用它来确保您正在用测试来精确地覆盖您所期望的情况。

Answer 3

拥有多个测试的另一个好处是，您可以将公共功能分解为所谓的实用函数。

通常，经过几次测试后，您会发现它们都在执行相同的设置，并为条件设置相同的属性。但条件的数值会有所不同。

其结果是，当考虑到这些共性时，最终只需将不同的条件传递给实用程序函数来处理设置。

这有两个效果。

第一，它回答了关于如何测试测试代码的老问题。实用程序函数被重用，因此会自动测试。如果所有的测试都失败了，问题可能在函数或SUT的设置中。如果只有一个失败，它就是在测试本身或您试图测试的行为中。

第二，在噪音较小的情况下，您的代码更干净，意图更明显，测试更易于阅读和维护。

您想要做的任何设置都不会改变测试，因此不需要任何参数，都会进入设置例程。

最后，当测试需要单独的设置时，我将测试组分成不同的类，这是因为您测试的是不同的东西。