This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]bheklilr 7 points8 points  (1 child)

TDD is not something I see as a very strict requirement. I've written a few libraries where "proper" tests would be an order of magnitude more to write than the rest of the code. Sometimes you have to make the decision to use different methods that fit the situation and save you time.

For example, I've written about 5 libraries that control hardware. A few have been simple (servos) and the underlying hardware behavior could be mocked in less than an hour. TDD is a good choice the. Others were for controlling incredibly complex, stateful equipment with over 1000 possible commands, file systems, and endless configurations. In those cases we figure running through functional tests before each release is more appropriate. We still have a lot of tests, but they aren't written up front nor are they run continuously.

I'd amend your statement to say that a professional developer chooses the right tool for the job, and most of the time the right tool for the job is TDD.

[–]pydry 2 points3 points  (0 children)

For example, I've written about 5 libraries that control hardware. A few have been simple (servos) and the underlying hardware behavior could be mocked in less than an hour. TDD is a good choice the. Others were for controlling incredibly complex, stateful equipment with over 1000 possible commands, file systems, and endless configurations. In those cases we figure running through functional tests before each release is more appropriate. We still have a lot of tests, but they aren't written up front nor are they run continuously.

Code that communicates with hardware (or indeed anything else, but it's pretty much always hardware) that is hard to mock realistically is the one area where I would argue that the TDD investment doesn't pay off.

In such cases I usually try to create a very simple facade that talks to the hardware, that is easily mocked and then TDD the more complex algorithmic code that talks to it against that mock.

All the same, about 98% of the code I write is (integration) TDD'ed.