TDD is not about reduction of bugs, or race conditions. Robert Martin has said that reduction of bugs is not sufficient enough to warrant using TDD for code.
TDD is about achieving better designed code that is maintainable and readable for many years. TDD uses unit tests, not integration tests. So, the behaviour of each function is asserted independently. Maybe you have a function that sets up a data structure at a particular memory location. Your unit test then is just to assert that the data structure at the memory location was setup correctly. You should even be able to unit test functions used in a bootloader like Grub.
> TDD is about achieving better designed code that is maintainable and readable for many years.
It isn't entirely clear to me why this is true. Clearly, TDD forces you to think beforehand about what you want your program to do, since that's ultimately what a test suite is: an executable description of what you want your program to do. However, it doesn't necessarily follow from this that your code will be well-designed or readable. Tests are about evaluating whether an implementation conforms to a specification, not whether the design is actually good. To evaluate a design, you need performance metrics. In other words, you need an answer to the question: βIs this design actually helping me achieve my goals?β
Engineering design is somewhat of a black art. A designer has to be both organized (to formulate and carry out plans) and flexible (to reconcile goals that may conflict with each other and/or evolve over time). Having a large toolbox of methodologies and problem-solving heuristics is a good thing, but it's also important to avoid the kind of mindset where your favorite tool is the One True Tool, or your favorite problem-solving approach is the One True Approach.
Tests in TDD are focused on behaviours required by the problem being solved. One rule in TDD, as Kent Beck lays it out, is if you can't design and complete a test (of behaviour) in under 10 minutes, you haven't broken down the original behaviour enough yet. He uses the simple reminder "start small or not at all". TDD is the very method of evaluating a design. However, keep in mind that this refers to the mechanics and details of a more global overarching design. You still start off with a plan and "bigger design".
TDD in this manner breaks down problems into small manageable chunks of unique behaviour very specific to the problem they are solving. Combine this with the refactoring step, and the code becomes simple to understand and readable. It's very important to note though, that a complex problem will always be complex. TDD does not remove the complexity of the problem domain.
TDD is about achieving better designed code that is maintainable and readable for many years. TDD uses unit tests, not integration tests. So, the behaviour of each function is asserted independently. Maybe you have a function that sets up a data structure at a particular memory location. Your unit test then is just to assert that the data structure at the memory location was setup correctly. You should even be able to unit test functions used in a bootloader like Grub.