你能说服你的同事写单元测试吗？

我把单元测试的好处都阐述了一遍，可是大家仍然有很多疑虑，其中最主要的是担心写测试会降低开发效率——写测试代码+写功能代码〉〉写功能代码

最终由于这个项目工期很紧，否决了我的建议！

daquan198163 2006-09-28 18:13
根据自己三年多来的开发经历谈些感受：
我觉得最大的阻力还是来自程序员自身
管理层一般不会关心开发方法和技术细节的问题
struts的流行恐怕主要也是技术人员发自内心的认可和推崇造成的吧
毕竟这牵涉到他的切身利益（工作效率、成就感、乐趣。。。）

同样的道理，单元测试和其他敏捷方法也要首先打动技术人员的心，然后想不流行都难
目前的情况与这两种技术本身的特点也有关，单元测试是阳春白雪，struts是下里巴人

我自己的经历就是这样：03年中时，我们经理让我研究一下junit和eclipse
那时候我用struts和jbuilder用的正爽，瞟了一眼觉得eclipse太简陋了（其实是自己被jb这种傻瓜相机惯坏了）
junit就更无法接受，那时觉得程序员写业务代码天经地义，写测试就是自虐
于是就丢在一边不再看了（可是如今，这两样东西已经是我工作中最重要的工具了）

daquan198163 2006-09-28 18:48
每次看到缺少测试的代码以及还在不停制造这种代码的程序员，我就会感叹前几年走的弯路：

04年我经历了一个项目，20人在客户现场开发，开发到后期时，整个项目就像一座沙子堆起的城堡，稍有不慎就会跨塌
于是，程序员们开始变得消极、焦虑、易怒、神经质。。。。（更年期？？ ）

消极体现在：不愿意修改bug，不愿意改代码以满足用户新的需求
焦虑：担心刚刚修改的代码会破坏已有功能，对下一个版本能否正常工作毫无信心，梦到测试人员发现其大量bug
易怒：经常对测试mm发火，私下里诅咒客户，抱怨别人弄坏了自己的程序
神经质：系统偶尔出现奇怪行为就胡乱猜测，改了不该改的地方导致更多奇怪现象出现

那段日子简直不堪回首，是对程序员身心的双重折磨

daquan198163 2006-09-28 19:06
自从单元测试（连带着轻量级架构和敏捷）走进我的世界，我发现我变得快乐了
编成不再是一件痛苦的事——至少不那么痛苦了——反而增添了很多乐趣和满足感

勇气：单元测试是自动化的回归测试，她让我对自己的代码充满自信，每一个测试就像攀岩者钉在峭壁上的一个楔子，没有了程序衰退的担心，于是我可以大胆的重构、积极的拥抱变化；

快速反馈：每写一段代码，我都可以在几秒钟之内看到他的运行效果，免去了打包、部署、重起server以及在一堆日志里找结果的工作，开发的效率极大提高；

测试驱动设计：通过编写测试可以准确的理解需求、发现问题、发现接口，在不知不觉间做出最合理的设计；

文档：测试是最好的详细设计文档，不会过时、可运行。
daquan198163 2006-09-28 19:31

前面我提到，很多人最主要的是担心写测试会降低开发效率——写测试代码时间+写功能代码时间〉〉写功能代码时间
对于这个问题，论坛里以前有人讨论过了，marting也说明过，大致的意思是：如果软件开发的主要工作是敲键盘的话，那个命题是成立的。

事实大家都知道，这个时间只占很小比例，但毕竟也是多用了，那么在哪儿又节省了呢，答案就是快速反馈。
快速反馈：每写一段代码，我都可以在几秒钟之内看到他的运行效果，免去了打包、重新部署以及在一堆日志里找结果的工作；

写测试3+写代码3+跑测试看结果1=7
写代码3+打包2+重新部署10+用ie访问程序2+在一堆日志里找结果并确认5=22

我一点也没夸张，那个was5重新部署一次真的很慢，有时还需要重起服务

单元测试 应该另外有人来写。

1.自己带头做
2.邀请别人和你双人编程

先要自己起带头作用，并真正给他体会到单元测试带来的便利，于是他高兴都来不及了，我就是这么干的，让他接连好几天说单元测试真好：）哈。。。搞得我都不好意思了。。。：）

我们公司把业务逻辑都写在action里面，面向对象工作都没做好，更何况写单元测试呢……

某些架构下的单元测试非常困难。所以要想单元测试就必须先重构。由谁来重构呢？是个问题。

印象中好象是工期紧张才会用TDD的
连TDD都认为跟不上了的话。。。。跳吧。。

个人感觉还是要从上往下推，依靠个人影响实在是太困难了。
而且某一两个UT往往起不到应有的作用，还是要有一定的覆盖度。
所以要先说服PM和CTO，软的不行可以来硬的。

怎么个硬法?

大项目中推广TDD会存在极大的风险，
小项目中如果不是自上而下推广，我感觉效率也不会很棒。

我首先邀请了我的好朋友在周末和我一起编写了一个简单的日报登记小程序，虽然我有意推广TDD，但告诉他编写这个日报系统是为了简化我们工作中麻烦的日报填写和分析工作。
他同意了我的后一个借口请求，然后我又故意渲染了一下TDD驱动开发，他自然也愿意在一个没有压力的开发环境中尝试新鲜的技术，于是终于将TDD推销给了第一个人。当然推广前，我怀有强大的自信，相信这种让我上瘾的开发方式也会让其他人上瘾，只要她们尝试第一口（说得有点像鸦片。。。）
连续勾引3个以上得核心团队成员，成员就会在组织内部不自觉得推广TDD，并逐渐站稳脚跟。。。推广TDD，我采用了稳扎稳打得战术，呵呵

@.@||~