Project Hub
We tend to use the term “Test Driven Development” or “TDD” for various concepts.
The original concept was, instead of starting with the intent of programming a feature, to start with the intent of testing for the presence of the feature. The subtle advantage of this concept is that it forces us to prove the feature first. This is kind of an outside-in or top-down approach to programming. The consideration shifts to how a feature, realized in code, would be used and tested, before considering how the feature will be implemented. But isn’t that just having a good functional requirement? True, but it’s also having functional requirement that can be executed by the computer.
One matter that often perplexes the testing of existing code is that it doesn’t expose a suitable testing surface. another concept of TDD is to develop tests along with the code, thereby ensuring a better testing surface, leading to better testing and more robust code.
There are addition concepts in TDD, some of which I will explore herein.
As I’ve journeyed through various levels of testing, I’ve been getting interested in the art of fluently writing tests that provide a comprehension of what I’m testing. Traditional approaches to unit tests lean too much on classes and methods without telling the other developer what the code is really supposed to do. I got turned on to the way that rspec tests both provide for naming tests purely textually and how they provide a way to organize tests hierarchically. My first experience in this was in testing JavaScript code with Jasmine. Most recently, I’ve been exploring this approach in C++.
Explore Test Fluency and Comprehension
If every line of code is written only to turn a red test green, then no line of code is untested.
A purported advantage of mocking is that a test can only fail due to a defect in the UUT. However, in practice, it turns out better to involve as many of the collaborating classes in the test case as possible. The idea of mocking is to isolate collaborators that are impractical to use in the test case.
I was reviewing a colleague’s unit tests, that heavily used Mockito. I ran the tests and they were gren. Then I changed one line of code - making a method return null. The tests were still green.
It is a common assumption that unit testing cannot be applied to firmware because firmware is tightly couple with hardware. Nonetheless, I think that there are some areas where TDD of firmware is beneficial.
Indeed, it’s often possible to test the code outside the target environment for situations that are very difficult to reproduce in hardware. I also think that TDD of code can produce more maintainable firmware.
Example project using GTest for TDD of Arduino LED timer
Here’s a collection of resources presenting a variety of perspectives on TDD.
Explore Perspectives on TDD