java为什么构造函数/字段中的“new”关键字对于单元测试是不灵活的？

Question

我一直在遵循Guice的一些指导原则，它提到您永远不应该在构造函数或字段中使用new，因为它是不灵活的设计，无法进行适当的单元测试

这是什么意思

还有一个问题，如果我的函数读取一个XML文件并对其进行解析，那么它是一个单元测试的范围，以尝试捕获所有可能的错误输入值？在UI中，我们不为输入验证编写单元测试

Answer 1

从不太苛刻了通常可能是更合适的说法

要点是：为了进行适当的单元测试，有时必须控制“测试中的类”正在使用的对象。当通过调用new()初始化相应的字段时。。。那么你就无法控制这个领域了。（好吧，你可以使用字节码操作工具，比如PowerMock；但尤其是在编写你自己的代码时：那么你绝对不会使用PowerMock；使用它的需要表明你放弃了一个糟糕的设计。句号）

然而，当您使用依赖注入时，单元测试可以将该字段的模拟对象传递到被测试的类中

但请注意：这不仅仅是关于“适当的单元测试”A）初始化业务逻辑和B）执行其“业务”的业务逻辑之间存在本质区别。这是两种不同的责任，当你不清楚这种分离时，你的产品就更难维护和改进

了解这个话题的一个很好的起点是这些videos。每一分钟都值得

编辑：你的评论/问题太离谱了；还有大量现存的材料（比如here、here、或there）。但这里有一句话：合理单元测试的本质是。。。将您的业务逻辑划分为小的、可测试的单元

我的意思是：当你把很多代码放到一个可以做5件不同事情的类中时，编写好的单元测试是很难的。取而代之的是：你为一项责任创建一个单位。在您的上下文中：可能有一个类用于读取XML数据。该类处理XML，并返回不再是XML的内容。然后有另一个类处理第一个类创建的输出

关于第二个问题：这实际上取决于XML的来源。换句话说：产品代码必须能够检测所有类型的不良XML输入。因为您希望您的生产代码能够正确处理所有可能提供给它的输入。因此，单元测试的目标是确保所进行的所有验证都在实际工作。验证XML不是测试代码的工作！单元测试验证您的代码是否履行了合同

现在，您的单元测试将重点放在这一点上：一些测试确保这种XML读取/转换工作正常；其他测试（对XML一无所知）确保进一步的处理工作正常

但正如所说；这是一个非常宽泛的话题，你不应该指望一个简单的答案就能告诉你所有需要做的事情。这个主题需要花费数月的时间学习各种资源，而且。。。练习，练习，练习