确定什么是单元测试，什么不是

Question

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

1. 系统必须捕获用户的名字，姓氏，电子邮件地址和可选，邮政地址
2. 名字和姓氏必须是字母
3. 名字和姓氏不能为空
4. 的电子邮件地址必须是有效地址并且是必填项
5. 邮政地址是可选的。

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

1. 包含上述字段以及具有相应的getter和setter这个Java bean
2. 验证注解用于上述领域
3. 一种用于保存用户
4. 用户接口道用于输入用户详细信息。

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

Answer 1

我写的，我讲道理测试“可我这样做不对吗？”。这意味着我不费心去测试其他库提供的 - 只有我的配置。

吸气剂和制定者 - 绝对不是。我使用Eclipse来生成它们，这不值得测试。

验证注解 - 我不会测试他们，例如，正确实施一个空检查，我依靠他们做它在罐子上说什么，但我会测试他们的存在。做正确的领域有他们吗？如果我使用正则表达式配置它们，我会测试正确的正则表达式。

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

我发现用户界面测试确实很难。我曾多次想过“这次我会” - 但比形式更复杂，我放弃了。使用像MVP这样的模式意味着我可以注入事件来测试大部分计算内容 - 但仍然存在与未经测试的UI的连接。我通常最终会对它进行测试，复杂的数据处理以及容易出错的事情。

Answer 2

有一件事我知道TDD，你永远不会写代码。

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

它是最好的，如果你有100％的代码覆盖率。

参考维基百科，你需要如何开始您的项目与TDD - http://en.wikipedia.org/wiki/Test-driven_development