All the books which talk about test-driven development (TDD) illustrate it with only very basic examples, less than 100 LOC.

The algorithms I wrote using TDD were larger, but still relatively small in size and complexity.

I'm pretty sure I know a few developers who successfully used TDD on algorithms of a few thousands of LOCs. Anything larger, however, would be broken down to modules, and each module would be unit-tested separately, in isolation from other modules.

I don't have any example of a really large algorithm that used TDD successfully. Does TDD scale well when the complexity of the tested logic increases, or it becomes ineffective, forcing the developers to move to other testing approaches?

A few examples of a complex logic that cannot be reasonably split into multiple modules:

* A lexer for a rather complicated syntax.
* The compiler.
* The rendering engine of a web browser which is in charge of displaying a page based on the DOM and the CSS rules applied to it.
* A simulator of an electrical circuit.
* Regular expressions engine.

---

The question appears in the context of [my answer](https://softwareengineering.stackexchange.com/a/421849/6605) to a question [about the testing of a lexer](https://softwareengineering.stackexchange.com/q/421844/6605). In my answer, I assumed that TDD would work great for someone who develops a lexer from scratch. In the comments, several persons highlighted that my assumption may be wrong.

---

The question is different from [Does TDD really work for complex projects?](https://softwareengineering.stackexchange.com/questions/41773/does-tdd-really-work-for-complex-projects) : there, the question is about enterprise codebases, which include the user interfaces and other things which aren't particularly easy to unit test. My question is exclusively about algorithms, and specifically about the pure ones which have no side effects.