[caption id="attachment_583" align="alignright" width="300" caption="How much time did I spend looking at this instead of typing tutor in elementary school"]
[/caption]
I've read the blog posts, heard the speeches, seen the tweets about unit testing. At a conceptual level I understand, you should unit test because then when you make changes you can find regressions easier. I've even heard the TDD people beating their drum about how I should never write code without tests. I get it, it sounds really good, and here is the dirty secret, I don't do it.
For those of you who have continued reading don't worry this isn't another volley in the war between TDDers and non-TDDers, this is about why I couldn't wrap my head around testing, and how I finally did, and where I am now. I hope that if you are in the same place I was, you agree that the idea of testing is really good, but can't figure out how to incorporate it yet, that this post might help you. I'm also going to take you down memory lane a little bit, but there is some good knowledge about a cool PHP testing framework in here, you can skip to it, if you like.
I grew up in a little house just outside of Cleveland, Ohio with an incredibly warm and caring family. There were 4 boys, my mom, and my dad. There was never much money around, but I never realized that this was such a bad thing, I had what I needed and a little something more, a computer donated to us by my Uncle Marty. The computer was a magical thing at first, I was 5 or 6 when it arrived in our house, an old black and green with less RAM than the Rockstar energy drink I'm sipping on right now. You could put in 5.25in floppies and play Dungeons & Dragons, Hitchhiker's Guide to the Galaxy, or some weird Submarine Game. You could do something else though too, if you put in a blank disc you could make your own game. My uncle showed me the basics of BASIC and my school library had a book filled with BASIC code that could make egg drop games and even a star trek rip off. I was hooked.
[caption id="attachment_584" align="alignleft" width="300" caption="Oh those halcyon days, you were all I needed dosshell"]
[/caption]
As I became a slightly older lad, still around 8 or 9, we had another family donation. This time my Uncle Bob had upgraded their family computer, and so we got the old one. This one was a marvel though, it had colors and could even go online. It had windows 3.0, although it was really just this odd thing we fired up from time to time to play in, we spent most of our time in dos shell or on the command line. I wondered if this computer had BASIC, and I found QBasic.
QBasic was were I really started programming, although the current programmer in me wants to throw up reading that sentence. I was no longer just copying code out of a book and making changes here or there, I was coming up with new ideas and figuring out as I went along. The built-in help system coupled with fairly readable error messages and a tightly integrated run time made learning easy and accessible to me. I would code stuff up and give it a go, I didn't realize that I was running an interpreter or had any idea what a compiler was, I would just develop and try it out. It was my REPL, although much more manual.
I moved from there for a short time to Visual Basic, and then at BGSU to C and C++. The C languages seemed so onerous to me at first, there was this lengthy compile step, I had to declare everything, there was odd punctuation floating about. But I got used to it, and became fairly proficient in it. Towards the end of my time at BGSU I took a job with the University fixing computers for RCC and from that job joined a team of PHP programmers.
Something felt familiar and comfortable about PHP development, I would just type some stuff and refresh the browser, immediate feedback. That's when I realized how my brain was set up, wired from the radiation of that old green and black monitor, I wanted to develop in quick insanely small iterations. Change this or that and test it out. Toss in an echo here or there to see the state and make decisions based off of that. It was always more structured than I'm making it out to be here, but the structure was there to support this notion of Rapid Application Development.
To this day I still find myself more comfortable building something new by getting the simplest thing that could possibly work (Minimum Viable Product) up and running and then doing iterations over it again and again, polishing it up. When I coupled this strategy with really aggressive refactoring I was able to produce some cool stuff, complex reporting architectures for clients, constricted language parsers, bytecode compilers, and to a large degree prosper.
[caption id="attachment_586" align="alignright" width="113" caption="Thank you creepily fake referee man for illustrating my point"]
[/caption]
Testing though seemed like a great idea, TDD seems like a nice way to write code, tell me what you are going to do, then do it. Makes sense. I tried to do some unit testing but had some false starts. I tried to do it with some Java code, wrote up a jUnit test, ran it with an ant task and it told me everything was cool beans. Did a few more and then couldn't figure out what the point was, I was testing things I knew had to work, if variable assignment stops working in the JVM then my unit tests aren't going to make a difference. Then I worked on 2 small projects that were Test Driven and they both hampered development so much that the project either failed or I quit altogether from it. My innocence had been dashed and now the thought of TDD left a sour taste in my mouth.
I had secretly hoped that like pair programming, scrums, and kanban boards this would be another good idea from agile that would have its time and then quietly be swept aside as impractical (of course I'm not saying these things are impractical, just that none of the enterprise shops I've worked at cared about them at all). After CodeMash I realized that these things weren't going away, so I redoubled my efforts to learn them and that brings us to today. (That was a long and weird trip if you read through it instead of just clicking the "skip that stuff" link, thanks!)
It's all about tools. I've tried various testing frameworks in Java and .Net but never found something that fit in with my workflow. I sat down at the Oracle of All Knowledge (Google) and started looking for a unit testing framework for PHP. Then I found SimpleTest, the name immediately drew me in. It was exactly what I was looking for, something simple I could use to write unit tests with. I went through the tutorials and figured it all out and it was exactly what I wanted, I could write up my tests and then just point my browser at http://whatever/tests/all.php and it would generate a cool webpage telling me exactly how my tests are doing. I was converted.
I'm making some fairly big architectural changes to the internals of Prosper for the next release (0.8) and have decided that part of the effort is going to be wrapping stuff up in unit tests, lots and lots and lots of unit tests. This is my first go on unit testing so I'm certain I will get some things wrong, but I'm hoping to learn a lot, and you can play at home and tell me what an idiot I'm being.
At the end of the day I'm beginning to move from, tests are cool but I don't test, to tests are cool and I'm learning how to do it. I've been down this road before with git and ruby and rails, its frustrating but worth it. SimpleTest is really cool, but I'm still finding my way through it, I'm writing a new output printer inspired by John Resig's QUnit and will release the code for that soon. Once I have a workflow and test directory structure I like I plan on producing a series of posts. You can find them because I plan on tagging them all with "Dr. SimpleTest or: How I Learned to Stop Worrying and Love the Test"
[/caption]
[/caption]
[/caption]
