unit-testing - 单元测试 : DRY vs. 可预测性

Question

在编写单元测试时，我们是否应该以 DRY 为目标，即功能的更改影响尽可能少的代码，我们的可预测性，即代码的操作是微不足道的？基本上，我是在询问创建非常通用且可由多个单元测试使用的辅助方法与仅将测试代码限制为单个单元测试之间的权衡。以具有以下方法签名的工厂为例:

public Node buildNode(String path, String name, Map<String, Object> attributes);

根据提供的参数，生成的 Node 对象会有所不同，因此我们需要测试不同的可能性。如果我们的目标是可预测性，我们可能会像第一个示例中给出的那样编写两个独立的单元测试，但是如果我们的目标是 DRY，我们宁愿添加一个通用的辅助方法，例如在第二个示例中:

EXAMPLE1:
@Test
public void testBuildBasicNode() {
  Node node = testee.buildNode("/home/user", "Node", null);
  assertEquals("/home/user/Node", node.getAbsolutePath());
  assertEquals(false, node.isFolder());
}

@Test
public void testBuildAdvancedNode() {
  Map<String, Object> attributes = new HashMap<String, Object>();
  attributes.put("type", NodeType.FOLDER);
  Node node = testee.buildNode("/home/user", "Node", attributes);
  assertEquals("/home/user/Node", node.getAbsolutePath());
  assertEquals(true, node.isFolder());
}

EXAMPLE2:
@Test
public void testBuildBasicNode() {
  Node node = testee.buildNode("/home/user", "Node", null);
  Node comparisonNode = buildComparisonNode("/home/user", "Node", null);
  assertEquals(comparisonNode, node);
}

@Test
public void testBuildAdvancedNode() {
  Map<String, Object> attributes = new HashMap<String, Object>();
  attributes.put("type", NodeType.FOLDER);
  Node node = testee.buildNode("/home/user", "Node", attributes);
  Node comparisonNode = buildComparisonNode("/home/user", "Node", attributes);
  assertEquals(comparisonNode, node);
}

private Node buildComparisonNode(String path, String name, Map<String, Object> attributes) {
  // Not just a duplicate of the buildNode method,
  // can be more trivial if we only limit it to unit tests that share some common attributes
  ...
}

我对第一个示例(可预测性)的问题是，如果任何功能发生变化(比如 AbsolutePath 应该如何格式化)，它需要在我的所有单元测试中进行更改。我对第二个示例的问题是 buildComparisonNode 感觉也应该进行测试，而且我当然不想开始为测试编写测试。

另外，作为结束语，您会为示例单元测试中使用的文字字符串声明最终变量，还是它们正常​​？

Answer 1

好问题。我以前听说过“单元测试可以是湿的，但不能浸湿......”对于测试的可维护性，重点(或可预测性)是关键。你的团队越大，我认为这对你来说就越重要。另一个需要考虑的事情是，如果有特定的测试帮助代码，它本身可以成为一个 API，所以如果每个人都知道如何使用它可能不是一个坏主意。我的经验法则是，如果我可以在自动重构中使用 IDE 来完成它并且我可以给它一个好名字，我将删除重复项。

一个建议...查看 Test Data Builder Nat Pryce 撰写的关于更易于维护/可扩展的方法的模式文章。