我正在为我的计算机视觉论文编写一款相当复杂的机器学习程序。它运行得相当好，但我需要不断尝试新的东西并添加新功能。这是有问题的，因为当我扩展代码或尝试简化算法时，有时会引入错误。
显然，正确的做法是添加单元测试，但如何做到这一点尚不清楚。我的程序的许多组件产生了一些主观答案，我无法自动进行健全性检查。
例如，我有一些代码，用低分辨率曲线逼近曲线，以便在低分辨率曲线上进行计算密集型工作。我意外地在这段代码中引入了一个错误，并且只有在我的整个程序结果稍微变差时才发现了它。
但是，当我试图为它编写单元测试时，不清楚我该做什么。如果我制作一个具有明确正确低分辨率版本的简单曲线，那么我并没有真正测试出可能出错的所有内容。如果我制作一个简单的曲线，然后稍微改变其点，我的代码开始产生不同的答案，即使这个特定代码现在似乎运行良好。
2019年更新：我已经修复了指向WELC摘要的链接，使用来自Wayback Machine网站存档的版本（感谢@milia）。
此外-尽管知道主要包含其他网站链接的答案是低质量答案:) - 这里是一个链接2019年新版的Google测试和调试ML代码教程。我希望这对未来遇到这个问题的人有所启发。
"那么我并没有真正测试出所有可能出现的问题。"
正确。
单元测试的工作不是测试所有可能出现的问题，而是测试在给定特定输入和期望结果的情况下，你的代码是否做了正确的事情。重要的是确保特定可见的、外部的需求被特定的测试用例满足，而不是每一个可能出现的问题都被防止。
无法测试出所有可能出现的问题。你可以写一个证明，但很难为每个可能性编写测试用例。
明智地选择你的测试用例。
此外，单元测试的工作是测试整个应用程序中每个小部分是否在隔离状态下完成了正确的任务。
例如，你的“用低分辨率曲线逼近曲线的代码”，可能有几个小部分可以作为单独的单元进行测试，这样就能确保整体也能正常工作。
例如，你的“在低分辨率曲线上进行密集计算的代码”，可能有几个小部分可以作为单独的单元进行测试，在隔离状态下执行。
单元测试的目的是创建小的、正确的单元，以后再将它们组装起来。
没有看到你的代码，很难确定，但我怀疑你试图在太高的层次上编写测试。您可能需要考虑将方法分解为更小的组件，这些组件是确定性的，并对其进行测试。然后通过提供返回基础方法（可能位于不同对象上）的可预测值的模拟实现来测试使用这些方法的方法。然后，您可以编写覆盖各种方法领域的测试，确保您具有可能结果的全范围覆盖率。对于小的方法，您可以通过提供代表输入域的值来实现，而对于这些方法所依赖的方法，则可以通过提供返回依赖项的结果范围的模拟实现来实现。
您的单元测试需要采用某种模糊因素，可以接受近似值，或使用某种概率检查。
例如，如果您有一些返回浮点结果的函数，几乎不可能编写适用于所有平台的正确工作的测试。您的检查需要执行近似计算。
TEST_ALMOST_EQ(result, 4.0);
以上的TEST_ALMOST_EQ可能会验证result是否在3.9到4.1之间（例如）。
另外，如果您的机器学习算法是概率性的，则您的测试需要适应它，通过多次运行的平均值，并期望其在某个范围内。
x = 0;
for (100 times) {
x += result_probabilistic_test();
}
avg = x/100;
TEST_RANGE(avg, 10.0, 15.0);
当然，如果对代码进行更改时，数据集上的性能可能会略微提高，但如果性能大幅下降，则表明出现了问题。