确定要单元测试的内容和不要测试的内容答案

【问题标题】：Determining what to unit test and what not to确定要单元测试的内容和不要测试的内容
【发布时间】：2010-11-29 05:43:45
【问题描述】：

我仍在了解测试驱动开发。我对应用程序的用户注册模块有以下要求。

在java中实现上述。我写了以下代码：

问题：上面的哪些代码应该被单元测试覆盖？即 bean 的 getter 和 setter、验证注解的存在、dao 保存用户的能力、UI 中相关表单元素的存在。

【问题讨论】：

请使用适当的技术（例如 Java）标记此内容。
@RPM1984：为什么？这个问题显然是关于单元测试和 TDD 的，答案同样适用于任何其他语言。
@Platinum Azure - 就“我应该/我应该”而言，我同意。但是实际的实现会与技术对技术（例如 UI 测试）有很大的不同。但我想这不是关于如何，所以我收回我的陈述。
因此，John O'Hara 将很难注册，Sarah Wickham-Brown 女士也是如此。（此外，我们还有一名来自印度次大陆的员工，他的名字叫 Gaurav；没有姓氏——或者没有名字。）并且“系统必须捕获……邮政地址”和“邮政地址是可选的”是准矛盾的。
@Platinum, @RPM1984：由于问题提到了 Java（bean、DAO）等，我不确定语言特定标签的重要性。

【解决方案1】：

我为我认为“我做错了吗？”的事情编写测试。这意味着我不会费心去测试其他人提供的库——只测试我的配置。

Getter 和 Setter - 绝对不是。我用 Eclipse 生成的，不值得测试。

用于验证的注释 - 例如，我不会测试它们是否正确实施了空检查，我依赖于它们是否按照它在锡上所说的那样做，但我会测试它们的存在。正确的领域有它们吗？如果我用正则表达式配置它们，我会测试我得到了正确的正则表达式。

另一个例子，如果我用 Hibernate 存储我的 POJO。我不检查Session.save(myObj) 是否正常工作，但我可能做错的事情，例如事务边界和映射配置（所有字段都已保存）等。

我发现用户界面测试真的很难。我曾多次想过“这一次我会”——但任何比表格更复杂的东西，我都放弃了。使用像 MVP 这样的模式意味着我可以注入事件来测试大部分计算内容——但仍然存在与未测试的 UI 的连接。我通常最终会测试它的一些部分、复杂的数据处理以及容易出错的东西。

【讨论】：

【解决方案2】：

就我所知的 TDD 而言，您永远不会先编写代码。

您首先编写一个测试，当您的测试失败时，您编写/生成代码来修复它，然后编写更多测试来破坏您打算实现的功能并为其编写/修复原始代码。

如果您有 100% 的代码覆盖率，那就最好了。

请参阅维基百科，了解如何开始使用 TDD 进行项目 - http://en.wikipedia.org/wiki/Test-driven_development

【讨论】：