I gave a short talk on test driven development as part of a training project for fresh graduates (or to be graduates). Main idea was to talk about test driven development and hopefully raise some interest so they can practice it during the remaining part of the training. I wanted to have a free talk with minimum presentation and if possible with a practical example. I decided to look around for existing material to see if I can get something as example. After few articles I decided to change my topic as “Driven Development” since I found many different flavors of this very popular topic. It started to feel like choosing a title alone makes you a part of a community (and sometimes refuse another one) without you know it. I’d like to focus on something around Behavior Driven Development and Test Driven Development although there are plenty other interesting ones (Feature DD, Asshole DD, Readme DD, Model DD…) I decided on the exercise (an algorithm question) and the main headlines and hoped that interactive discussion will lead to somewhere nice.
It is a dangerous hopeful approach. Didn’t turn out that bad but could have been better. Because of the later part I decided to take note on what went wrong and what went right so I can refer to it next time.
Algorithm question was nice. Something simple enough to be explained in few minutes. Taking some examples and getting answers for few input also took some minutes before we start thinking about general solution. Good thing with puzzle like questions is that they are interesting, mostly. It wakes most people and helps them to join the discussion regardless of the programming knowledge. I avoided any programming terms at this stage on my account and nobody jumped that direction.
“What do you do now?” was the question after we get a generalized solution for our problem. We defined our inputs (an array of integer values), an algorithm and what needs to be computed for output. Answers started coming like “I traverse the input values”, “I count the number of repeats of numerical values in given array” etc. That was not what I was looking for. I realize now that I use the same first person sentences when I try to explain a piece of code to a colleague: “here I check the first occurrence of the character…”. It felt strange then to think myself looping over the input array. I think it is a common habit among the programmers to jump from design (or identifying the solution) to running application. Especially the young ones are not that concerned about the actual practice of writing the program. “Looping over the array” is the main concern not how that loop is written. And yet, in a recent interview biggest clue I got about the candidate’s experience was the way she set up her for loop.
“So, what do you do now?”. Silence. So it needs a bit more help: “You came to the office busy with the algorithm from the previous night, got yourself a coffee, turned on your computer, checked your mails, and what now?”. That helps. Then we started our IDE, created a project, added our source code, wrote our main method and so on. Being a difficult person I put many “why” questions. “Why did we checked that check box?”, “Why did we put this keyword here?”… It is interesting to see how many thing we do even realizing but unfortunately not knowing why we do that. I expect that some actions are almost automated for an experienced developer but just because he (or she, let’s stick to he for now but mean that he or she) executed those actions so many times and he know exactly what do they mean so he doesn’t need to think about them again. That’s not the case always.
It was nice to go with coding and implement almost all the algorithm this way. Then came to the question that “how can you prove that this code does what you think that it does?”. That leads to testing and eventually unit testing and not much of a jump from there to test driven development. Some explanation on unit testing and some information on unit testing macros I am using. Then we did the exercise from beginning, this time with test first approach.
I have following guidelines when it comes to writing a piece of code which I am trying to stick lately:
- Do not write any code without an actual need: This is a bit more complex. We realized that it is not that easy to decide the order of executing assignments. Wrong order of execution often leads to time loss due to design changes which could have been avoided if only pieces put together in the right order. Simple test for me is that if no body calls a method, you don’t need to write it.
- Having a test method checking your code is not an actual need: That is the trap we fell often when we try to stick to the first item.
- You don’t write anything if you don’t have a test for it: Test is where you write down your expectations from your code. This is often the most time consuming part lately and leads to lengthy discussions.
