如何通过单元测试产生高效的代码？

Question

我参加了一个TDD编码Dojo，我们尝试在简单问题上练习纯TDD。然而，我发现单元测试中出现的代码并不是最有效的。现在大多数情况下都没问题，但是如果代码使用量增加，那么效率就成了问题。

我喜欢代码从单元测试中出现的方式，但是有可能通过进一步的测试使效率属性出现吗？

这里是一个红宝石的例子：素因子分解。我遵循纯粹的TDD方法，使得测试一个接一个地验证我的原始验收测试（在底部注释）。 如果我想让generic prime factorization algorithms之一出现，我还能采取哪些步骤？为了减少问题领域，我们假设我想要实现一个quadratic sieve ...现在在这种精确的情况下，我知道“最优算法，但在大多数情况下，客户端只会添加一个要求， x”的时间，特定的环境。

require 'shoulda' 
require 'lib/prime' 

class MathTest < Test::Unit::TestCase 
    context "The math module" do 
    should "have a method to get primes" do 
     assert Math.respond_to? 'primes' 
    end 
    end 
    context "The primes method of Math" do 
    should "return [] for 0" do 
     assert_equal [], Math.primes(0) 
    end 
    should "return [1] for 1 " do 
     assert_equal [1], Math.primes(1) 
    end 
    should "return [1,2] for 2" do 
     assert_equal [1,2], Math.primes(2) 
    end 
    should "return [1,3] for 3" do 
     assert_equal [1,3], Math.primes(3) 
    end 
    should "return [1,2] for 4" do 
     assert_equal [1,2,2], Math.primes(4) 
    end 
    should "return [1,5] for 5" do 
     assert_equal [1,5], Math.primes(5) 
    end 
    should "return [1,2,3] for 6" do 
     assert_equal [1,2,3], Math.primes(6) 
    end  
    should "return [1,3] for 9" do 
     assert_equal [1,3,3], Math.primes(9) 
    end   
    should "return [1,2,5] for 10" do 
     assert_equal [1,2,5], Math.primes(10) 
    end     
    end 
# context "Functionnal Acceptance test 1" do 
# context "the prime factors of 14101980 are 1,2,2,3,5,61,3853"do  
#  should "return [1,2,3,5,61,3853] for ${14101980*14101980}" do 
#  assert_equal [1,2,2,3,5,61,3853], Math.primes(14101980*14101980) 
#  end 
# end 
# end 
end 

和天真的算法，我创造了这个方法

module Math 
    def self.primes(n) 
    if n==0 
     return [] 
    else 
     primes=[1] 
     for i in 2..n do 
     if n%i==0   
      while(n%i==0) 
      primes<<i 
      n=n/i 
      end 
     end 
     end  
     primes 
    end 
    end 
end 

编辑1从第一个答案来看，我想我并不清楚我的初始描述：性能测试是不是是我单元测试的一个标准部分，它是一个新验收测试编写回答特定要求从客户端。

编辑2我知道如何测试执行时间，但它似乎从简单的算法转移到优化的算法是一个巨大的步骤。我的问题是如何使最优代码emerge，换句话说：你如何分解从平凡代码到最优代码的迁移？ 一些人提到这是一个问题的具体方法：我提供了一个示例问题，我不知道如何继续。

Answer 1

• TDD为正确性和非回归并专注于单元测试
• 仿形为性能，这是一个功能测试问题。

我也用来参加每周的TDD编码Dojo，我们尝试了一些实验，看看它是否可以用于算法目的（找到更好的算法，找到没有明显的算法）或者内置的性能限制。

当道场使用TDD，我们尽量遵守规则之下

• 写打破现有的代码最简单的测试（或支付的啤酒，如果它不破码）
• 编写最简单代码，使测试添加新的测试

之前加入测试

也重构测试之前通过

重构代码（使用代码味道）

根据这些规则，我们比第一眼就可以看到更多的实验空间。我们可以调整最简单的定义并添加代码异常来考虑效率（基本上来说：如果我们想到几种实现某些东西的简单方法，它们更喜欢效率最高的方法，并且如果我们知道一些更高效但仍然简单的方法 - 算法比我们的代码中使用的是一种气味）。

总的来说，结果是TDD本身不适合预测整体代码的性能，并且从开始就实现高效的代码，即使使用TDD和重构，我们成功实现了对代码的更好洞察，并且可以增强它以获得更好的可读性和避免了一些明显的性能瓶颈。试图在测试级别的代码中插入性能约束通常是灾难性的（我们得到的代码和测试太复杂，经常代码破坏或者更改太复杂）。

其中一个原因是TDD我们通常使用非常小的测试集（最简单的测试失败）。另一方面，真正的数据集会出现更多的性能问题，并且与上述规则相吻合。性能测试，即使在正式的单元测试中，也是更相似的功能测试。通常的优化策略包括添加缓存，或者考虑到实际数据分布的某些属性，或者当某些小的优点特性对性能有很大的负面影响时，关联用户故事中的更改。所有这些都不能真正在TDD中内置，但更有可能在分析代码时发现。

我相信表演目标基本上是一个功能测试的问题。

Answer 2

不，你不应该尝试。单元测试测试的正确性，而不是效率 - 迫使他们测试效率是一种过早优化的一种形式。

Answer 3

在您的单元测试代码中，您可以添加测量目标代码已用时间的代码。伪代码将如下所示：

start_time = date_time_now(); 
Math.primes(1000); 
stop_time = date_time_now(); 
assert stop_time-start_time < target_execution_time; 

某些单位文本框架可能已经有可用的时间，您可以参考。这使得额外的样板代码无需测量时间。

此外，elapsed_time只是要使用的“效率”指标的一个示例。其他要测试的指标包括cpu_time，吞吐量，传输的输入/输出字节等。

Answer 4

进行效率测试。您给出了这样的要求：“对于给定的环境，该功能的运行时间少于”x“时间。” 编写一个测试执行时间的测试。如果你通过了测试，那么如果失败了，就不需要进一步的代码增强，通过分析和微观选择或算法增强来加快速度。

我不得不同意BlueRaja性能测试不应该是单元测试的标准部分，尽管如果重视性能，它可以帮助保持它在桌面上。

Answer 5

单元测试通常检查零散的功能正确性。

你当然可以添加时序约束到一个单元测试，但你可能很难有时间与技术无关的方式表达出来（例如，O（N LN N）。

而且，仅仅因为你可以写一个坚持要在一定时间内交付结果的单元测试并不意味着该单元的编码器必然能够找到一个达到这种效果的算法（当然，他可能无法想到如何正确实现功能，

如果你这样做，我会建议隔离功能测试和性能测试 然后至少你可以告诉你代码在你deci之前是否工作表现确实很糟糕。

Answer 6

我起初虽然这不起作用，你需要一个比TDD更大的飞跃，而且我会说至少你的测试会在你重写你的代码时帮助你。

但是，您应该尝试让我们知道。虽然我还没有做到，但我认为你的下一个测试应该是的一次性能测试。这显然是这个时候的要求，所以为什么不以同样的方式继续下去。

我认为你可以编写一个能够在任何平台上可靠运行的基础。你需要一些基础设施，以帮助你，但它可以看起来像：

TEST: should be faster than O(n^2) 
setup: baseline_time_for_10 = time_of(f(10)) 
100: assert time_of(f(100)) < baseline_time_for_10^2  
etc. 

我一直想做到这一点，但还没有一个项目有合适的机会。让我们知道怎么回事。

Answer 7

TDD不能帮你推导算法 - 如果那是你的问题。这是其中一个不适合TDD优势的利基领域（利基：与成千上万框架/库中的企业软件相比）。

没有阻止你继续使用TDD - 你可能会写一个性能测试，但是你的目标规格是什么？如果有可能减半你的规格呢？这些问题不能在不分析代码的情况下以正确的方式进行回答。去测试驱动不会回答这些问题;最多它会给你一个安全网，以检测你是否破坏了现有的代码。

例如你可以用TDD来实现排序，但是你找到一个新算法或者到达一个像quicksort这样的现有高效算法的机会是黯淡的。除非你知道算法设计的原则，并有意识地通过它的方式。

更新：支持证据。 http://www.markhneedham.com/blog/2009/12/10/tdd-big-leaps-and-small-steps/ 还有一些 - 但他们就像讨论reddit。自以为是的不受支持的免费为所有人。不发布这些。