
The Tests Talk – Benefits of TDD - chynkm
https://quii.dev/The_Tests_Talk
======
eesmith
I'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.ThePrimeFactors...](http://www.butunclebob.com/ArticleS.UncleBob.ThePrimeFactorsKata)
.

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.

