I am relatively new to the Test Driven Development (TDD) scene. Though I have read up on the subject (specifically Test Driven: TDD and Acceptance TDD for Java Developers by Lasse Koskela), my only hands-on experience is limited to a single, 3-month project where I was the lone developer. All other information gathered on the subject has been through blog entries, podcasts, ramblings and the occasional demo in the office. Though I believe I have a good understanding of TDD methodologies, I am far from putting this, dare I say, knowledge to practice. Good practice, that is…
A spike is a term associated with TDD. A spike is nothing more than quick coding exercise which validates or invalidates an assumption. Lasse Koskela says it more eloquently:
A spike is a short experiment with the purpose of familiarizing ourselves with the technology, tools, algorithms, and so forth, that we need for solving the problem at hand. A spike is a way to make an unknown known — at least to a point where we know whether it’s worth continuing to dig that way or whether we should start looking for another way.
If you are familiar with TDD concepts, you know that spikes offer no value with it comes to testability, maintainability, etc. They are merely quick prototypes which I find immensely helpful but should not be considered the focal point of TDD. Well, my first crack at TDD resulted in roughly 70% spikes and 30% actual tests. Not too good.
There is no doubt in my mind that I always had the best intension to test-code-refactor, but I wasn’t yet familiar enough with TDD to know I was way off course. There was also no one around to put me on the right track (or keep me honest.) Putting my ego aside, I know I could have used some hand-holding when I was starting off with TDD.
Test Driven Development is a discipline. Like many other disciplines, TDD requires a teacher, student and practice. The teacher offers instruction and ensures the discipline is practiced correctly. The good student gathers knowledge and implements under watchful guidance. In my opinion, TDD is therefore a seemingly good fit for a team which embraces an Agile approach, collaboration, rapid development and testability. I’m not saying the lone developer with no prior experience with TDD is not capable of learning TDD on their own. I know some are. I know guys who have done it. Simply, I am stating that TDD seems most accessible to the mentored developer working with team members who previously adopted the methodology. To put it another way, I bet Test Driven Development concepts are best learned through practical, hands-on example.
I haven’t given up on TDD yet. Who wants to hold my hand?