Recently Ross Crawford asked a question on the developer list about testing User Interface code. Little did I know that I'd be putting my response to him into action the very next day.

Today I was adding a module to one of my sites, and I decided that the module list should be alphabetical by column, rather than by row as it is now. A simple change, I thought, why not take a few minutes to implement it.

Naturally my first run at this had bugs. In this case, it was an infinite loop. An infinite loop with infinite output that gave my Firebug-enabled Firefox a really hard time. A restart the browser with 20+ open tabs hard time. Not fun.

There is a simple fix for this, I thought... unit tests! After all I'm going to wind up writing tests for it before I propose it as a change, because being able to prove that a change works is (or should be) one of the best ways to get a change approved.

A couple of glitches with mocking JText and trying to get the Windows CLI version of PHP to not dump captured output to the console, and I was ready to write some tests. A short time later and the time for a revise/test cycle was down to a minute or so, eliminating the painful need to kill and restart Firefox. Shortly thereafter the bug was fixed and everyting was looking good.

Then I decided to validate the HTML with Tidy. It failed pretty badly. It seems a misplaced /> was causing a span element to become unbalanced and an input element to be malformed. I fixed this up, eliminated all of the other warnings that I could, and created a patch.

That's the power of testing. I found previously existing but undetected bugs, significantly reduced my cycle testing times, and now the project has a tool that gives every other developer the same advantage with no additional investment in time.

See the documentation wiki for a discussion of the specifics involved in this type of test.