Question

想象一下，我有一个方法：

void Method(bool parameter){
    if(parameter){
        // first case
    } else {
        // second case
    }
}

您首选的单元测试组织方法是什么？

选项1：

void MethodTest(){
  // test first case
  // test second case
}

或

选项2：

void MethodTestFirstCase(){
  // test first case
}

void MethodTestSecondCase(){
  // test second case
}

Answer 1

在这种情况下，我会分别测试这两个。

话虽如此，我并没有教诲“每次测试只测试一件事”的方法。有时候，在同一个测试中测试多个东西只会更加务实 - 特别是如果到达一个终点意味着要经过另一个点，有时可以将两者结合起来。

在这种情况下，你真的要测试两个单独的事物，而不是一个在去另一个事物的路上，所以我将它们分开。

Answer 2

选项2.

您应该在每个测试中只测试一件事。如果它测试不止一件事，也很难给测试一个好名字。

当测试失败时，也应该很容易找到错误，而不使用调试器。如果测试涵盖多个事物，则错误可能是多个位置。

Answer 3

选项2通常更可取。

这样做的好处是，您可以分别在每个测试的单元测试运行器中获得可见性，而不必在出现问题时查看故障发生的位置。

此外，随着您的发展，更容易运行更集中的测试以更快地获得反馈。

Answer 4

使用选项1，如果第一种情况失败，则根本不会测试第二种情况。使用选项2（在大多数单元测试框架中），如果第一种情况失败，第二种情况仍将进行测试。

这使得选项2更优越，因为您可以区分仅第一个案例被破坏的情况和两个案例都被破坏的情况，这使得在出现问题时更容易调试。

Answer 5

我倾向于使用选项3：

[TestClass]
public class When_parameter_is_a {
    setup() {} // arrange
    execute() {} // act
    [TestMethod]
    this_should_happen() {} // assert
    [TestMethod]
    this_should_happen_too() {} //assert
}

[TestClass]
public class When_parameter_is_b {
    setup() {}
    execute() {}
    [TestMethod]
    this_should_happen() {}
    [TestMethod]
    this_should_happen_too() {}
}

然后测试每个部分的所有预期行为。这是一种BDD风格（行为驱动设计）测试，并强调某些上下文中的行为，而不是测试该方法的“实现”。

Answer 6

都不是。

不要考虑测试类的方法，而是考虑测试类所做的事情 - 它提供给其他对象的服务。执行此操作时，您会发现您没有以测试类的方法命名的测试方法。当多个测试练习被测试类的相同方法时，您没有找到测试名称的问题。

Answer 7

我会有一个类（套件）测试，测试被测试类中的所有不同方法。对于特定功能的每个变体，此类（套件）将具有不同的测试方法。这并不意味着您必须在方法中每行代码进行一次测试。您可以根据单个方法确定“特征”的粒度，但它们通常很小。在你的情况下，我会说你有两个“功能”，一个是参数通过测试，另一个是失败时。因此，我至少会对这种方法进行两次测试。通常，每个测试用例只有一个或几个断言。

如何分离单元测试方法？

7 个答案: