您如何才能对只能修复的bug进行TDD测试？

这是一个示例：我的Web应用程序包含可拖动元素。拖动元素时，浏览器会生成“重影”。我想在拖动时删除“重影”，并为此测试编写了一个测试。

我的问题是，我最初不知道如何解决此错误，而编写测试的唯一方法是在修复它之后。

在诸如之类的简单函数中let sum = (a, b) => a - b，您可以在编写任何代码之前编写一个关于为什么sum(1, 2)不相等的测试3。

在我描述的情况下，我无法测试，因为我不知道验证是什么（我不知道断言应该是什么）。

所描述问题的解决方案是：

let dataTransfer = e.dataTransfer
let canvas = document.createElement('canvas');
canvas.style.opacity = '0';
canvas.style.position = 'absolute';
canvas.style.top = '-1000px';
dataTransfer.effectAllowed = 'none';

document.body.appendChild(canvas);
dataTransfer.setDragImage(canvas, 0, 0);

我不知道这是解决方案。在网上找到解决方案后，我什至无法编写测试，因为我唯一可以知道它是否真正有效的方法就是将这段代码添加到我的代码库中，并通过浏览器进行验证是否达到预期的效果。测试必须在代码之后编写，这与TDD背道而驰。

TDD如何解决此问题？在代码之前编写测试是强制性还是可选的？

当我正确理解您的信息后，找到解决方案后，您甚至无法为“鬼影”示例编写可靠的自动化测试，因为验证正确行为的唯一方法是查看屏幕并检查是否没有鬼影。还有。这给我的印象是您最初的标题提出了错误的问题。真正的问题应该是

• 如何自动测试图形用户界面的某些行为？

答案是- 对于几种UI问题，您没有。当然，可以尝试使UI以某种方式自动显示问题，并尝试实现屏幕快照比较之类的方法，但这通常容易出错，脆弱且不具有成本效益。

尤其是通过事先编写的自动测试进行“测试驱动” UI设计或UI改进实际上是不可能的。您可以通过改进来“驱动” UI设计，将结果显示给人类（您自己，一些测试人员或用户），并征求反馈。

因此，请接受TDD并非灵丹妙药这一事实，对于某些问题，手动测试仍然比自动化测试更有意义。如果您有系统的测试流程，也许有一些专门的测试人员，那么最好的办法就是将案例添加到他们的测试计划中。

TDD如何解决此问题？在代码之前编写测试是强制性还是可选的？

一种方法是应用尖峰解决方案的模拟。

James Shore这样描述：

当我们需要更多信息时，我们会进行一些小型的孤立实验。

基本思想是在弄清楚发生了什么时放下设计工具。一旦有了轴承，就可以再次使用设计工具。

诀窍：将调查中的知识带回到生产代码库中，但不带代码。相反，您可以使用严格的设计技术来重新创建它。

马匹的课程。

编辑：

如果只能用肉眼看到缺陷，如何自动执行测试？

我想提出一个稍微不同的拼写：“如果自动化测试不符合成本效益，那么如何自动化测试呢？”

答案当然是“你不”。而是将您的实现分成两部分-大部分在测试中具有成本效益，而另一部分则过于简单以至于无法破解。

构建软件设计的方法有两种：一种方法是使其变得如此简单，以至于显然没有缺陷-CAR Hoare

因此，在使用第三方代码时，我们将拥有非常薄的代码外壳，可充当第三方库的代理。在测试中，我们用“ test double”替换了该外壳，该外壳可验证协议，而不必担心会产生所需的效果。

为了测试我们的代码与真正的第三方代码的集成，我们依赖于其他技术（可视化验证，技术支持电话，乐观度....）

保留一些演示工件可能很有用，以便您可以在升级第三方库时检查您的假设是否仍然成立。

换个角度来看，围绕UI / GUI的测试相对于验收测试（以功能/业务工作流为中心的测试）可以做得更好。

对于Web来说，我认为诸如selenium webdriver之类的框架有可能接近正确的测试，但是开始的开销可能会很多，这与仅针对单元测试的TDD所见的流程有所不同。 。

专门针对您的情况的部分称为“页面对象模型”（https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html）。通过命名方法/事件/类成员，可以将运行时GUI明确映射到某些代码。

对此的主要争论是开销，并且这种开销通常可以在开发周期的结尾看到。开销是测试需要一些包装程序，这些包装程序似乎会创建重复的工作。

展望未来，这将取决于团队和业务的成本/收益，因此进行讨论以确定期望和观点可能是一个有益的话题。

鬼像是什么样的？如果创建了一种已知颜色的虚拟ui，则将可拖动组件放在哪里？如果存在重影，是否会存在特定的颜色。

然后，该测试可以测试是否存在幻像图像的颜色。

这样的测试将是合理的持久性和可行性。