So you think TDD isn’t worth the cost?

January 28, 2012 Uncategorized 1 comment ,

Think of the full software development life cycle. We gather requirements, create user stories, break them down into tasks, estimate, fight with your client about how long it’s all going to take, renegotiate the timings (what’s 35% of the development time on unit tests? Do we need those?), submit a revised timescale with cut down requirements and no time allocated to testing. Then we start development.

And soon the problems start coming up. At the end of the first sprint the client raises a few bugs with the software delivery… We didn’t account for those in the plan! And we can’t estimate them – we don’t know the size of the problem. That’s why it’s a bug… So we allocate some time in the next sprint to work on the top priority bugs and commit to developing fewer features.

The second sprint finishes, and more defects are raised in the software – some of them can be attributed to requirements not been defined clearly enough, but some of them are just code that we don’t understand how it even worked in development! Did someone actually test it before it went into the main development branch?! (how many people can honestly say they have never heard that one before…?)

Pretty soon you’re way behind the plan. The number of bugs that we cannot estimate and didn’t plan for are sucking up too much time and we don’t know how long it’s going to take to get back to a point where we know how long the project is going to take.

So what’s to be done? Bugs throughout the development life cycle are inevitable – but because we cannot know how many there will be and how long they will take to fix, we need to be able to minimise the number that crop up.

Some research done by microsoft ( has shown that spending 15-35% extra development time on adopting test driven development resulted in a pre-release defect density decrease of 40-90%.

The ideal is when we can plan, develop and release software that contains no defects in a timescale that everyone agrees on. This wont happen any time soon – but an increase of 15-35% development time for up to a 90% decrease in the number of defects has *got* to be worth it by anybody’s standards.

Have you used TDD (or BDD) and experienced similar results? Comments encouraged!

Buildings a Continuous Integration Server for PHP with Hudson

October 4, 2010 Uncategorized No comments ,

An article that I wrote for techPortal has been published.

PHPNW TestFest 2010

August 12, 2010 Uncategorized No comments ,

I am very pleased to announce this years PHPNW TestFest over at MadLab in Manchester. The event will take place on Saturday 11th September from 12pm until sometime around 5-6pm. Lunch will be provided (courtesy of our sponsor, Ibuildings), and I daresay we may wish to make an bit of an evening of it at a local bar…

More information on what the php testfest is can be found over at and you can register your interest over on upcoming, at

All you will need on the day is to bring your laptop. The venue will provide all of the connectivity that we need.

Hope to see you there!

Unit testing protected/private methods in a class

June 2, 2009 Uncategorized 4 comments ,

I think a lot of people when getting into unit testing naturally assume (and are told) that typically, a unit is a single method or function within your code, and each unit should have a unit test.

To an extent this is true – until you are presented with what you do with protected or private methods within classes.

There are two camps of thought on this issue.

One (that I disagree with) says that these methods ARE units in their own right, and should be tested as such (using introspection, or language hacks etc). In PHP this can be accomplished by abusing the __call method in your class (to allow a test suite to call protected or private methods on your class).

The second, is that a ‘unit’ is actually a single call to the public interface of your class. The protected and private methods that are called within the class are implementation details and should be allowed to be refactored entirely. Providing the behaviour and the public interface of the class does not change, refactoring does not involve ANY modification to the class itself.

Because the implementation details of a class do not constitute a unit in it’s own right, testing these methods in isolation are therefore incomplete and actually invalid (as they never have the context in which they are used, and even though your code may show 100% lines of code coverage, the branch coverage will always be far from complete).

So – if you’re tempted to create a test for a protected/private method within a class, then you’re moving away from unit tests and into protecting your implementation using a unit testing framework.