目前项目的暴强代码风格 + 把它重构了！

我知道你是好心。没有没有任何别的意思，如果这个让你觉得不舒服，我可以删除。这是真心的。
只是说，不管什么事情，一个结论最好都对应一个适用范围，世界上没有万能的螺丝，也没有放诸四海而皆准的道理。

没什么，就事论事嘛。


对呀，我也想知道到底是什么原因导致它不适用了，什么情况下不适用，所以才让你举个底层应用领域的例子。

我个人也比较看好测试优先（测试优先似乎不能叫tdd），我反对的是神化它，如果能够保证设计的和做的一样，真是世界就清静了。
只能说是yy而已。

哥，建议你读 Pragmatic系列的 《使用JUnit进行单元测试》。里面有一个CROSS（？）标准。
回头我查一下~
你不看还这么理直气壮的。。。




hurricane1026 也许 Kent的《测试驱动开发》会给你点提示



我觉得在 java的 web开发中，对view很难测试。也许将来Ruby on Rails会发展到可以对MVC进行一体化的测试。



我觉得有 单元测试 大部分情况 是比没有要好的多的。



Andrew 在Pragmatic系列中有答案：使用临界值：  max, min, 0 . 1.-1.



我觉得可以。既然你做出来的东西可以通过测试。难道设计的跟做的不一致吗？



哥，测试用例不是这么容易的。  要全面，还要正交。而且有代表性。 
如果因为一个很粗糙的测试用例没有达到你的预期目的，你就把 单元测试弃之不用，
这个是你的损失啊。


还是 写测试的功力问题。对于单元测试高手，他的测试用例完全可以保证合格。


我觉得TDD是一种思想。不仅仅在软件领域。在其他领域也一样。
比如在 游戏对战中，比如魔兽，如果开局发现你的对手是个智力型英雄，你肯定会根据这个来搞个抗魔的装备。
而常规路线也许是你想要弄个加攻的武器。
比如追女中， 要是对方对经济比较擅长，你就可以跟她谈股票，谈经济。常规路线是先吃饭，然后看电影，
最后才发现她喜欢经济。-_-

先想好，这个东西的传入条件是什么，以及结果。然后通过一些步骤的努力，来让你的假设实现。这个就是我认为的TDD.


我觉得一样是可以的。至于怎么实现，就不在这个讨论之内了。单元测试，跟作者的水平有直接关系。




对头，TDD没有人逼着你用。只是TDD 跟RoR一样，很多人用了就不愿意在回到原来的套路了。
我第一用TDD 是在06年底，为同学写一个遗传算法的实现。奇迹般的发现，方法变的设计良好，
以前的种种冗余重复都不见了。而且思路明确，实现简单。开发压力小。而且修改了哪个地方，
红条可以在第一时间提示我。

gigix 已经说了很多。hurricane1026和ddd ，我个人强烈建议你们试用一下TDD。忍住几分钟的
成见之后，你不会失望的。



老抛还是很逗啊。



我觉得gigix的态度一直都是非常认真。我觉得 hurricane1026和ddd，你们应该试一下TDD ——最开始
可能会觉得不习惯，在你写第三个UnitTest的时候，保证你会喜欢上它。—— 梨子只有尝了之后才
知道是什么滋味，不是吗？



哥，人家发表论文，Martin全球演讲，难道大家都是傻子吗？ Martin的那本书，让Kent 唯一看两边的书，
被你一句“经验主义”就给批判了啊？？？
至于Eclipse 的 Extract Method, Move, Rename, Push up , Push Down ,Convert... , Introduce...
这些连半自动化都算不上吗？

你是我哥，我认了，OK？？？


同意

实际经验证明：TDD可以提高软件质量
报告中研究的4个案例，1个来自IBM，3个来自微软。每个案例研究都对比了开发同一个产品的两个团队，他们使用同样的开发语言和技术，处于同一级别的管理之下，唯一不同之处在于：一个团队使用TDD，另一个不用。在开发过程中，这些团队都不知道自己处于研究之下。IBM案例中的团队在开发设备驱动程序，微软的团队在开发Windows、MSN和Visual Studio的相关应用。

这还是泛泛之谈，vs，msn，用用ttd肯定没有问题。windows团队估计可比整个中国任何一个软件公司都大。里面某个项目用ttd没问题。ibm的设备驱动程序什么样子的驱动程序呢？怎么个工作方式呢？

我很好奇，设计OS kernel的实现，或者类似与大量os kernel里的操作的时候，如何TDD。不是说TDD不好，一般的应用软件，用tdd确实好（虽然人的惰性导致推广起来有难度，我自己就懒得写100%的测试代码）
但是不知道大家知不知道不可测理论，也就是观察者对被观察的对象造成影响，那么涉及到os kernel的某些features，测试程序是否会对其造成影响呢？当然我没有具体的经验只是揣测。说到测试，方式很多，但是自动化测试能够覆盖多少代码，什么方面的代码，值得商榷。

H公司就在做，我们的一个团队就在指导他们做
你之所以好奇然而还没有答案，可能只是因为你好奇的程度并不是很高

H公司只是写一个用到kernel mode对某些函数或者内存空间的应用？还是在开发kernel的features？

跳过口水，我个人用过tdd，虽然不是特别适应，但是感觉不赖，就算不能test drive dev，至少有unit test跟着，心理踏实。但是总有些东西非常难以测试，kernel mode的问题一般需要kernel debug，用并口线，我就好奇，大拿们是想什么招解决这个玩意的automated test的呢。

跳着快速浏览一遍。说说我的一点经历吧：
1.在一个日本外包项目中第一次使用junit做tdd开发，结果没按时完成。不过，用详细设计书和review在功能细节上提供保障，日本人这方面是没有什么纰漏的，他们好像也不是很重视tdd。

2.在一个项目中使用单元测试服务层，结果浪费大量时间后，由于设计和实现反复改动而完全废弃了测试代码
---
通过以上的痛苦教训，我感觉，tdd是有时间成本的，而且对代码质量提高不明显。除非时间特别宽裕，技术底蕴积累的比较多，开发人员工作经验丰富的团队才有可能，在浮躁的环境实施不现实

------补充-----
关于测试用例。我想可以用测试人员的系统测试来代替：
1.首先设计人员写出功能的详细需求，再写详细设计，然后按照详细设计编码。同时，测试人员按照详细需求和设计写出测试用例，然后对所有文档进行评审。
2.编码，自测，代码走查，集成测试，系统测试，让测试人员把所有功能点都检查之后就等于做了一遍单元测试了。