测试应该写到什么程度

       在JavaEye做完session后，看到一些网站的意见，普遍认为做的东西太简单，写的过程太繁琐。那么TDD到底到什么程度才好。

       我自己的意见是
       1 单元测试，所有的逻辑都要覆盖到。
        2 集成测试，也就是Acceptance Test,至少要有所有的正常流程。

        在petsoar这个例子里，首先我认为单元测试没有多，集成测试多了一个。当时主要的目的是演示Selenium的用法。Selenium-Remote-Control这个东西我也是第一次用，所以多写了一个。

        那很多人认为做的时间太长了，没办法，一来要演示清楚，二来出了点故障，三来水平有限。

测试多是写得不够，
很好有人写得过头吧。

说简单到未必，Robert Martin的那个bowling kata例子也和你演示的差不多。
虽然自己从来都做不到，但我很同意单元测试要覆盖所有逻辑，不过单元测试做在业务层应该会好些吧，像演示中测试最终的报价，总觉得没有必要去检查view的页面，直接用junit测试Order不是更好，估计是为了演示Selenium才这样做的吧。
总的来说，我觉得那天最后的演讲不错啊，有意外也很正常嘛，谁在实际项目里没碰到过意外呢。

P.S.本来IDEA4以后我就不用了，看了演示觉得IDEA的代码提示功能不错，也许该再装一个看看。老是用eclipse有时也很没意思。

虽然帖子比较老了，可是还是挺有价值的。

没有真正理解tdd

测试是描述需求的。

把你的需求用测试描述出来，你就知道该写多少测试了。

一般来说描述需求的测试称为验收测试，test-first中所指的测试就是这个。
在具体开发过程中，根据关注层次，关注点的不同，要做很多细化的测试，我想lz说的应该是这些吧。