感觉有点迷茫了

看了一篇《程序员为什么不写单元测试 》的文章
http://www.javaeye.com/topic/97693?page=1
感觉有点迷茫

我是比较喜欢TDD的开发模式的，但问题是我经常用不到，也许是我开发的项目都比较小的关系（至少我认为是这样，都是SSH的，没有EJB的），

我的开发模式更多时候是这样的：
先看业务，然后从DAO到SERVICE再到WEB，再看下一个业务，如果有现成DAO可以利用就用，没有就再写一个DAO然后SERVICE然后WEB,这样下来后先测试，如果有BUG了在针对这个BUG对其底层DAO开始进行JUNIT。

问题是BUG毕竟是少数，所以按照TDD的开发模式，感觉就是比我这样要慢

实在很迷茫

我现在也是只写dao的junit，感觉效率要高一点。毕竟一步做到TDD不是那么容易的事，当然主要原因还是程序员自身没有这要的习惯（我个人先检讨一下）。

你没有重构，
当你重构之后会发现dao只有三个。。++

虽然我对自己写的代码质量很有信心，不过每次我添加一些单元测试的时候，总是能够发现一些代码的bug。说实话，编写单元测试的确会影响开发的速度，但是想对于提高的代码质量和将来的维护成本，已经非常划算了。

完善的单元测试用例可以保证需求的变化，LZ做的项目也许比较小，但应该也有需求变化的时候，这时候单元测试就显示出好处了。

刚开始接触TDD，感觉有点迷茫，主要是断言感觉用不顺手，不太清楚如何灵活应用。
例如，我要测试的目标方法返回一个ArrayList，其每个元素均为一个pojo对象，这时我用这样的断言：
assertNotNull(retList);
assertEquals(2,retList.size());
这样基本可以确定我的目标方法是否返回一些值了，但我如何确定retList中的元素就是我想要的pojo呢？有没有通用的办法对返回值中的内容进行深入测试呢？
请。

这是因为你还没有进行重构，当你进行了重构，你如何保证你所修改后的代码是正确的、可行的。这个时候测试用例就显得非常重要，它可以检验出你代码修改后可能出现的Bug(当然测试用例写得足够好)。
利用TDD开发的话，是先写测试，后写实现代码。在写测试用例的时候，可以对你要实现的代码的功能及细节都会有比较清晰的了解。这样写出来的代码，质量也要高一点。

这个好办：
ArrayList expectedList = new ArrayList();
expectedList.add();//加入你所期望的pojo.
assertEquals(expectedList,retList);//当然，你的POJO要重写equals(Object o)方法。

如果你无法确定List里面元素的顺序，可以使用Set

谢谢abu的建议。
不过这种办法对我来说不太实用，要知道返回的ArrayList里的pojo数目是不定的，由数据库中的记录决定，而且很多pojo构造还是很复杂的，手动构造不太现实。
目前我只做到assertEquals(num,retList.size())，如果返回了期望的num个pojo，我就认为程序没有问题了。实际上如果这一步能通过，一般情况下也确实不会有太大问题。

不得不说一句，TDD真得是个好东西。最近具体实践了一把，我的做法是先根据设计写出接口，然后写测试方法，然后写它的业务实现方法，保证测试通过，然后适当重构。当业务实现方法有改动时，马上运行测试方法，看看有没有副作用。这样写出的后台代码可靠性比起以前大大地增强了，错误很少，前后台联调的时候，后台代码十分的让人放心。
不过，我想我的测试应该属于集成测试了，因为测试方法里都是通过DAO实际操作数据库，我觉得测试时还是操作数据库比较习惯和放心。集成测试也罢，单元测试也罢，达到测试目的就好了。
当然，我对单元测试的理解和应用还很肤浅，需要慢慢积累。

hashcode我一直在用。。。