The Aust Gate

I have been working on a project which has gone slightly wrong for a variety of reasons. Most of which I am not going to go into here.

However one of them was a lack of testing. Not full system testing but the less glamorous and more (let’s be honest) tedious unit testing. I have ventured into testing before but not on an enterprise scale. Previous companies have not seen the benefit in spending time in creating tests and running them.

In a sense I fell into it quite by accident. I was running some manual tests for another project, following a set of use cases and test plans. All went well if slowly. Having got in early, I spent some time using the Selenium IDE in Firefox using the WYSIWYG editor in an attempt to quickly put some tests together. Having run the tests, the time taken to do them were cut down significantly but more importantly, they can be run again and again in the same way. Unless altered. Then they can be run again and repeated. Yes, setting up tests takes time but in the long run appears worth it in terms of confidence.

The confidence comes from being able to repeat things and to be able to identify either code or user story issues. If new code comes in, the code can be run and regression tests performed.

That is running tests at the end though. What about developing? That’s where Test Driven Development or TDD (Wikipedia, Agile Data on TDD, ) comes in. Or where I hope and strongly believe it will.

I am not going to go into what TDD is but drawing on current experience, it will allow me to have a greater confidence in the built code. In the long run, spending some spare time getting into writing tests and then building code around them should allow me to refactor the code and remove its issues.

Moving on though, I can use it to make sure that bad code does not creep back in. Since we use PHP at work, I have been using PHPUnit as the best framework. Having dipped in and out of PHPUnit over the last couple of years, I needed a quick reminder about some of its features and how to set it up to read existing classes which is what this sitepoint article gives.

Is this where it ends? No.

The next jump to make is to get the Jenkins Continuous Integration tool to run the tests that I write. Automatically. Whilst writing the tests and then code offers confidence that the while thing is going to do what I think it is doing, I would really like to not be continually running the tests. I have installed the Jenkins tool on to Ubuntu 10.10 (though upgraded to 11.04 recently) and once the first tests are written, then I will set up a project in Jenkins to run it. That is another post for another day.

So where does this leave me? In the first place, I am playing a certain amount of catch up to build a testing skeleton. It will have holes but the coverage can be extended and I get into better practices with regards development.

More importantly, the code that I write can be released with a certain amount of confidence and built on or against with that confidence.