Join the DZone community and get the full member experience.Join For Free
In our first episode, we defined guerilla warfare and looked at why using guerilla-like tactics can be an incredibly effective way to spur on an agile transformation from the bottom up. Then, in episode two, we zeroed in on the two fundamental tactics employed by the agile guerilla. Episode three's focus was on how to get started. We examined four different ways that we can turn inward and address our own flaws as a developer and as a person. Episode four showed us...wait for it...FOUR ways that we can improve our personal workflow and influence our team to manage its work more effectively.
In this episode we're going to continue today's automated testing theme ( see Jared's article on DDT) with a look at how you can apply Test-Driven Development (TDD) to your work even when the rest of your team has yet to get on board.
In early 2003, my team was slowly slugging through development of an enterprise laboratory management platform. At the time our development model looked a little something like this:
- Code until you run into an unimplemented dependency;
- Repeat until one of the dependencies is checked in;
- Big Bang Integration!
- Debug, debug, debug…
- Repeat until something pseudo-demoable is ready.
As you might imagine, this wasn’t a very productive way to work, but unfortunately it was all most of us knew. At the time I thought we really needed to improve on our testing so that we could eliminate a lot of the defects that at the time I didn’t realize were being caused by our development model. I asked my boss if I could start a QA effort and not too much later found the XP/Agile Universe conference that was held in August 2003. It was my hope that we could learn about how to properly test/QA our software there as there seemed to be a lot of talks about this “TDD” thing. I got approval to attend, and while down there I was immersed in this new culture of Extreme Programming (XP) and Agile.
At one point I ventured into a room that was setup like what many of us would call a SCRUM/Team room today, where a group of folks were all coding away on a system and making its FitNesse tests pass. I quickly paired up with a gentleman and we went to work. At some point Brian Marick came over and asked what we were working on. I fumbled through a description of the requirement and he then asked, “Well, where’s your test?” I said that we didn’t have one, and he then said something that at the time was very profound to me, “Well, you can’t write any code until you have a failing test!”
I spent most of my time waiting in the airport to return to Memphis reading Uncle Bob’s Agile Software Development: Principles, Patterns, and Practices. Needless to say, I was fired up.
When I returned to work in the following weeks, I essentially tried two different tactics in parallel to share what I learned with my team.
First, I practiced what Jared calls “2×4 Development,” or, beating your team in the shins with a 2×4 until they start doing TDD, pair programming, continuous integration, etc. I even delivered my own version of the agile manifesto to the entire department, and the most profound comments I got out of that were “I can’t ever imagine us paying two developers to sit at the same computer and work on the same code,” and “Well, who’s going to test the test code?!?!”
Needless to say, this didn’t work very well. My second tactic was what I now call Guerilla TDD (G-TDD). I told my teammate that I didn’t care what he did with the rest of his time, as long as he checked in his interfaces before he started to code. Now I had something to mock! I then proceeded to TDD all of my code. I advertised my productivity in terms of test cases passing with a little counter on my whiteboard. Development was fun again, as I could get instant feedback on how my code was working and I knew that it was interacting properly with its dependencies. Sure enough, when those big bang integrations happened, my code rarely seemed to be the source of the defects, and I quickly found myself getting pulled into other parts of the code to help develop since I had already gotten my typical assignment finished!
We delivered the section of the system that I developed using TDD much faster than any part that I had worked on up to that point (no hard numbers, but I have a pretty good memory of that time), and in addition, I wrote the CLEANEST code I had ever written up to that point.
Word of warning, Guerilla TDD will never be as effective as TDD practiced by the entire team – you’ll almost never get someone who doesn’t care about tests to fix one that they broke. However, G-TDD worked well for me and got me some recognition as a guy who could write good clean code fast! If I could go back to that point, I think I may have tried Defect Driven Testing first or in addition to G-TDD.
So, how are you getting your team test infected? Try G-TDD, try DDT, try both!
That's all for this episode of The Agile Guerilla. Next time we'll take a look at Guerilla Continuous Integration. See you then!
Other Epsiodes in "The Agile Guerilla" series:
Opinions expressed by DZone contributors are their own.