探讨在业务型目比较实际的推行ut, cc,selenium

感觉类库框架型的代码，写多少单元测试，写得多么白盒都是值得的，不过分的，没有附上单元测试的类库，最好不要用。
如果要找参考，Spring的测试用例就不错，它演示了一个框架类库该有的测试方法和测试粒度（谢天谢地，Spring的测试用例都比较实际，不会机械的生成所有方法的测试用例，而是有目的性进行测试）

而在业务代码中，要推动所有人在MVC各层都进行单元测试真的有点无力感，幸亏有selenium这个好东西作集成测试。使用它，依旧可以达到持续集成的效果，让CC有活干。

准备在公司项目里推如下规则，各位老大，看看是不是可行：
1.运行CC
2.类库框架代码程序员必须编写单元测试
3.业务代码程序员必须编写selenium集成测试
4.业务代码中的重要类重要逻辑程序员应编写单元测试用例
5.qa人员最后根据需求,编写验收测试用例并模拟现场环境,手工测试

分步走吧

主要要老板支持,领导理解

可以简化为推行TDD亚，老板一听只要一步，说不定比较好理解~
简化词太多了，ut=unit test?
cc=curise control?

我觉得你要搞清楚——并且更重要的是带你的老板一起搞清楚——你做这些事情的价值到底是什么。你不能泛泛地说“提高代码质量”，这个不行的，第一没有量化的东西说明到底提高了多少，第二你不知道提高了质量到底有没有意义。比如说你可以问问老板，你想不想每周搞一个release launch，如果老板说想，那么你没有continuous integration你是很难weekly release的；有了ci以后，如果没有完整的functional test suite你的ci也是摆设的；有了functional test以后，如果没有unit test你的程序员写程序会很痛苦的。事情就是这样，你首先抓住根本的价值是什么，然后再一点点去推进实践，去看哪些实践是需要的哪些是不需要的。如果你说不出要获得什么价值，那么所有实践都是不需要的。

公司跑Rational全套，所以这个纯粹是自己希望在团队里面捣弄的，没有老板这个角色。
  前几天徐八叉介绍了Thoughtworks 一个很过瘾的Agile toolset集成项目 --Buildix（http://buildix.thoughtworks.com）， 集成了
subversion,
trac ，除收费的jira外最喜欢的trac(http://projects.edgewall.com/trac/)，
还有CC，以及集成的用户管理，项目管理小工具小命令行
似乎是我这种小团队快速开小灶的好选择。

不过它是整个Linux ISO一起发布的，还要找台全空的机子来安装或者搞vmware.

那就很没有意思了。

trac是个好东西，我最初就是因为要用trac才去学python的

也不尽然压，不尝试怎么能有真实体会、有发言权以及发现你的需要？光道听途说是没有说服力的。只有实践完乐，才能进行合理选择。

所以，多说不如动手，先动手，回来再总结会比较好些，在这里问可不可行，恐怕是很难获得满意的答案乐。

当然，我不是说，就按你自己想的一整套就全一股脑整上试试，怎么循序渐进，那就是你的本事乐，实践完乐你回来写篇东西，肯定值得交流。

不然的话，只能是听到像我这样不痛不痒的话乐：）

现在Team里先找志同道合之人,一个个争取。
种子只能自己发芽，园丁只能使环境变的有利于成长。

赞同一下gigix的话。
另外，仅仅引入各种工具，或者增加n多规定、流程，都无法提高代码质量。
经过这么多年，感觉要提高代码质量只有去找好的开发者。
教育人真难啊。