程序员为什么不写单元测试

对TDD来说，我自己已经开始习惯了这种编码方式，编码前写一个TODO－List，然后写TestCase，接着才有代码，再重构，最后有了代码。这样写相对于传统的编码来说，免去了一大堆Debug的时间，不然写完一堆代码，然后手动一测试，一堆Bug和非预期行为，接着就是无穷无尽的折磨人的debug时间来了。

继续遇到了一个志同道合者了。

我只是一个推崇XP方法的学生而已。遇到JUnit之后发现编码体验变的和之前完全不同故有所感悟而已。

不会写单元测试的人比会写的人要便宜

少一点Why，大道理说服不了多少人。多说一点How，多给一些实际的例子！

例如，我这里很多程序依赖几十个DAO，而且很多DAO中实际是包含很多业务逻辑的。请问这个单元测试如何做？很多Service中只是逐一调用这些DAO(transaction script)，对Service的单元测试的意义有多大？

例如这是一个DAO的sql语句(ibatis)

稍微复杂点的逻辑可能会写个测试，说是测试，其实就是加个main方法，而且这个main方法最后还可能被无情的删除。

如果说测试是一种责任，那么我不得不说一下我们公司，注释啊，同志们！
公司的底层数据库操作是自己的框架，再加一层service，那个注释写的，跟没写一样，看起来真叫累，所以现在我写代码注释都打的非常详细。

如果说不写测试是不负责任，那么不写注释的同志们就该拉出去痛打一顿！

测试的环境很难做。
比如和数据库相关的测试。由于有多张关联表，要模拟这个数据环境很麻烦。也许比业务逻辑的代码还要多。