理智检查 - 使用JUNIT时对象数量显着增加

我在一个项目中首次使用Junit，我对它强迫我重构代码的方式感到着迷。我注意到的一件事是，为了能够测试代码块，我创建的对象数量正在显着增加。这是典型的吗？理智检查 - 使用JUNIT时对象数量显着增加

感谢，

埃利奥特

来源

2011-10-27 Elliott

什么是“显着”增加？根据我的经验，您为每个“有效内容”类创建一个JUnit类，即foo.java <-> fooTest.java。方法的数量...测试可能相当实际，但这取决于你想要如何谨慎。 – mazaneicha

您是否在谈论测试类，或者有关正常代码中的其他类和对象？ –

也许你可以发布一个例子，发生这种情况？ – Raedwald

是的，这是正常。

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

您可能想了解Single Responsibility Principle。叔叔鲍勃在他的书Clean Code中也有一些重新考虑因素的例子，他在这里触及了这些问题。

当你是单元测试时还有一件事。 Dependency Injection是一个最重要的事情，在构建代码时可以为您节省很多麻烦。（只是为了澄清，DI并不一定会导致你有更多的课程，但它会帮助你的课程更加脱离彼此）

来源

2011-10-28 09:37:03

是的，我认为这是相当典型的。当我开始将测试代码引入遗留代码库时，我发现自己创建了较小的实用程序类和pojos并对其进行了测试。原来的类只是成为一个叫这些小类的包装器。

一个例子是当你有一个方法做一个计算，更新一个对象，然后保存到数据库。

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

您可以创建计算方法返回的计算对象。然后该方法更新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并保存为一个项目。哪个不好。

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

来源

2011-10-28 08:05:32

为什么你的计算器不是静态的？ .calculate（T）。为什么你必须有计算？你能否通过计算的实际结果，无论它是更新方法而不是将其包裹在计算对象中？ –

它可能是静态的，我可以将三条线合并成一条线，但这只是一个例子。原始的calculate（）方法进行计算（可以有多个结果）*和*更新Thing对象，重点是分离两个方法。在你有多个结果的情况下，你需要一个中级课程。以上只是一般技术的说明。 –

取决于您指的是什么样的对象。通常情况下，使用EasyMock或Mockito等模拟框架应该没问题，在这种情况下，仅用于测试目的的附加类的数量应该少得多。如果你指的是你的主要源代码中的其他对象，可能是单元测试正在帮助你重构你的代码，使它更具可读性和可重用性，这是一个好主意，无论如何恕我直言:-)

来源

2011-10-28 08:17:34 aishwarya

理智检查 - 使用JUNIT时对象数量显着增加

回答

相关问题