Java 健全性检查-使用JUNIT时对象数量显著增加

我第一次在一个项目中使用Junit，我被它迫使我重新构造代码的方式所吸引。我注意到，为了能够测试代码块而创建的对象数量正在显著增加。这是典型的吗

谢谢

---

艾略特是的，我认为这是相当典型的。当我开始将测试代码引入遗留代码库时，我发现自己创建了更小的实用程序类和POJO，并对它们进行了测试。原始类只是成为调用这些较小类的包装器

例如，当您有一个方法进行计算、更新对象然后保存到数据库时

public void calculateAndUpdate(Thing t) {
  calculate(t); // quite a complex calculation with mutliple results & updates t
  dao.save(t);
}

您可以创建calculate方法返回的计算对象。然后，该方法更新Thing对象并保存它

public void calculateAndUpdate(Thing t) {
  Calculation calculation = new Calculator().calculate(t); // does not update t at all
  update(t, calculation); // updates t with the result of calculation
  dao.save(t); // saves t to the database
}

所以我介绍了两个新对象，一个计算器和计算。这允许我测试计算结果，而不必有可用的数据库。我还可以对更新方法进行单元测试。它也更实用，我喜欢：-）

如果我继续使用原始方法进行测试，那么我必须对计算udpate进行单元测试，并保存为一项。这可不好

---

对我来说，第二个是更好的代码设计，更好的关注点分离，更小的类，更容易测试。但小班的数量却在增加。但是总体复杂度会下降。

取决于您所指的对象类型。通常，您可以使用类似EasyMock或Mockito的模拟框架，在这种情况下，仅用于测试目的的额外类的数量应该非常少。如果您在主要源代码中引用其他对象，可能是因为单元测试正在帮助您重构代码，使其更具可读性和可重用性，这是一个好主意

一般来说，类和方法越小/越专注，就越容易理解和测试它们。这可能会产生更多的文件和实际的代码行，但这是因为您添加了更多的抽象，使您的代码具有更好/更清晰的设计

你可能想读一读这本书。Bob叔叔在他的书中也有一些重新分解的例子，叫做where，他正好触及了这些要点

---

在进行单元测试时，还有一件事。是最重要的事情之一，在构建代码时，它将为您节省很多麻烦。（为了澄清一下，DI并没有必要让您拥有更多的类，但它将帮助您的类彼此更加分离。）

什么是“显著”增加？根据我的经验，您为每个“有效负载”类创建一个JUnit类，即foo.java fooTest.java。测试中的方法数量可能相当多，但这取决于你想要的谨慎程度。你是在谈论测试类，还是普通代码中的其他类和对象？也许你可以发布一个发生这种情况的示例？为什么你的计算器不是静态的。计算（t）。你为什么要计算呢？你能不能把计算的实际结果传递给update方法，不管它是什么，而不是包装在计算对象中？它可以是静态的，我可以把三行合并成一行，但这只是一个例子。原始的calculate（）方法进行计算（可以有多个结果）并更新Thing对象，重点是分离这两个方法。如果有多个结果，则需要一个中间类。以上只是一般技术的说明。