Hacker News Reader

Comment by humanrebar | Hacker News Reader

I'm with you on testing GUIs and (mostly) stored procedures. I would add low-level interfaces (hardware, OS, third-party library implementations) to that list.

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.

View on HN

> Maybe I don't understand what you mean by algorithm ...

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.

Unit testing would let you validate the correctness of the code.

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.

TDD doesn't preclude one from doing whiteboard design and thinking things through. It just asks that you write a test case before you write your code.

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.

> Why wouldn't you write a test case to test the O() access time of a function ahead of time?

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.

Testing algorithms is easy, yes, but it's usually not clear that TDD would lead you to design the optimal algorithm.

It would not, but good tests will let you verify the correctness of the algorithm without deploying your software to customers. Which frees you up to try more experimental things without ruining the experience of the users.

Reply on news.ycombinator.com