测试驱动开发（通常是敏捷）的这种局限性在实际上是否相关？

在测试驱动开发（TDD）中，您从次优解决方案开始，然后通过添加测试用例和重构来迭代地产生更好的解决方案。该步骤应该很小，这意味着每个新解决方案都将以某种方式位于前一个解决方案的附近。

这类似于数学上的局部优化方法，例如梯度下降或局部搜索。这种方法的一个众所周知的局限性是它们不能保证找到全局最优值，甚至不能保证找到可接受的局部最优值。如果您的起点与所有可接受的解决方案之间有很大范围的不良解决方案，则无法到达此目标，该方法将失败。

更具体地说：我正在考虑一个场景，在该场景中，您已经实现了多个测试用例，然后发现下一个测试用例将需要一种完全不同的方法。您将不得不放弃以前的工作，然后重新开始。

这种想法实际上可以应用于所有以小步骤进行的敏捷方法，而不仅仅是TDD。TDD与局部优化之间的拟议类比是否存在严重缺陷？

这种方法的众所周知的局限性在于它们不能保证找到全局最优值，甚至不能保证找到可接受的局部最优值。

为了使您的比较更加恰当：对于某些问题，迭代优化算法很可能会产生良好的局部最优，而在其他情况下，它们可能会失败。

我正在考虑一个场景，在该场景中，您已经实现了多个测试用例，然后发现下一个测试用例将需要一种完全不同的方法。您将不得不放弃以前的工作，然后重新开始。

我可以想象现实中可能发生这种情况：当您以某种方式选择了错误的体系结构时，您需要从头开始重新创建所有现有的测试。假设您开始在操作系统A上以编程语言X实现您的前20个测试用例。不幸的是，要求21包括整个程序需要在无法使用X的操作系统B上运行。因此，您需要放弃大部分工作并使用语言Y重新实现。（当然，您不会完全放弃代码，而是将其移植到新的语言和系统上。）

这告诉我们，即使使用TDD时，也要事先进行一些总体分析和设计是一个好主意。但是，对于任何其他类型的方法也是如此，因此我不认为这是固有的TDD问题。而且，对于大多数现实世界中的编程任务，您只需选择一种标准体系结构（例如编程语言X，操作系统Y，硬件XYZ上的数据库系统Z），并且可以相对确定地使用了迭代或敏捷方法（如TDD）不会把你带入死胡同。

引用罗伯特·哈维（Robert Harvey）的话：“您不能通过单元测试来发展架构。” 或pdr：“ TDD不仅可以帮助我达到最佳的最终设计，还可以帮助我减少尝试次数。”

所以实际上你写的是

如果您的起点与所有可接受的解决方案之间有很大范围的不良解决方案，那么您将无法到达那里，并且该方法将失败。

可能会变成事实-当您选择错误的体系结构时，很可能无法从那里获得所需的解决方案。

另一方面，当您事先进行一些总体规划并选择合适的体系结构时，使用TDD就像在可能会达到“全局最大值”（或至少足够好的最大值）的区域中启动迭代搜索算法一样。 ）在几个周期内。

我不认为TDD有局部最大值的问题。正如您已经正确注意到的那样，您编写的代码可能会出现，但这就是为什么要进行重构（在不更改功能的情况下重写代码）的原因。基本上，随着测试的增加，如果需要，您可以重写对象模型的重要部分，同时通过测试保持行为不变。测试有关系统的不变事实，因此需要在局部最大值和绝对最大值中均有效。

如果您对与TDD相关的问题感兴趣，可以提及我经常想到的三个不同的问题：

1. 该完整性问题：有多少检查是必要的，以完整地描述一个系统？“按实例编码”是描述系统的完整方法吗？

2. 该硬化的问题：无论测试接口，需要有一个不变的接口。测试代表不变的真理，切记。不幸的是，对于我们编写的大多数代码，这些真相根本是未知的，充其量仅是面向外部的对象。

3. 该测试损害的问题：为了使断言可测试的，我们可能需要编写代码欠佳（少高性能，例如）。我们如何编写测试，以使代码尽可能地好？

编辑以解决评论：这是通过重构为“ double”函数排除局部最大值的示例

测试1：当输入为0时，返回零

实现方式：

function double(x) {
  return 0; // simplest possible code that passes tests
}

重构：不需要

测试2：当输入为1时，返回2

实现方式：

function double(x) {
  return x==0?0:2; // local maximum
}

重构：不需要

测试3：当输入为2时，返回4

实现方式：

function double(x) {
  return x==0?0:x==2?4:2; // needs refactoring
}

重构：

function double(x) {
  return x*2; // new maximum
}

用数学术语描述的就是我们所说的将自己涂在角落。这种情况几乎不是TDD独有的。在瀑布中，您可以收集并倾倒数月的需求，希望您可以看到全局最大值，然后才能意识到下一个山坡上还有一个更好的主意。

区别在于在敏捷环境中，您从未期望过此刻是完美的，因此您已准备好抛弃旧的想法并转向新的想法。

对于TDD更具体，有一种技术可以防止您在TDD下添加功能时发生这种情况。这是转换优先权前提。TDD有一种正式的方法供您重构，而这是添加功能的一种正式方法。

@Sklivvz 在回答中令人信服地指出该问题不存在。

我想指出这并不重要：一般而言，尤其是在敏捷开发（尤其是TDD）中，迭代方法的基本前提（以及存在的理由）不仅是全局最优，而且局部最优也没有。众所周知。因此，换句话说：即使这是一个问题，也没有办法以迭代的方式来解决这个问题。假设您接受了基本前提。

TDD和敏捷实践能否承诺提供最佳解决方案？（甚至是一个“好的”解决方案？）

不完全是。但这不是他们的目的。

这些方法简单地提供了从一种状态到另一种状态的“安全通道”，并认识到变化是耗时，困难和冒险的。两种做法的重点是确保应用程序和代码既可行，又被证明可以更快，更定期地满足要求。

... [TDD]反对允许添加未经证明可满足要求的软件的软件开发 ...肯特•贝克（Kent Beck）因开发或“发现”了该技术而倍受赞誉，他在2003年表示，TDD鼓励简单设计并激发信心。（维基百科）

TDD致力于确保每个“大块”代码都满足要求。尤其是，它有助于确保代码满足预先存在的要求，而不是让要求受不良代码驱动。但是，它不保证实现以任何方式都是“最佳”的。

至于敏捷流程：

工作软件是进度的主要衡量标准。在每次迭代结束时，利益相关者和客户代表都会审查进度并重新评估优先级，以优化投资回报率（Wikipedia）

敏捷并不是在寻找最佳解决方案 ; 只是一个可行的解决方案-目的是优化ROI。它承诺工作的解决方案更快，而不是以后 ; 不是“最佳”的。

但是，那还可以，因为这个问题是错误的。

软件开发的最佳目标是模糊的，不断变化的目标。要求通常是不断变化的，并且到处都是秘密，这些秘密只会在充满老板老板的会议室里出现，这使您很尴尬。解决方案的体系结构和编码的“内在优势”是由您的同龄人和您的管理上级主管的分歧和主观意见来分级的-他们都不会对优质软件有任何了解。

在最起码，TDD和敏捷实践承认的困难和尝试优化的两件事情是客观的，可衡量的：。工作v未-工作和迟早v以后。

而且，即使我们将“工作”和“更快”作为客观指标，您为它们进行优化的能力也主要取决于团队的技能和经验。

您在努力产生最佳解决方案时可能会想到的事情包括：

• SOLID原则
• 干净的代码
• 设计模式
• 雇用熟练和经验丰富的人...

等等..

_{这些问题是否真的产生了最佳解决方案，这将是另一个要问的大问题！}

到目前为止，没有人添加的一件事是您所描述的“ TDD开发”是非常抽象和不现实的。就像在数学应用程序中，您正在优化算法，但是在大多数编码人员从事的业务应用程序中却很少发生。

在现实世界中，您的测试基本上是在行使和验证业务规则：

例如-如果客户是30岁的不吸烟者，有妻子和两个孩子，则溢价类别为“ x”等。

您将不会迭代更改溢价计算引擎，直到很长时间才正确-几乎可以肯定，当应用程序处于活动状态时；）。

您实际创建的是一个安全网，以便为特定类别的客户添加新的计算方法时，所有旧规则都不会突然中断并给出错误的答案。如果调试的第一步是创建一个测试（或一系列测试）以在编写代码以修复错误之前重现错误，则安全网甚至会更加有用。然后，在一年的时间里，如果有人不小心重新创建了原始错误，单元测试甚至在代码签入之前就被打破了。是的，TDD允许的一件事是，您现在可以放心地进行大型重构和整理但这不应该是您工作的重要部分。

我认为这不会妨碍您。大多数团队都没有人能够提出最佳解决方案，即使您将其写在白板上也是如此。TDD /敏捷不会妨碍他们。

许多项目不需要最佳解决方案，而那些需要最佳解决方案的项目将在此领域中花费必要的时间，精力和精力。像我们倾向于构建的所有其他事物一样，首先要使其运行。然后加快速度。如果性能如此重要，则可以使用某种原型进行此操作，然后利用通过多次迭代获得的智慧来重建整个事情。

我正在考虑一个场景，在该场景中，您已经实现了多个测试用例，然后发现下一个测试用例将需要一种完全不同的方法。您将不得不放弃以前的工作，然后重新开始。

这可能发生，但是更可能发生的是担心更改应用程序的复杂部分。没有任何测试可以在这方面产生更大的恐惧感。TDD并具有一组测试的好处是，您使用需要更改的概念构建了该系统。当您从一开始就提出这种整体式优化解决方案时，很难进行更改。

此外，将其放在您担心优化不足的情况下，您会不禁花时间优化不应有的功能并创建不灵活的解决方案，因为您过于关注其性能。

将诸如“局部最优”之类的数学概念应用于软件设计可能是骗人的。使用这样的术语使软件开发听起来比实际要量化和科学得多。即使代码存在“最佳”，我们也无法对其进行度量，因此也无法知道是否已达到目标。

敏捷运动实际上是对人们认为可以使用数学方法来计划和预测软件开发的一种反应。不管好坏，软件开发更像是一门工艺，而不是一门科学。