单元测试:DRY与可预测性

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

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

2. 建议......查看Nat Pryce关于更易维护/可扩展的方法的测试数据生成器模式文章.