在Java EE应用程序上进行单元测试是否有意义？

Question

我听说Java EE单元测试比标准Java应用程序更难。我公司的应用程序测试仍在用户验收测试中。我们验证UI和函数的行为是否符合预期。在Java EE应用程序上进行单元测试是否有意义？如果是的话，有什么好的起点？

Answer 1

当然有道理。

让我猜一下：就贵公司而言，当您对中央组件进行微小更改时，我认为您将一次又一次地重复您的用户验收测试。在我看来，这是一个真正的PITA，也是一个开发团队的优势。

单元测试允许您以一致的方式开发Java EE应用程序的不同层（即视图，业务和模型），此外，它允许您执行regression testing。回归测试的神奇之处在于，在长寿命应用程序中，这为您提供了一种确保新补丁，代码重构或演化不会破坏当前系统行为的方法。如果您使用continuous integration工具，则可以自动完成。

因此，您可以使用jUnit作为示例直接为业务和模型层编写单元测试。这就是Java EE应用程序中的单元测试问题：我们如何处理视图层？

嗯，对于视图层，您可以使用自动化测试工具（例如Apache jMeter）来检查Web应用程序的预期行为，检查数据验证，系统稳定性（使用常规数量编写长测试）用户）和可扩展性（增加和减少并发用户），压力测试等（我知道它不是单元测试，但它可以以类似的方式用于回归测试）。

我认为这是每个软件项目的重要组成部分，我邀请您将其应用到您的某个项目中，并自行比较最终结果。

Answer 2

在服务器上进行单元测试总是有意义的。 Java EE不一定难以进行单元测试。一个很好的起点是代码和应用程​​序的各个层。即开始为持久性编写单元测试，然后为服务编写单元测试等....

Answer 3

Java EE 6的CDI资源注入实际上已经制作用于单元测试;你可以为@Alternative bean换掉@Inject-ed FacesContexts，数据库资源和bean，这些bean具有已知的，可预测的测试行为。

Answer 4

单独在UI级别进行测试是危险的，因为您可以在较低层中存在错误，这些错误在时间的上层MOST中隐藏或补偿。这也意味着当您遇到问题时，您必须首先确定问题是在前端还是后端。

Answer 5

是的，Java EE难以进行单元测试。当你打破一些东西并且两周没有注意到它时，它也很难很多来修复它，因为你从不费心去编写单元测试。

应用程序越复杂，您就越需要拥有良好的测试方案。由于我们讨论的是Java EE，因此可以安全地假设您的应用程序很复杂。