junit java代码测试框架(50分)

最近参加了一个java的web方面开发的团队。
我现在有个想法，把主要逻辑封装在bean中，
再由servlet或jsp表现出来。
用bean封装主要逻辑，没什么新鲜。
只是这次我想在，代码的测试上动点脑子。
想采取junit测试框架包，在代码开发过程，
实施持续自动测试，以期望提高代码的可靠性。
如果大家还不清楚junit是何物可去 http://www.junit.org/index.htm
下载最近版本和相应文档。
中文介绍的一篇文章见
http://www.csdn.net/Develop/article/11%5C11865.shtm
Junit的文档我大致是看明白了，但想问一下这里哪位有实际
使用经验，具体效果如何。因为效果会如何，我心里还没底。
不过就项目的前期准备而言，我似乎嗅到了一些不太良好的味道...

支持！

关注

曹大哥，真的想跟你学习学习，！

jUnit这个东西，重要的在于管理，而非编程。jUnit是一种所谓单元测验。XP理论认为，
你写代码之前，应该写出你的test Case. 我在项目中用到了这个jUnit.实际使用中效果
没有完全发挥。这应该是由于没有贯彻xp的管理思想。我们是在写完一个bean之后，再
写这个test Case的，并且如果需要作修改，没有先修改testCase,再去修改代码。由于
客户不断催促，情急之下就会直接改代码，用人眼测试一下是正确的，就发布了。这导致
最后jUnit TestCase和实际class脱钩。后来能够跑的testCase不足50%了。
jUnit真的是个好东西。你看，当你看到小绿条规律的向前跳动，100%完成的时候，心情
真的很欢畅。因为我可以确定我的代码是正确的，我从来没有感觉这么放心过。
但是有了好工具，而没有好管理，只会带来更加重的灾难。
要想把jUnit用好，我总结几个教训：
1,项目必须良好组织，有强有力的项目spec指引，再开发之前做好screen design ,db design
等等文档，不然你没有办法开始写testCase.如果连Unit的单位都没有，哪儿来的UnitTest?
2,TestCase必须有一定的粒度。你必须决定，哪些是应该被unit test的，哪些是不需要的。
我们采用的是很小的粒度，每一个dbClass都有一个对应的testClass.最后发现这样的粒度是
有问题的，因为往往testCase写的比被测试的class代码都长，而我们的dbClass本来就都是
一些机械的操作。后来我们认识到这种基本的class是应该采用生成机生的。就算需test的话，
要的话，这种机械的classTest本身也应该自动化。
UnitTest的粒度应该以Unit为单位。比如说，认为Order是一个Unit,那么整个操作过程会包含
几个步骤，place order, order approve, order parse, generate Outbound Job,这是一个
“商业逻辑”,TestCase就应该按照这个商业逻辑来写。
3,修改代码，必须严格按照spec更改的流程来做。如果spec不更改，screen design 或者 db design不更改，
你的已经经过unitTest的程序绝对不能改。必须先改UnitTestCase再来改程序。xp编程的精髓之一
在于，确保你的每一行代码都是有价值的，是经过深思熟虑的。而写testCase这件事情就是这样
一个必要的思考过程。
UnitTest在老外的project中，好像总是和CVS一起使用。jBoss有一个功能就是自动跑unitTest
每天晚上他帮你跑所有的unitTest,第二天早上你来一看，好，报告已经发到你的email box里了。
哪些case没有通过，就可以了如指掌。（这个功能是通过ant来做的）如果testCase不写好，
怎么能做到这样呢？
其实我也是UnitTest的初学者，学习一些先进的open source的开发，应该会更有益处。
欢迎大家一起讨论！

接受答案了.