java - Struts2 动作 - 测试它与否？

Question

我目前正在开发一个使用 Struts2 框架的项目。我们使用单独的组件进行数据库访问，这是经过良好测试的。同时，我们从事的项目有很多未经测试的动作。在大多数操作中，我们至少使用一个 DB 服务调用。因此，一方面，这些操作非常简单。我不确定 - 是否应该为此编写单元测试？

我认为好的做法是始终编写单元测试，但是这些操作非常简单，我现在承受着来自管理层的巨大压力。那么，是否重要 - 让 Struts2 动作没有单元测试？

Answer 1

以下是编写单元测试的三个主要原因。

• 它可以帮助您知道您的代码现在可以工作。
• 当将来添加或更改功能时，它有助于保护您的代码免受回归错误的影响。
• 如果您在编写代码之前编写单元测试，它会以一种非常好的方式关注您的设计过程——阅读 TDD 以了解更多关于这样做的好处。

所以问问自己这三个编写单元测试的原因是否适用于这里。如果所有三个问题的答案都是“否”，那么请考虑编写单元测试并将它们保存在代码库中的成本。将此成本与可能的收益进行比较。对是否应该编写单元测试做出明智的决定，并准备好向你的经理捍卫这个决定。

但是不要有一个先入为主的观念，即“单元测试总是好的，对于每个班级”。并且不要携带相反的概念——“单元测试总是不必要的”。两者都不是真的。

Answer 2

我和在 Guice 和 Google Wave 工作的Dhanji Prasanna在同一个阵营。它不是关于 100% 的覆盖率，而是关于编写有价值的测试，以帮助开发和防止代码回归的方式为正确的组件提供正确的反馈。

对于我的一个 Struts2 应用程序，我们有非常非常复杂的数据验证要求。数千。我们使用 struts2-junit-plugin 通过 Spring 3 IoC 和 Struts2 验证以及用于填充具有许多不同数据场景的模拟请求的自定义机制在其集成上下文中测试动作类。这些测试在开发过程中和作为维护工具都是非常宝贵的。

但是对于我们一些更简单的操作，与编写它们所花费的时间相比，我认为没有多少价值。但是，如果它们非常简单，它们也不会花费太长时间来编写。

我还看到过 100% 覆盖率概念导致 100% 的类为他们编写了轻率、毫无价值的测试。为了我的钱，我投票赞成预先确定测试将提供最大价值的领域，并专注于做好这些领域。

Answer 3

必须为函数编写单元测试可能会出现问题，但无论如何，将来可能会在 Actions 中进行验证，这样可以很好地测试它。测试动作所花费的时间必须一点点，我建议这样做，你的应用程序中的每一层都必须有一些功能，如果不是不必要的，并且必须审查架构。