单元测试以验证时间复杂度

Question

有没有人使用单元测试来验证代码的时间/空间复杂性？

由于

雨果

Answer 1

这是你提出的一个非常好的观点。当然你使用单元测试。

单元测试主要是测试代码结果的“方式”。您可以测试它是否能够执行它应该执行的操作，并在您希望它失败时进行测试。

时间和空间是两个非常重要的变量，你可能“想要”快速和低空间成本，但程序却反其道而行，那么你就有了一个bug，这就是单元测试的目的，找到错误并解决它们。

单位的一些伪代码测试时间消耗，您可能知道如何解决这个问题，但这是一种相当不错的测试方法：

Unit_Test_To_See_If_X_Takes_More_Than_Y_Seconds(int max_milli_seconds)
{
    int current_millis = getMillis();

    do_operations_on_objects_and_functions();

    int millis_after_executions = getMillis();

    int elapes_millis = millis_after_execution - current_millis;

    if ( elapsed_millis > max_milli_seconds )
      Assert(ERROR);

}

另外，当你考虑它时，你可以进行太多测试吗？不，你不能。测试所有结果是好的，即使你测试“愚蠢”的东西，如果你没有测试结果和一个bug的演变，它是否意味着它不存在只是因为你没有看到它或者你没有测试它？ ：）

Answer 2

可能的解决方案是使用Filip的函数进行1次迭代测试，然后是100次，然后是1000次，然后是10000次（等），并将结果绘制在图表上以确定时间复杂度。或者使用数学来得出每次运行之间的最高因子差异。我不确定你是如何测试空间的。

我认为输出不会是简单的传递或失败，除非现有算法导出最高因子（N ^ 2等）并与之进行比较。

Answer 3

我在调整算法时遇到了类似的问题。我做的是循环它，然后除以循环次数和big-O值。然后，我称之为“q”或“质量价值”。有趣的是，该值或多或少与我预期的一致，而且对于不良参数则略高一些。关键是，如果你看一下big-O的定义，你可以测量主要的“不那么显着”的计算。它们通常是不变的或复杂性较低。就我而言，它有点线性，但仍然无需考虑。

我的建议是，计算这样的质量值。然后你可以看到是否有一个突然加注，表明你的上一次更改的副作用会破坏你的复杂性假设。

Answer 4

虽然时间方面很好地涵盖了Filip和Josh的答案，但空间问题更复杂，因为有问题的代码可能会释放它在完成时使用的任何内存和资源。因此，我猜测单元测试本身对于确定空间复杂性并不是特别有用。你需要一个探针，或者一些其他的监视器，你正在测试你的coude。

我想说在被测试的代码中提供一些原位日志/跟踪将是最简单的解决方案，可能会从发布版本中删除。