So You Wanna Do TDD?
Today I work at a Software Craftsmanship company. We pair program. We do iterations. We test drive everything. Development isn't perfect, but most of the time it makes sense. However...
About a decade ago I was you. I was working at a huge, no really huge, enterprise company. How huge? My cube (yuck) was at 2C3. That was the location stuck on a pole so you could locate me amongst the cube farm. Think of a parking lot at your local mega-mall or theme park. We only used technologies that were "proven." How proven? We couldn't use Java or C#, too new. In 2007 I was still writing Windows thick clients in C++ with MFC. The codebase was two million lines and stored in Visual Source Safe. Don't let me get started on bug fixes, which were often ignored because they weren't important enough.
And our unit testing ....
Unit testing was done via Word document that had checklists. When you finished a feature you were supposed to run through the manual tests on the checklist, through the UI, duplicating what the functional testers were already doing. These tests were almost never done.
The code that was delivered was usually buggy, late, and terrible to work with.
I Tried To Change
A couple years into my job a mentor and friend of mine lent me the Extreme Programming Explained book by Kent Beck, and I was immediately attracted to the idea of Test Driven Development. The notion of writing little tests to demonstrate working code just clicked in my head and I immediately started to write my code that way.
And I failed miserably...
I started writing the code test first and found it took FOREVER to run the tests, and they failed intermittently. It took a lot longer to write the code, and eventually somebody commented out my tests because "hey it's just test code." Finally somebody added a feature to my code by copy-pasting entire classes, and tweaking some names, because they didn't understand the design. In fairness the design probably wasn't very good.
Frustrated I convinced my boss to let me take a class. I took a class in TDD at Object Mentor and was lucky enough to get Bob Martin as an instructor. I remember him making me feel very stupid when I asked how to test private methods1. I also remember feeling like I finally got this. I understood the method, I knew what I was doing, and I'd get it right from now on. My boss asked me to train others.
And I failed even more miserably... Nobody paid attention, I convinced at least one developer NOT to write tests, and couldn't even complete the bowling game in front of others.
Then I Succeeded
So how did I get from the place I was at a decade ago, where I actively failed at both TDD and teaching others, to a place where I practice TDD constantly and teach others? Did I just get lucky and get a great job2? Should this book just be the application form at the 8th Light website?3 Do you have to change jobs to write code the right way?
Of course not.
This book is about taking problems, problems I've lived through, and solving them directly. Have you ever been stumped on how to deal with the database in tests? We'll deal with that. Have you ever struggled with code that doesn't have tests? We'll deal with that too. Have you ever written tests without a test framework or had to test a UI? We'll do that too.
And we'll do it in ways that DON'T make you slower than your fellow developers who might be skipping tests. We all know that the boss doesn't care about tests, they care that your work is done. Therefore this book takes a pragmatic approach. We'll make sure our code works without requiring esoteric expertise. When you're done with this book you'll have specific solutions, that you can take to your job today. Even if the code is big.
Even if you work in a cube.
Let's do this.
1. "If you can't get to it through the public interface, why does it exist?" Bob was not mean or condescending, but the answer is so obvious I felt like a dumbass. ↩
2. A little. ↩
3. http://www.8thlight.com/ ↩