Starting The Test Driven Journey

Posted 2012-07-29
Written by Matt Frost
Category code

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

$this->assertFalse(true);
That's going to fail though right? Yep, that's the idea. In the doc block for that test we wrote what we were testing in BDD language, which very clearly explained exactly what was going to be tested. From that point forward, I went through and added a line to the test (above the intentionally failed assertion of course), ran the test, fixed the problems, and repeated that over and over. I will admit, it was very monotonous, especially given the example I had chosen. Finally, after an hour and half or so of writing code for the test, we had verified the bug existed and had a test to verify the fix as well. An hour and a half didn't seem so bad, and considering it was my first unit test with SugarCRM and first time going through the TDD process step by step; I feel like it went pretty well.

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).

Conclusion

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.

Comments

Gravatar
John Kary

2012-07-30

The thing about writing tests on client projects is you factor it into your initial estimate. Your total time to write the tests AND the actual feature is just how long it takes you. Plain and simple.

There are some studies that have been done to demonstrate the longitudinal time an cost savings from writing tests. There is good info on this in the book Code Complete. Perhaps you can source a copy of the book and present to you boss the findings the author cites.

Some other devs I know just start writing tests despite their boss' wishes. And they end up producing better code as a result.

The benefits are difficult to realize at first look, much in the way humans are notoriously bad at realizing compound interest :)

Gravatar

2012-07-30

I've heard of Code Complete, I'll definitely check it out. I've been close to the point where, I've been ready to take that principled stand and say, I'm writing the tests you can fire me if you want. I'm not there yet, but when code isn't written well and functionality isn't easily, automatically verifiable no one benefits.

We have this process now where a non-developer tester runs through the process in a browser and we throw an hour or two into that and say that we've tested it well. I agree the time should be built in, a lot of these projects are just in such bad shape, untestable, over budget, and just ugly.

Thanks for your comment though, gives me some things to think about :)

Posting comments after has been disabled.