Fellow developers, I have had my TDD epiphany. I have been a software developer for a very long time and never felt that I fully grasped the concepts behind Test Driven Development. Today, I came across a performance issue which involved a client complaining about an application taking 20 hours to process a certain number of records. I was panicking and thinking of ways to reproduce the problem and how we can measure the performance so we can improve it, but what I did not have was a goal. I started thinking, why is it a problem that it takes 20 hours to process these products? Then it dawned on me.
What is the expectation of my code?
At this point in the development cycle, I had no tests that asked this very important question. I had only an expectation of myself of how well my code should perform. I asked my boss during this performance discussion this very question, and we both kind of looked at each other without a clue.
This very question could have solved the development life cycle issue the entire time, and could potentially save this issue. How many records should my application process? What is the expectation of the client? If we don’t know, we need to do research and find out. This lead to a whole host of questions that will improve our application and rang the word through my ears, Eureeka!
By finding out what a client expectation, I can develop tests against my code to see if I am meeting that expectation, and if not I won’t release code to a client that does not meat their expectation. This will result in the overall quality of my code to improve drastically. To everyone who has ever tried to tell me about test driven development and had it fall on confused and deaf ears, I apologize. Let’s get to work!