Decision making is often seen as being one of the most risky actions one can take. Having to choose between two options can even debilitate a person when comparing the two. For reasons such as this many intelligent people have turned to deductive reasoning and basic logic when faced with a choice. While these practices are very helpful when making choices of objective nature, when dealing with situations of seemingly subjective nature it can be difficult to identify the obvious choice. In the case of programing, this is where unit testing and TDD (Test Driven Development) step in.
I cannot tell you how many times I’ve heard developers proclaim “The program works, trust me!” only to have a quality assurance technician find a bug within minutes. This observation (years ago) lead me on a search to find a better way. I stumbled into TDD almost right away. I quickly found leaders such as Robert (Uncle Bob) Martin and Kent Beck to be both fascinating and convincing. I bought a few books such as Test Driven Development: By Example and began my study. I found, through my reading and eventual practicing of TDD and Unit Testing, that my past trust in my code and self was not only risky but outright amateur.
Unit Testing and TDD lead to a paradigm shift within the developers and, when practiced within an organization, the business itself. One of the most important process changes that an organization can make to ease transition into TDD and Unit Testing is in the way features are described and translated into requirements. High level user stories are great but if we’re to unit test very well we need to know the expected behavior in all of the basic operations of a feature. These use-cases are the meat and potatoes to accurately being able to unit test and prove whether or not the code/program works. When a developer is able to translate the use-cases into unit tests and build up a competent suit of tests at that point the trust in the developer and his/her ability to program is no longer needed and the shift to trusting the tests begins. The premise becomes as long as we have simple, accurate, and plentiful tests and they all pass then the system/program/app works AND we ship it!
Disclaimer: the link in this post for the book “Test Driven Development: By Example” is an Amazon affiliate link.