Tuesday, August 6, 2013

Figuring out TDD

I want to use TDD in my GSoC project. Tests are important, and the benefits of testing are worth it.

Now, my only problem with TDD is, I'm not quite sure how to do it. Oh, I've got the mechanics in place (Travis is set up and ready to eat my github repo, and I think I've got phpunit setup locally. Heck I even have Jenkins on my local machine if I could ever get it configured right.), but whenever I go to write unit tests, I feel like I'm staring at a blank page in an old fashioned typewriter.

t  o  w  e  r
I feel like I'm staring at a blank page in an old fashioned typewriter. (Image from starside on flickr)
For a long time, I think my problem was an incomplete design. I knew I wanted to take stuff from a boilerplate, then "process it somehow", then put it in a derivative package. But I didn't know what that "somehow" looked like.

Well, I've figured out the main parts of that process now. I know what I want my API to look like (within PHP). So, I take my first example, and go line-by-line to make it work.

Loading Gist ....

So, let's take part of line 2:

new BlobQuery('Cognifire.SweetSitePackage');


How do I test this? Do unit tests test constructors? Is this a unit?

And so I'm back at that blank page again. I'm not quite sure what unit I'm testing. The constructor doesn't return anything, it just sets up the object. Should I add getters and setters for what should ultimately be protected properties just so that I can test that they are initialized correctly? That seems rather odd.

But TDD says don't write a line of code until you've written a failing test, so I feel stuck.

How do you approach TDD? Unit testing? What questions do you ask yourself to get past the stupid blank page?