One of my new favorite ways to “procrastinate usefully” is by watching YouTube talks by Robert Cecil Martin, also known as ‘Uncle Bob.’ Bob is a software Engineer who currently works at 8th Light, Inc. and is one of the co-authors of the Agile Manifesto. He has been professionally programming since 1970, and sells videos (Clean Coders) that teach young programmers how to build professional code. Uncle Bob also gives talks at various conferences regarding various issues related to field of Software Engineering. One of these talk is on Test Driven Development (TDD).
Bob is a big proponent of TDD. TDD is one of those things I’ve heard mentioned in various podcasts or read about in programming blogs, but I’ve never heard anyone expound upon the core ideas behind it. The simple break down is this. According to Bob, TDD is nothing magical. It is a discipline programmers take up to give their development cycle structure. That structure is one that ensures a programmer always has ready to ship code. The code may not have all the features a company wants and may therefor not wish to ship the code, but the programmer can feel confident in the fact that if shipped, everything available in the code works and works well. TDD accomplishes this by enforcing 3 very strict rules.
- You are not allowed to write any production code unless it is to make a failing test unit pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
These 3 rules lock a developer in a constant cycle of writing a test, writing some code, and writing the next test. It may seem like a slower process in the beginning, but your wind up with a far cleaner and more manageable code base.
If everyone on your team follows TDD, then all compilation errors are just a minute or two away from what you just tried to compile, the project is in a perpetual state of ‘ready to ship,’ and perhaps the most important benefit, you get a little button that tells you if everything works or if something is broken, and you believe that button. This allows you the freedom to clean code or update older systems developed with TDD without fear of breaking the system in some strange way. Every time you change something in the system, you can run the test suite and see if something broke or if everything is ok. This ability is a huge benefit to increasing development speed as systems get more and more complex, and also future features to be added to a code base with relative ease.
This way of doing things is something of a revelation to me, and I am very excited to get experienced with TDD in my personal projects. What do you guys think? Is TDD as useful as Uncle Bob claims, or do you think it is a waste of development time?
Here is a video by Bob espousing the benefits of TDD (sorry for the audio):
Featured Image from Pixabay. Edited by Brad Wilson.
Problems To Solve 