浅谈测试驱动开发究竟对不对？

阅读有关TDD的任何提倡，它总是会归结为进行自我测试的论点，没有人反对。从来没有理由在实现之前编写测试。这里是执行之前编写测试没有理由，所以测试驱动开发从根本上就是错误的，因为是倒退。到了2008年下半年，我正在为Windows 7任务栏编写扩展程序。我的工作基本上完成了，最终的应用程序很小，只有几屏代码。我被指示为此编写单元测试，以便经理可以选中一个框。我拒绝了，因为该项目太小了，没有任何单元，将其拆开以添加这些愚蠢的测试，将破坏已经通过所有测试并准备发布的工作的稳定性。

随着谈话的恶化，我的经理告诉我有关“测试驱动开发”的新内容，这时我确保有一条通向退出的明确道路，因为我显然是在与疯子交谈。这是我第一次听到教理。

 测试全部通过后，您就完成了

我见过的每一个TDD倡导者都以同样的空洞信念重复了这个逐字记录。

 设计总是在变化

当时我有20多年的经验，我认识到第一个明显的缺陷。在编码之前编写测试是要记住一句古老的格言：没有战斗计划能够幸免于敌。我工作过的大多数地方都将软件计划视为浪费时间。充其量是他们通过的动作。

在Microsoft，我 多次受到彻底性的惩罚 ，尤其是编写威胁模型时。但是，我总是从需求 和 功能规格入手来计划工作，并且拒绝了那些不想花时间在编码之前进行设计的潜在客户。

但是，即使是最彻底的计划，也可能在启动实施后的几天甚至数小时之内显示出意外的突发事件。客户的设计总是比他们意识到的 还要模糊，即使我尽我所能地勤奋工作，也会有一些我没有想到的事情。

因此，如果我遵循TDD架构，我将不得不不断地回顾我的测试，复习所有测试，并根据我的发现修改它们。而且由于在工作完成或接近完成时编写测试将包括我在实施过程中发现的所有内容，因此事后编写测试更加有意义。

当然很有趣，一遍又一遍地重写这些-照片由Elnur Amikishiyev

 这是TDD对我来说的样子：

1.编写TDD测试

2.开始执行

3.发现意想不到的考虑

4.重写测试

5.继续执行

6.goto3一遍又一遍…

7.(实际上更像项目150)所有测试均通过

8.发送到质量检查

假设，由于TDD，QA部门还没有全部裁员。请注意，上述4在一个大型项目的过程中可能会发生数十次，并且每次重访TDD测试都是 100%的浪费时间。

 老办法更好

1.开始执行

2.发现意外的问题并加以解决

3.在代码完成时、编写测试并运行

4.修复所有错误

5.发送到质量检查

通过这种方法，我在发现冒险之旅之后编写了测试，因此仅将测试写到最终设计中，并且仅根据需求重新进行测试。

(1)质量检查中发现的错误

(2)新功能

(3)发布后发现的错误

老鼠和男人等的最佳计划。因为我们都有……

 盲区

这里的第二个问题是TDD假定开发人员应该编写自己的测试。 这太荒谬了。我已经看过很多次了;该项目对我来说似乎很可靠，我无法打破它，但是其他人可以在不到一分钟的时间内打破它，为什么？

因为我的设计中会出现同样的盲点。

我的脑海只在这里盘旋。没有人会怎么写比“是-否”消息框更复杂的东西而不会遇到这种情况？解决此问题之前，无需编写测试就可以了。无论我在实施之前还是之后编写测试，都存在我没有想到的情况，而这些情况不必是“极端情况”。每个人的工作都需要由其他人根据要求和功能规范进行黑盒测试。

 讨论区

容易想到这样的态度，即在TDD方案中浪费时间重访测试只是增加了收入；所以该项目需要20%到50%的时间，那又如何呢？我得到的报酬多20–50%。但是我不认为这是道德的。坦率地说，这很无聊。

以上就是关于浅谈测试驱动开发究竟对不对的全内容介绍，想了解更多关于软件研发的信息，请继续关注。