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

Question

TDD 周期是测试、编码、重构、(重复)然后交付。 TDD 意味着由测试驱动的开发，特别是意味着在开发或编写代码之前先了解需求，然后先编写测试。

我的自然倾向是支持 TDD 的哲学偏见；我想确信现在还有其他方法比 TDD 效果更好甚至更好，所以我问了这个问题。还有其他问题表明 TDD 成本高昂、难以实现、存在挑战……同意，但什么是好的替代方案？

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

我可以想到很多不是 TDD 但可能比它们的值(value)更麻烦的方法......这不是道德判断，只是它们的成本超过它们的值(value)......以下只是示例作为学习练习可能没问题，但我发现在严肃的生产和非 TDD 中 Not Acceptable 方法可能包括:

检查产品质量 -- 专注于提高测试/质量保证的熟练程度可能会出现问题，尤其是如果您不首先处理需求和开发方面的工作……这种情况的症状包括错误分类，其中开发人员有许多不同的错误要处理它，有必要采用一种分类形式——每个开发周期都变得越来越糟，程序员工作的时间越来越长， sleep 越来越少，挣扎着在死亡行军中继续前进，直到被消耗殆尽。

迷信……相信自己不懂的东西 -- 这将涉及借用您认为已从某处证明或测试过的代码，例如遗留代码、魔术代码启动向导或开源项目，然后您继续进行修改 Storm ，将 FaceBook Connect 滑入您的用户界面，即时发明一些新的魔术功能(例如使用 Twitter API 的混搭、GoogleMaps API 和 Zappos API)，向一些人展示你很酷的新“产品”，然后编写一个简单的“规范”和“测试用例”列表，并将其交给 Mechanical Turk 进行测试。 (如果您相信您的产品会成为下一个 Facebook、Twitter 或 YouTube，则会获得额外积分。)

Answer 1

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

TDD 周期在哪里

指定

代码

重构

通过可执行规范证明正确性

洁净室循环是

指定

代码

重构

证明正确性

(测试)

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

从我读到的内容来看，Cleanroom 的性能指标与 TDD 的性能指标非常相似，这让我相信 TDD 的真正值(value)实际上并不在于测试部分，而是在于思考部分。进行一个实验会很有趣，在该实验中，您将 TDD 的“红色”部分替换为一个简单的秒表，该秒表会在您编写新方法之前锁定您的键盘 30 秒。