I tried out Test Driven Design (TDD) this spring in a small course project. I read the famous “Test Driven Development – By Example” while doing it and I felt pretty confident that I at least grasped the gist of it. Unfortunately I lack some knowledge in Object Orientated Design and some concepts were unfamiliar to me.
However, I loved it. It allowed me as a programmer with little experience to produce code that I was confident about. I could later refactor it and still be sure that it worked. It wasn’t all that different from how I usually work. I’m never the type who just throws myself into an assignement, I always sit down to think and research first, but here was a technique that allowed me to do that and produce code at the same time. Thinking and coding, awesome!
After my guest lecture the other day, I discussed it with my boyfriend. I bought up that study that showed that TDD can reduce the amount of defects found with about 40-90%. My boyfriend was a bit sceptical as he often is with “new revolutionary programing techniques”. He tried TDD and like me he enjoyed it. He says that he uses it sometimes in his work and that it helps him to structure his thoughts. He points out that there are many factors that we don’t know about, was this a highly motivated team for example?
We discussed it further and talked about why it is works and where it fails. He bought up the fact that eventhough you might start with the best intentions, after a while code gets to complicated. Of course, at that point, it’s probably bad code, he adds, but either way you don’t have time to go back and do it right by then.
We agreed that it does help you build more component-oriented code. Code that is easier to test and maintain. Code that probably isn’t spagetti-code.
I think it’s the time factor that makes it hard. Even in my small school-projects I know how the quality of the code decreases the closer to deadline you come. Would I still be writing tests first the day before delivery? I’m not sure.
The search for simplicity 