3 ms·
The Tests Talk – Benefits of TDD
- eesmith 7y agoI'm waiting for the day when a TDD advocacy piece describes how to handle "Substitute Algorithm" refactoring. As a concrete example, consider Robert Martin's prime factors kata at http://www.butunclebob.com/ArticleS.UncleBob.ThePrimeFactorsKata http://www.butunclebob.com/ArticleS.UncleBob.ThePrimeFactors... . Martin write "The final algorithm is three lines of code". However, it's a very slow algorithm. His resulting Java API accepts an integer as input, which is an implicit promise that the algorithm should handle 2^31-1 as an input ... which happens to be prime. But the implementation will take a long time. I want to see a refactoring which adds the test for 2147483647 (or 9223372036854775783 for 64-bit integers), discovers that it fails the test (by taking too long), and then use that to drive the refactoring. It's not hard to think of other complexity issues, like replacing a N^2 sort with N long N, or naive substring search with something like the Knuth–Morris–Pratt algorithm.