Starting The Test Driven Journey
Being an apprentice under Grumpy has been a great experience for me to this point. I've been plagued by all the issues that occur when you don't have any way to verify that the code you've written works or hasn't broken other things in your application. I've dealt with implementing a new feature and having it set off bug after bug, I've been in damage control mode, and I've certainly had that sense of jitters when finally pushing that feature request to production. If there was any way to eliminate the spirit crushing sense that you'll never be finished with anything or you'll never be able to improve something because more bugs keep cropping up; I wanted to be part of that.
I bought Grumpy's book shortly before attending Tek 12, read through it. It's a great book, and I really do recommend it; but I just wasn't at that point yet. I had written a few assertions, but the tests certainly weren't improving the quality of the code. They were generally just telling me things I needed to know, but not everything I needed to know. Tests have to be good to provide any sort of value to your application, I had no idea where to start when it came to writing good tests.
Verifying Bugs with Tests
The first time I had a Skype session with Chris, he had me pick out a bug fix I was working on and we wrote a test to verify that the bug existed. At work, I'm the Lead Programmer for our SugarCRM based projects, so writing a unit test in a framework/application like that seemed a bit daunting. John Mertic over at Sugar hooked me up with some documentation on unit testing SugarCRM and it turns out it wasn't as daunting as I'd feared.
You might be wondering, how did you write the test? Well we got the test all setup, declared the setUp and tearDown methods, and setup the test with a single assertion
Fighting the Battle
Unfortunately, the clarity that has come to me personally is not shared by all. In our call last week, I talked to Grumpy about how my exuberance to write tests was being snuffed out by "we don't have time" excuses. In consulting, every hour goes to someone; so being rebellious and writing the tests anyway would mean I'd have to bill the client for the tests I was told not to write. I don't feel right about operating that way. I did have permission though to meet with Chris during work and get that first test written. Every time I can prove that a test saved us time, prevented a bug from being introduced and saved us some hassle; the more testing will win everyone over (theoretically). The unfortunate part is that in order to stay sharp, I have to write tests outside of work on things that aren't work related.
So That's What I'm Doing
A while back I decided to write a framework as a learning experience to help me learn more about frameworks. I saw that as a great opportunity to use Test Driven Development to practice writing tests in the context of an application. I already know that the PHP world doesn't need another framework, so you can save that racket for someone else; but if I can gain the experience of writing tests first and validating that the desired functionality is correctly implemented, then I win. Even if no one ever looks at my framework (although I'm hoping someone will).
Committing to writing tests means that you will write more lines of code, it means that it will take more time. There is no magic bullet that lets you write high quality code quickly, experience certainly helps, but in a large application it's impossible to understand the different areas that could be affected by changing code. The lunacy that I've experienced is that some how it's better to turn out bad code quickly and then fix it. It makes it impossible to estimate because we can never know how much time is going into the fixing bugs and we never really have full confidence that our solution is the best one. If quality, consistency, extensibility and stability are important to you there's really not another option. No matter how good your developers and engineers are they'll never be able to produce the necessary information as quickly as a suite of well written tests.
I've already drank the Kool-Aid, I'm in. I've seen the benefits, I've experienced the increase in confidence, and I've only just begun my journey. I'm very grateful to Grumpy for his time, patience, and his ability to put up with my awful jokes and down right silliness. It's selfless commitments to helping others learn that makes the PHP Community great. So pay it forward and start writing some damn tests!
Lastly, here is a link to Grumpy's Book The Grumpy Programmers Guide to Writing Testable Applications - you should buy it.