
Common Misunderstandings about Key Laws of TDD - agnieszkaczapla
http://www.thedroidsonroids.com/blog/key-laws-of-tdd
======
eesmith
I have yet to see a TDD piece describe how to handle the situation where a
current algorithm must be replaced.

Consider Martin's "primes" example, at
[http://www.butunclebob.com/ArticleS.UncleBob.ThePrimeFactors...](http://www.butunclebob.com/ArticleS.UncleBob.ThePrimeFactorsKata)
. Martin is rather chuffed that the implementation takes only 3 lines of code:

    
    
      public class PrimeFactors {
        public static List<Integer> generate(int n) {
          List<Integer> primes = new ArrayList<Integer>();
    
          for (int candidate = 2; n > 1; candidate++)
            for (; n%candidate == 0; n/=candidate)
              primes.add(candidate);
    
          return primes;
        }
      }
    

Where in the Red-Green-Factor do you add tests to verify acceptable
performance across the applicability domain?

For example, Java's maximum integer value is 2147483647, which is also a
prime. The above algorithm tests every integer >= 2 before determining that.
Which is slow.

When do you add a test that PrimeFactors.generate(2147483647) correctly
returns the 1-element List containing 2147483647, and with acceptable
performance?

If you find that the performance is too slow, how do you refactor the existing
code to handle it?

This linked-to page says: "Before touching the production code, we do a single
automated test. Next, we add the simplest possible code which makes it pass."

So, I add 2147483647 as the single test, which fails. What next?

Obviously there are many well-known ways to make that code performant.
However, _all_ of them would require substantial changes the code, which
surely should entail many additional tests, yes?

And just what is the 'simplest possible code to make it pass'?

