tdd – 没有使用/需要/需要测试驱动开发的*完全可接受*方法的优秀示例是什么？

TDD周期是测试,代码,重构,(重复)然后发货. TDD意味着由测试驱动的开发,特别是意味着理解需求,然后在开发或编写代码之前先编写测试.

我的自然倾向是支持TDD的哲学偏见;我想确信有其他方法现在比TDD更好或甚至更好,所以我问过这个问题.还有其他一些问题表明TDD价格昂贵,难以实施,提出挑战……同意,但有哪些好的选择？

什么是不使用/需要/需要测试驱动开发的完全可接受的方法的好例子？

我可以想到很多不是TDD的方法,但可能比它们的价值更麻烦…它不是道德判断,只是它们的成本高于它们的价值……以下只是作为学习练习可能没问题的东西,但我认为在严肃的生产中不接受的方法,而不是TDD可能包括：

>检查产品的质量 – 专注于提高测试/质量保证的熟练程度可能会有问题,特别是如果您不首先处理需求和开发方面……这种情况的症状包括开发人员所具有的错误分类处理它的许多不同的错误,有必要采用一种形式的分类 – 每个开发周期变得越来越糟,程序员工作越来越多,睡眠越来越少,努力继续死亡游行直到他们被消耗.
>迷信……相信你不理解的事情 – 这将涉及借用你认为已经从某个地方证明或测试过的代码,例如：遗留代码,魔术代码启动程序向导或开源项目,您可以继续修改风暴,将FaceBook Connect滑入用户界面,动态发明一些新的魔术功能(例如使用Twitter API进行混搭) ,GoogleMaps API和Zappos API),向少数人炫耀你的酷“新产品”,然后编写一个简单的“规范”和“测试用例”列表,然后将其转交给Mechanical Turk进行测试. (相信您的产品接下来是Facebook,Twitter或YouTube,可获得额外积分.)

洁净室软件工程是一种方法,一方面听起来非常僵硬,静态,“不敏捷”,几乎与TDD相反,但另一方面它实际上非常相似.例如,它是高度迭代的,就像所有敏捷方法一样.与TDD一样,您首先编写规范,但与TDD不同,规范采用正确性的数学证明形式而不是可执行测试.

TDD周期在哪里

>指定
>代码
>重构
>通过可执行规范证明正确性

洁净室循环是

>指定
>代码
>重构
>证明正确性
>(测试)

我将测试放在括号中,因为它们通常是(半)自动生成的.因此,虽然它们是开发周期的一部分,但它们不是程序员必须完成的工作的一部分.

从我读过的内容来看,洁净室的性能指标与TDD非常相似,这让我相信TDD的真正价值实际上并不在测试部分,而是在思考部分.执行一个实验会很有趣,你可以用一个简单的秒表替换TDD的“红色”部分,它可以锁定你的键盘30秒,然后你就可以编写一个新的方法了.