我目前正在研究一个使用Struts2框架的项目。我们使用单独的组件访问数据库，这已经过很好的测试。与此同时，我们所从事的项目有很多“行动”，但未经过测试。在大多数操作中，我们至少使用一次DB服务调用。所以一方面这些操作非常简单。我不确定 - 单元测试是否应该写入？Struts2行动 - 测试与否？
我认为最好的做法是始终编写单元测试，但这些操作非常简单，而且现在我受到管理方的巨大压力。那么，它是否很重要 - 在没有单元测试的情况下离开Struts2的行为？
以下是编写单元测试的三个主要原因。
所以问问自己，这三个编写单元测试的原因是否适用于此。如果所有三个问题的答案都是“否”，那么考虑编写单元测试的代价，并将它们保存在代码库中。将此成本与可能的收益进行比较。对你是否应该编写单元测试做出明智的决定，并且准备好为你的经理辩护。
但是不要有一个先入为主的观点，即“对于每个班级，单元测试总是很好”。不要提出相反的概念 - “单元测试总是不必要的”。这两个都不是真的。
必须编写函数的单元测试可能会有问题，但无论如何，将来可能会验证的行动，这将是很好的可以测试。 测试操作的时间必须稍微多一点，我建议您这样做，应用程序中的每一层都必须有一些功能，如果不是不必要的并且必须查看该体系结构。
我和Dhanji Prasanna一样在Guice和Google Wave工作。它不是100％覆盖范围，而是关于编写有价值的测试，为正确的组件提供正确的反馈，以帮助开发和防止代码回归。
对于我的一个Struts2应用程序，我们有非常非常复杂的数据验证要求。数千人。我们使用struts2-junit-plugin在Spring 3 IoC和Struts2验证的集成上下文中测试动作类，并使用自定义机制为大量不同的数据场景填充模拟请求。这些测试在开发过程中和作为维护工具都是非常宝贵的。
但是对于我们一些较简单的操作，与花费时间写作相比，我没有看到太多价值。但是，如果它们非常简单，它们也不会花太长时间写出来。
我还看到过100％覆盖率概念导致100％的课程为他们写了毫无思想，毫无价值的测试的情况。对于我的钱，我投票选出了测试将提供最大价值的领域，并专注于做得非常好。
它总是最好的做法，有单位的情况下，如果你有时间，我会强烈建议你去为他们，而且是S2的简单架构准备单位案件真的很简单，旁边你已经有很好的DB层的情况下。 – 2012-04-15 11:58:34
取决于它们的简单程度。取决于是否有集成测试会使单独的操作单元测试变得冗余。取决于现在要做的最重要的事情。 – 2012-04-15 13:00:17