我一直在遵循Guice的一些指导原则，它提到你不应该在构造函数或字段中使用new，因为它不灵活的设计阻止了正确的单元测试。
这是什么意思？
还有一个问题，如果我的函数读取XML文件并解析它，那么尝试捕获所有可能的错误输入值是单元测试的范围吗？在UI中，我们不会为输入验证编写单元测试。
答案 0 :(得分：6)
从不是苛刻的，经常可能是更合适的陈述。
关键是：为了进行正确的单元测试，您有时必须控制您所测试的＆＃34;类的对象＆＃34;正在使用。当通过调用new()来初始化相应的字段时，您就无法控制该字段。 （好吧，你可以使用字节码操作工具，比如 PowerMock ;但特别是在编写自己的代码时：那你绝对避免使用PowerMock;需要使用它表示你放下一个糟糕的设计。期间）
然而，当您使用依赖注入时，单元测试可以将该字段的模拟对象传递到被测试的类中。
但请注意：这不仅仅是关于＆＃34;正确的单元测试＆＃34;。 A）初始化您的业务逻辑和B）您的业务逻辑正在进行其业务＆＃34;之间存在本质区别。这些是两个不同的职责，当您对这种分离清楚时，您的产品随着时间的推移难以维护和增强。
了解这一主题的一个很好的起点是videos。每个人真的值得每一分钟......
编辑：您的评论/问题相当远;并且有大量现有材料（例如here，here或there）。但是这里有一个一般性的评论：合理的单元测试的本质是......将你的业务逻辑分成小的，可测试的单元！
我的意思是：当你将大量代码推入一个可以完成5个不同事物的类时，那么编写好的单元测试就是 hard 。相反：您为一项责任创建一个单位。在您的上下文中：读取 XML数据可能有一个类。该类处理XML，并返回不再是XML的东西。然后你有另一个类，它适用于第一个类创建的输出。
关于你的第二个问题：这真的取决于你的XML来自哪里。换句话说：您的生产代码必须能够检测所有类型的错误XML输入。因为您希望生产代码正确处理可以提供给它的所有输入。因此，您的单元测试的目标是确保您实施的所有验证实际上正在运行。验证XML的测试代码的工作不！单元测试验证您的代码是否符合合同！
现在，您的单元测试重点关注：一些测试确保此XML读取/转换有效;和其他测试（对XML一无所知）确保进一步处理有效。
但正如所说;这真的是一个非常广泛的主题，你不应该期望单个SO答案可以告诉你需要做的所有事情。这个主题需要花费数月时间研究各种资源，并且......练习，练习，练习......