Not to mention that GUIs, algorithms, stored procedures and a lot more other types of architectures are impractical to write, if at all, using TDDs approaches.
I never saw a way that could convince me to use it in such cases.
Algorithms are certainly testable with TDD though. In fact, they're probably the easiest thing to test. Maybe I don't understand what you mean by algorithm, but things that can be expressed mathematically (sorting, searching, decision trees) are very straightforward to test. Tests can even be reused to verify multiple algorithmic approaches to the same problem.
I mean using TDD to specify:
- memory layout of the internal data structures
- O() access times
- cache friendliness
- concurrency
I see how one can test them in a unit test approach with whiteboard design and such, but not in a "write test, fail, write code, success" cycle that is usually sold on conferences.
As far as improving performance characteristics, the argument is that unit testing helps indirectly by improving awareness of the behavior of your system. Having a good idea of where there aren't bugs will let you be more aggressive in refactoring to improve things like performance characteristics.
Sun Tzu:
If you know your enemies and know yourself, you will not be imperiled in a hundred battles... if you do not know your enemies nor yourself, you will be imperiled in every single battle.
...if it's not clear, you are your code and bugs are enemies. It's all about mitigating risk through better understanding of your code base.
It's sort of like enabling the feedback of a REPL to any language. Why wouldn't you write a test case to test the O() access time of a function ahead of time? Or test the memory layout of a data structure?
Seems to me those are great examples of tests I would write to help me flesh out the results I want, before I go and implement it. They help one specify _exactly_ what they want.
Because asymptotic limits are a lot easier to verify analytically than empirically. You can, of course, easily test the actual performance characteristics under specific conditions, but that's different than testing the asysmptotic limit.
Of course, TDD doesn't preclude analytically verifying those things that can be analytically verified.