我的第一个真正意义上的测试

补充一句：
关于Dao测试的问题
1用mock来测试
2直接用真实环境去测试

1。
如果用mock的话，我只是测试我Dao实现是否按照自己预期的效果去测。比如，你mock HibernateTemplate，然后调用find(hsql),好现在的测试结果是，测试的时候将会比较这两次hsql
是否一致，至于hsql是对是错，自己可以再写一个测试专门来负责测试HibernateTemplate.find(hsql)方法。这样对于定位错误是比较有好处的。也就是细分测试的问题
至于第2个网上讨论的也不少，而起本人对此的理解还很普通

呵呵，你不应该认为，我们只提到sql就认为只是为了验证sql，也许还包括其他的，比如，如果你使用乐存储过程，或者触发器之类的。
事实上，我也不认为必须要连接数据库，如果我现在只是为了测我写的SQL对不对，而且我已经有了某一个工具（比如，自己写一个检查SQL语法的工具，当然，你这个工具要能够集成进你的测试代码中），那我像我不会去连接数据库的。因为比较连接数据库还是很慢的，而测试的速度必须尽可能的快。

还是那个原则，有逻辑就采用plain的方式测，mock也好stub也吧，否则，直接进行集成单元测试就OK了。
对与数据库DAO的测试，我也是这样的，有逻辑我就可能mock，否则，就直接连接数据库的测试。

我不知道这样对不对，因此我遵循这样的原则：如果对某个功能不放心，就写相应的测试，否则就OK了。这也是我从without ejb上学到的。的确，以前我一直不知道我该怎么测？该不该测。
，还想，自从遵循这个原则之后没有那么困惑了。

TDD主要是为了开发而设计的
无关的测试都放到后面由QA与监理去作吧

快速完成功能...
快速达到期望的值才是正途
及使手写个return true也是必须的

呵呵，TDD说起来容易，做起来来，但是一旦你习惯了，就习惯了，正如有些牛人所说的那样，TDD容易让人上瘾。
只可惜，很难说服你周围的人跟你一样，去实施TDD，这是我比较困惑，比较郁闷的一点。

什么上瘾?我的同事都退回去不写测试了

当初用EJB才强迫他们用的...

我的同事何尝不是这样，主要是他们写测试而不去遵循基本的写单元测试的原则，不去遵循一定的策略，因此，对与他们来说写测试代码只会是一种额外的工作，耽误时间。
此外，很多同事不愿去了解测试的相关理论，他不去了解为什么这么做，也不去实践，你跟他说了，他也不认同。跟何况，写测试代码对于生手来说的确很难，或者说TDD入门很难，我已经花了很多时间了，还没入门呢，不过我越来越喜欢它了。
还有，TDD的很多好处只有你去实践了，你才会体会的到，否则，你永远都体会不到的，我们同事，大多数对于测试的理解都停留在大学里的古老的软件工程里提到的那点测试而已，而且根深蒂固的认为，测试是测试组的事。他们宁愿花很多时间在调试，在debug，也不愿写测试。
7月份，我在我们的项目中引入持续集成，在引入之前我发了N多邮件，说了N多基本的原则，可是那有怎么样？出错了都邮件通知了，告诉你有bug了，可是没人去改，build几十次了，惟独成功过一次，而且那次还是花了很大的精力去复查的，可是过去几天，有回去了。对我们来说，持续集成有一定的效果，但是收效并不大。我现在面临的最大的困难就是怎么去说服其他人，可是有些事，我想我怎么也做不到。郁闷死了。幸好，我可以自娱自乐。

虽说敏捷强调人性化，不过build这事情是必须严格的。break build是最紧急的状况，新功能、测试、发布、重构、吃饭、回家……一切都要给fix build让步。这需要从制度上严格规定。build status就是项目的健康状况，如果项目是否健康都没人care，说别的都是空谈。

如果了解持续集成的任何一个同行，可能都认可你所说的，可是，如果不了解持续集成，那就不一定像你所说的乐。我不知道国内有多少公司在进行严格的测试？实施持续集成这样的东东。我所知道的很多人，他们宁愿花N多时间去看什么Spring，学其他的大量的开源框架。当然，我并不是说这样不好，但是，我认为，有些基础设施更重要，就像单元测试应该是每个开发人员最基本的工具（实际上这是一把锋利的宝剑）。我并不是说开源不好，事实上我相信我对开源的兴趣并不亚于他们。我难以理解的是，他们去研究开源的东西，却不学开源里面的东西，比如，测试，日构建，持续集成，自动发布等。上面我说过，其实测试入门很难，特别是TDD，可是，从开源社区，我学到了很多，rod也建议，写测试最好从开源代码开始。

我只能说这是人的问题，不是技术的问题，实际上，我认为，技术不是问题，敏捷说的不错，左>右