I personally tend to believe one can get many of the benefits of TDD (without actually adhering to TDD), by:
- Writing both the caller and the callee code at around the same time (definitely not more than 24 hours apart).
- And use that to influence the design of the interface (objects, method calls and parameters).
- For a component requiring a complicated algorithm/code, strongly consider implementing in a simpler but correct algorithm first, even if it is less efficient (or stupid, or only works in a narrower situation).
- A very simple testing method would be running both algorithms and comparing their results.
- Once a bug was discovered (by any means) in one part of the code, that part of code deserves to be tested much more aggressively. This means doing more sophisticated tests than TDD would call for. (based on the reasoning that bugs occur in clusters)
TDD seems to require you to have a pretty clear understand of what function you plan to implement, or what requirements you plan to satisfy by implementing the code. In some situations, there is simply too little understanding of the problem. This would have called for a Spike solution. Within the scope of this Spike solution, TDD can be applied because the problem has been narrowed down to a managable level. Once a few Spikes have been finished, each covering some aspects of the original problem, one can start working on the full solution, and applying TDD at that point might be feasible because of the improved understanding.
After reading the page more carefully,
While it should be possible to test
most kernel functions in a "testbed"
test driver, the really "juicy" stuff
like interrupt handling, process
dispatching or memory management are
probably not unit-testable.
--- from http://wiki.osdev.org/Unit_Testing
They are clearly saying that most parts are testable, and that some parts require a different kind of testing: Stress Testing.