java - 将 JUnit 测试方法放入测试类中是一种不好的做法吗？

Question

考虑一个带有小型库样式静态方法的 Java 类。

将 JUnit 测试方法放在同一个类中是一种不好的做法吗？

我看到了以下优点:

• 作为 self 文档的 JUnit 测试就在方法代码附近
• 很容易将此代码移动到另一个类或包

有什么矛盾，为什么总是将测试代码分开是一种普遍做法？

一个例子:

import org.junit.*;

public class HtmlUtils {
    public static String normalizeBrs(String html) {
        return html.replaceAll("<br\\s*/?>", "<br/>");
    }

    @Test
    public void testNormalizeBrs() {
        Assert.assertEquals(normalizeBrs("hello <br /> world <br>"), "hello <br/> world <br/>");
    }
}

Answer 1

(将 JUnit 测试方法放入被测类中是一种不好的做法吗？)

绝对。

这里的关键原因: single responsibility principle 。一个类、一个方法、编程中的任何东西都应该支持/提供完全一个的责任。

生产代码的核心职责是实现其“生产目的”。

换句话说:业务逻辑就是业务逻辑。没有其他。

任何不属于那个桶的东西......都去了其他地方。

测试就是这样一种“事物”、方面、责任，无论您如何命名。

更典型的方法是为生产代码和测试代码创建不同项目。

当您的生产类是 x.y.Z ... 那么测试类将是 x.y.ZTest；但是尽管它们位于同一个包中，您通常会将它们放在不同的源位置文件夹中。

除此之外:Java 的重构 在 2017 年可以被视为“已解决的问题”。今天将方法移动到不同的类中，或更改包名称非常容易，您(绝对)会这样做不必为此担心。 (如果重构对你来说太危险了，以至于你考虑用测试代码污染你的生产代码，那么好吧:学习如何使用现代工具)

此外，如果您将测试方法放在被测类中，您可能最终会测试内部实现。这不是你应该测试的。您应该针对类 API 进行测试；您的测试应该独立于内部实现。