Although I’ve been administering (to) a Joomla site for a while now, I recently had the opportunity to install Joomla from scratch for the first time. The process was remarkably smooth, and with a little help from friends around the web it was done in no time at all. And surely one of the keys to the simplicity of the installation was this: After untarring the distribution files, the next step is to fire up a browser and load the URL of the installation directory, which shows the first page of the Joomla installation process. The page is essentially a test report; in my case it was mostly green, with a couple of red markers that showed things I needed to fix before installation could proceed.
This is rather cool – test-driven installation – and it’s becoming more common these days (I saw the same thing when I installed MovableType for this blog). The page tells me what the software expects from its environment, and also where I currently fail to meet those expectations. Neat. In the Joomla case I had test failures telling me that some files weren’t writeable, and that I had no MySql support in PHP. I fixed those and refreshed the page – green! Onto the next page in the Joomla installation sequence, and the installation worked fine.
As an aside, this is one case of a genuinely test-driven process. The distributed package is shrink-wrapped, intended to be installed many times under varying conditions, and the tests are a kind of poke-yoke. Their aim is to ensure that the upstream process (preparing your environment) is completed correctly without passing errors on to the later step. (Contrast this with the example-driven processes we use in “test-driven development”. Here we create sample situations in order to assist – and constrain – the design of something new, during a process that essentially occurs only once.)