半帮手方法

我可能已经在测试代码中看到了更多的情况，在测试代码中，思考通常比常规过程更具程序性。 这肯定是一种测试气味 。 但是，我认为这也是其他代码中常见的反模式。

 function readFile(filename) { 
    // open file and return its string  }  function substituteId(file, id) { 
    const placeholder = 'REPLACE-ME' ; 
    // do global replace of the placeholder with id 
    // return that  }  // call site  const file = readFile( 'foo.txt' );  const substituted = substituteId(file, currentId); 

上面的代码非常完美。 也许我们想要一个通用的工具包，该工具包允许我们打开文件并有时执行替换。 但是，如果两次调用的用法在代码中出现了两次以上，则可能处于丢失抽象级别的情况。

呼叫者想做什么？ 他们是在尝试打开并归档并使用它，然后有时替换某些东西吗？ 还是他们试图获取经过处理的文件？

这里的示例是一个常见的测试示例，其中我们使用预先创建的示例数据来表示标识符可能发生变化的事物的预期结果。 难题是您要么必须进行模糊匹配 ，要么必须在每次变化的字段上尝试匹配实际值。

但是，上述两步协议通常是常见的反模式。

如果您每次都必须做相同的两件事，那么您需要使用辅助方法的两半……显然，这可以扩展到更明显的代码重复程度，但是当每次只有两行时，更容易错过。

有什么解决方案？

如果我说我们应该编写第三个方法来调用前两个方法，那么您可能会打起头来说： “好吧，嗯！” 你会是对的。

但是，该解决方案需要考虑更好的一般情况。

调用代码是否表达了其意图，还是在实现中迷失了方向？

有了上述问题，您就可以快速确定何时需要在呼叫站点进行更多工作。 代码应保持一致的抽象级别。 尤其是测试代码，应该像测试意图那样阅读，而不是像实现该意图所需的75步那样阅读。

也就是说，过度重构测试可能导致不知道发生了什么，但这是另一回事了。

翻译自: https://www.javacodegeeks.com/2020/03/half-a-helper-method.html