我目前正在开发一个使用Struts2框架的项目。我们使用单独的组件进行数据库访问，经过了很好的测试。与此同时，我们工作的项目有很多未经测试的动作。在大多数操作中，我们使用至少一个DB服务调用。所以一方面这些动作非常简单。我不确定 - 是否应该为此编写单元测试？
我认为好的做法总是写单元测试，但这些操作非常简单，我现在面临来自管理方面的巨大压力。那么，是否关键 - 在没有单元测试的情况下离开Struts2动作？
答案 0 :(得分：6)
以下是编写单元测试的三个主要原因。
因此，请问自己，编写单元测试的这三个原因是否适用于此处。如果所有三个问题的答案都是“否”，那么请考虑编写单元测试的成本，并将其保留在代码库中。将此成本与可能的收益进行比较。做出明智的决定，决定是否应该编写单元测试，并准备好向经理辩护。
但是，不要带有一个先入为主的观念，即“每个班级的单元测试总是好的”。并且没有相反的观念 - “单元测试总是不必要的”。两者都不是。
答案 1 :(得分：1)
我和Guice以及Google Wave工作的Dhanji Prasanna同一个阵营。它不是100％的覆盖率，而是编写有价值的测试，以有助于开发和防止代码回归的方式为正确的组件提供正确的反馈。
对于我的一个Struts2应用程序，我们有非常复杂的数据验证要求。数千人。我们使用struts2-junit-plugin在Spring 3 IoC和Struts2验证的集成上下文中测试动作类，并使用自定义机制来填充具有大量不同数据场景的模拟请求。这些测试在开发期间和作为维护工具都是非常宝贵的。
但是对于我们的一些简单操作，与写入它们所花费的时间相比，我看不到回报的价值。但是，如果它们非常简单，它们也不会花太长时间来写。
我也看到过这样的情况：100％的覆盖率概念导致100％的课程为他们编写了轻率，毫无价值的测试。为了我的钱，我投票确定了测试将提供最有价值的领域，并专注于做得非常好。
答案 2 :(得分：0)
必须为函数编写单元测试可能会有问题，但无论如何，将来可能会在有效的操作中进行验证可以测试。 测试操作所花费的时间必须是一点点，我建议这样做，应用程序中的每个层必须具有一些功能，如果不是必须的话，必须检查架构。