当生产功能有数百万个测试用例时，TDD如何工作？ [英] How TDD works when there can be millions of test cases for a production functionality?

问题描述

在TDD中，您选择一个测试用例并实现该测试用例，然后编写足够的生产代码，以便测试通过，重构代码，然后再次选择一个新的测试用例，然后循环继续进行。

我在此过程中遇到的问题是TDD表示您编写的代码仅能通过您刚刚编写的测试。我确切地指的是如果一种方法可以具有例如一百万个测试用例，您能做什么？显然不是写100万个测试用例吗？！

让我通过以下示例更清楚地解释我的意思：

 内部静态List< long> GetPrimeFactors（ulong number）
 {
 var result = new List< ulong>（）; 
 
而（数字％2 == 0）
 {
 result.Add（2）; 
数字=数字/ 2; 
} 
 
 var除数= 3; 
 
而（除数< =数字）
 {
如果（数字％除数== 0）
 {
 result.Add（除数）; 
数字=数字/除数; 
} 
其他
 {
除数+ = 2; 
} 
} 
 
返回结果； 
} 
  

上面的代码返回给定数字的所有素数。 ulong有64位，这意味着它可以接受0到18,446,744,073,709,551,615之间的值！

那么，当生产功能有成千上万的测试用例时，TDD如何工作？ / p>

我的意思是要编写多少个测试用例，以便可以说我使用TDD来实现此生产代码？

TDD中的这个概念表明您应该只编写足以通过测试的代码，这对我来说似乎是错误的，如上面的示例所示？

什么时候足够了？

我自己的想法是，我只选择一些测试用例，例如适用于高频段，低频段等5个测试用例，但不是TDD，是吗？

非常感谢您对本示例在TDD方面的想法。

解决方案

这是一个有趣的问题，与可证伪性

科学史上的经典例子是所有的天鹅都是白色的吗？这个问题。无论您发现多少只白色的天鹅，您都不能说所有天鹅都是白色的这一假设是正确的。另一方面，给我带来一只黑天鹅，我知道这个假设是不正确的。

良好的TDD单元测试遵循这些原则；如果通过，它不会告诉您一切都正确，但是如果失败，则会告诉您假设的错误之处。在那种情况下，测试每个数字并不是那么有价值：一个案例应该足够了，因为如果在这种情况下不起作用，您就会知道出了点问题。

有趣的问题是，与天鹅不同，您无法真正列举出世界上每只天鹅及其所有未来的孩子和父母，您可以枚举每个有限的整数，并验证每种可能的情况。此外，程序在很多方面都比数学更接近于物理，而与物理学更接近，并且在某些情况下，您还可以真正验证陈述是否正确-但在我看来，这种类型的验证不是TDD所遵循的。 TDD正在进行良好的实验，目的在于捕获可能的故障案例，而不是证明事实是正确的。

In TDD, you pick a test case and implement that test case then you write enough production code so that the test passes, refactor the codes and again you pick a new test case and the cycle continues.

The problem I have with this process is that TDD says that you write enough code only to pass the test you just wrote. What I refer to exactly is that if a method can have e.g. 1 million test cases, what can you do?! Obviously not writing 1 million test cases?!

Let me explain what I mean more clearly by the below example:

 internal static List<long> GetPrimeFactors(ulong number)
        {
            var result = new List<ulong>();

            while (number % 2 == 0)
            {
                result.Add(2);
                number = number / 2;
            }

            var divisor = 3;

            while (divisor <= number)
            {
                if (number % divisor == 0)
                {
                    result.Add(divisor);
                    number = number / divisor;
                }
                else
                {
                    divisor += 2;
                }
            }

            return result;
        }

The above code returns all the prime factors of a given number. ulong has 64 bits which means it can accept values between 0 to 18,446,744,073,709,551,615!

So, How TDD works when there can be millions of test cases for a production functionality?!

I mean how many test cases suffice to be written so that I can say I used TDD to achieve this production code?

This concept in TDD which says that you should only write enough code to pass your test seems to be wrong to me as can be seen by the example above?

When enough is enough?

My own thoughts are that I only pick some test cases e.g. for Upper band, lower band and few more e.g. 5 test cases but that's not TDD, is it?

Many thanks for your thoughts on TDD for this example.

解决方案

It's an interesting question, related to the idea of falsifiability in epistemology. With unit tests, you are not really trying to prove that the system works; you are constructing experiments which, if they fail, will prove that the system doesn't work in a way consistent with your expectations/beliefs. If your tests pass, you do not know that your system works, because you may have forgotten some edge case which is untested; what you know is that as of now, you have no reason to believe that your system is faulty.

The classical example in history of sciences is the question "are all swans white?". No matter how many different white swans you find, you can't say that the hypothesis "all swans are white" is correct. On the other hand, bring me one black swan, and I know the hypothesis is not correct.

A good TDD unit test is along these lines; if it passes, it won't tell you that everything is right, but if it fails, it tells you where your hypothesis is incorrect. In that frame, testing for every number isn't that valuable: one case should be sufficient, because if it doesn't work for that case, you know something is wrong.

Where the question is interesting though is that unlike for swans, where you can't really enumerate over every swan in the world, and all their future children and their parents, you could enumerate every single integer, which is a finite set, and verify every possible situation. Also, a program is in lots of ways closer to mathematics than to physics, and in some cases you can also truly verify whether a statement is true - but that type of verification is, in my opinion, not what TDD is going after. TDD is going after good experiments which aim at capturing possible failure cases, not at proving that something is true.

这篇关于当生产功能有数百万个测试用例时，TDD如何工作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！