Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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... . 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'?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: