I am working on a research project at my university. I was tasked to implement an algorithm that modifies the analog readout of a sensor depending on the sensor location. This algorithm involved looking up two separate look up tables and computing percentage offset required for the sensor readout.
This new feature needed to be integrated with the existing firmware running on the microcontroller. When I took a look at the existing firmware I knew I was in trouble. The code was poorly documented with no unit tests. I was short on time and I needed my algorithm to work.
I decided to try following the Test-Driven-Development (TDD) workflow because I was taking the Clean Code course by Robert C. Martin as part of my internship requirement a few days back.
The workflow was simple. Write a "failing" unit test. Code up the new feature just enough to make the unit test pass. Add a new "failing" unit test. Jump back to the feature to make it pass. Repeat this till you get a fully working unit test suite + module.
Contrary to what I assumed, following this procedure took less time to implement the feature and it was easy to identify if something broke when I changed a part of the new feature.
If you have not given TDD a chance or have not heard about it, this is your sign to give it a try. TDD forces you to write testable code. Free documentation if you name your unit test name very verbose.
Top comments (0)