I’m starting with Part One, but I anticipate it’s the first of many, if not a few.
When it comes to complex topics I notice people just go into describing the topic. One of the things I learned as an educator is that an alternative mindset is better. “If you want to build a ship, don’t drum up the men and women to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” Antoine de Saint Exupéry
Why TDD?
I have been learning the ways of Clean Code and am at the TDD crossroads. One example that Uncle Bob mentions is scalability.
In short, new projects at first have high productivity, however as they grow in a matter of months or years the high becomes low. The initial code if not written with future modules or changes in mind will rot. Debugging or modifications may cause the whole system to crash. What used to take a week or a month to produce now becomes months or longer. This does not spark joy.
A small mention of Brooke’s Law, which counterintuitively means the more people you hire to fix the problem the longer it takes to do so.
Since I am in the mood for proverbs, the process above is like building your house on sand. TDD is like building your house on a steady foundation. Sand may be faster initially, but you can build many things on a good foundation.
What is TDD?
First let’s answer what is not. When I first started solving Advent of Code problems, I tried to go as fast as I could to accomplish as many as I could. No refactoring just blaze through, and if I was stuck move on to an easier problem. This is not TDD, this is sloppy.
TDD is meticulous and precise. Instead of finding the solution to the problem:
# You create a test. The simpler the better
# Run the test
# Write code to make it pass
# Refactor if possible
# Rinse and repeat
This process ensures that at every stage of development, it is satisfying all of your requirements. It is also best to be very specific with the naming of the tests. In doing so, if any changes ruin the code the test name will tell you exactly what went wrong. Which makes it easier to debug the code.
Test –> Code –> Refactor
Testing so often allows you to put more trust into your system. This happens because the code is clearer and easier to understand. Which allows you to make changes efficiently in the future.
In the end, I have a lot of code to erase and build up again.
Merl