TDD aha moment
Here is a new tag line for TDD: “spend more time with your family”! TDD is an approach to a software development that ultimately saves time during a construction and maintenance cycles. Want to take your kids to an early game of their favorite team, or disappear for a couple of days with your significant other? If you do, then you cannot afford to waste hours per day restarting your applications and navigating to certain locations just to check a presence of a link. You cannot allow yourself to wait for servers to start up, and do a manual testing. On a more global scale, you cannot be interrupted by a call during a date because of an embarrassing bug in production. If you could shave off 20 minutes from one hour by test automation (not atypical), it runs up to saving about 3 hours during one day, and 2 days in a course of one week! Here is another tag line: “TDD – go home early”. Emergency calls at night make you drive to the office before the sun-rise? “TDD – stay home late”. Ok, ok, emergency calls at night cannot be completely eliminated, but the number can be reduced.
The aha moment came to me one day when I made a tiny silly mistake. I wanted to fix it right away to regain some self-respect. It was one of those errors that you think even a human with a half brain cannot make, so writing a test for such a situation is below you. The fix would be so simple and straightforward and it would take me just 10 seconds to do it. Then I started thinking about starting a server, selecting a set of data that would trigger the exceptional situation and making a “visual sign-off” to confirm the correct behavior. This cycle would have taken me about 10 minutes. My enthusiasm started to fade away little by little. Aha! It would take me only 5 minutes to write a failing test, fix the code and re-run the test.
I went home 5 minutes earlier that day.
PS: TDD is a serious subject. There are excellent arguments out there why TDD is not just a fad, but an essential software engineering practice. For example, in an article “What Is Software Design?” (1), Jack W. Reeves suggests among other things that “… it is cheaper and simpler to just build the design and test it than to do anything else”. It’s a fascinating read where Jack convinces you that engineering rigor in software is testing.
I should also recommend “Neal Ford on Agile Engineering Practices” (2) from O’Reilly Media to learn more about TDD.
PSS: TDD is not all or none proposition. I believe that a goal of 100% test coverage might be harmful if it’s just a goal by itself without a broader context and a consideration of trade-offs. But that’s a topic for a separate discussion.