是否可以将TDD与图像处理算法一起使用？

Question

最近，我参与了一个使用TDD (测试驱动开发)的项目。该项目是一个用Java开发的web应用程序，虽然对web应用程序may not be trivial进行了单元测试，但也可以使用mocking (我们使用了Mockito框架)。

现在我将开始一个项目，在这个项目中我将使用C++来处理图像处理(主要是图像分割)，我不确定使用测试驱动开发是否是一个好主意。问题是很难判断分割的结果是否正确，同样的问题也适用于许多其他图像处理算法。

所以，我想知道的是，这里是否有人成功地将TDD与图像分割算法(不一定是分割算法)一起使用。

Answer 1

您在问题中描述的图像处理测试发生在比您将使用TDD编写的大多数测试更高的级别。

在真正的Test Driven Development过程中，在向软件添加任何新功能之前，您将首先编写一个失败的测试，然后编写使测试通过、清洗和重复的代码。

这个过程会产生一个很大的Unit Tests库，有时测试的LOC比函数代码还多！

因为您的分析算法具有结构化行为，所以它们非常适合TDD方法。

但我认为你真正问的问题是“我如何去执行一套针对模糊图像处理软件的Integration Tests？”你可能会认为我在吹毛求疵，但这种单元测试和集成测试之间的区别确实切中了测试驱动开发的核心。TDD过程的好处来自于单元测试的丰富支持结构。

在您的案例中，我会将集成测试套件与web应用程序的自动化性能指标进行比较。我们想要累积执行时间的历史记录，但我们可能不想显式地使单个性能较差的执行(可能受到网络拥塞、磁盘I/O等影响)的构建失败。您可以围绕测试套件的性能设置一些宽松的容差，并让Continuous Integration服务器生成每日报告，为您提供算法性能的高级概述。

Answer 2

至少，您可以使用这些测试进行回归测试。例如，假设您有5个特定分割算法的测试图像。您可以通过代码运行这5个图像，并手动验证结果。正确的结果会存储在磁盘上的某个位置，以后执行这些测试时，会将生成的结果与存储的结果进行比较。

这样，如果你做了一个破坏性的改变，你可以捕捉到它，但更重要的是，你只需要经历一次(正确的)手动测试周期。

Answer 3

每当我进行任何与计算机视觉相关的开发时，TDD几乎都是标准实践。你有图像和你想要测量的东西。第一步是手动标记图像的一个(大)子集。这将为您提供测试数据。这个过程(为了完全正确)然后将你的测试集分成两部分，一个“开发集”和一个“验证集”。您需要重复开发周期，直到您的算法应用于开发集时足够准确。然后在验证集上验证结果(这样您就不会在开发集的某些奇怪方面过度训练。这是最纯粹的测试驱动开发。

请注意，在开发像这样严重依赖算法的软件时，您正在测试两个不同的东西。

1. 你会在你的软件中发现常见的bug。这些可以使用“普通的”测试技术来测试你的算法的性能，为此你需要一个上面概述的系统。

根据(1)，程序可以是无bug的，但根据(2)，则不完全是。例如，一个非常简单的图像分割算法是这样说的：“图像的左半部分是一段，右半部分是另一段。根据(1)，这个程序可以很容易地实现无bug。它是否满足您的性能需求则是另一回事。不要混淆这两个方面，也不要让一个方面干扰另一个方面。”

更具体地说，我建议您首先开发算法，然后在算法中使用TDD (而不是代码！)也可能是软件的其他要求，作为单独TDDevelopment过程的规范。在繁重的开发下对一些相当复杂的算法中的小的临时助手函数进行单元测试是浪费时间和精力的。