This hands-on approach gives you a visceral feel for what’s going on and whether it’s working properly. As a aspiring Engineer I found this a great way to see how process plant related to the engineering specifications and mass balances.

Looking back, this practice was a form of testing, applied to both my knowledge and the construction of the plant. In the latter guise it’s called commissioning, and you’d be surprised the problems you can find this way, from malfunctioning components to blockages caused by dead animals.

And that’s reminiscent of the early days of computing, when fixing a problem could mean finding a real dead bug in the system.

It seems that my process engineering background has followed me into software development: I’m just as fascinated by the use of software test techniques to follow software pipes. Test by test I can find my way around code, checking my understanding of what it does, how it works, and whether it matches the original design intent.

A comprehensive and robust test suite is worth it’s weight in gold when upgrading or carrying out routine maintenance. It’s really liberating to find that you can experiment in code without worrying whether, when the time comes to redeploy, nothing unexpected has changed.

So may be I’m one of life’s testers rather than an outright developer, but then again every developer show have a little tester in them.

There’s no better way to learn a new language than to actually use it in real life. My Nature Notes started as a project for my partner in PHP, CodeIgniter actually, but progress was slow due to an enjoyment deficit.

Testing is the main reason that I grew unhappy with PHP, most of the tools were there, but the integration was patchy: the basics are all there in Ruby and it’s associated development frameworks and integrating new packages via ruby gems or plugins is simple.

I started using the built-in Rails testing tools, but for no particular reason I’ve moved on to RSpec for unit and functional Rails model and standalone Ruby code testing coupled with Cucumber based integration testing. I’ve found that I need both.

Cucumber tests try to exercise the whole software stack – views, controllers, models and even the database. The use of natural language makes it easier to translate user stories into the appropriate tests, though it still needs some discipline to ensure that the edge cases are covered: I don’t think clients could write these as acceptance tests.

Involving the whole stack makes tests a little brittle, how specific is too specific? I’ve managed to break tests by removing fullstops (periods) from the rendered HTML!

I think that this is where unit and functional testing with RSpec at the model level is indispensable. I test model associations, validations and custom business logic in that order, I draw the limit at all the ActiveRecord CRUD functionality.

I’ve found that the development environment hasn’t really changed in the move, the same basic toolkit does PHP and Ruby.

I regularly use several code version control systems including Subversion, Git and Mercurial. Recently though I’ve increasingly turned to Git and GitHub. Like most good tools the more you use it the more attached you become, so I’ll have to force myself to use the equally fine Mercurial again soon. I love these distributed tools.

TextMate is my editor of choice for Rails development. I’ve tried to use Netbeans IDE, I use this for Java, but it seems like overkill. TextMate is quicker, simpler and provides the tools I need via the a range of bundles.

I have to admit that the code syntax highlighting is the most useful feature because I like using the command line too much, but I’m increasingly using code completion and I’m going to try the Zen coding bundles for HTML and CSS, I don’t like the default tools much.

That’s a round up of my current practice, more about the resulting software once I’ve decided to move on to a public beta.

It feels like I’m starting from the top of the software stack and working down from broad specifications, creating code as I go, rather than up from fine grained models based on specific unit tests. Is this a reductionist approach?

When writing my features and scenarios I’ve noticed a tendency to follow the CRUD acronym common in data access layers: Create Read Update and Delete. The order of these processes is significant and my reasoning goes something like this……

I can’t really expect to read the contents of an entity before I’ve generated the code to create it. Now I’ve created it, I’m not going to try to edit this same entity unless I can actually read it. I can read what I’ve got, but I might want to edit those contents, and delete comes last…… because it just does, I guess the order of “UD” is negotiable, but this way it’s easier to pronounce.

You get the general picture, but this is just the approach I’ve adopted through trial and lots of error. It’s far from perfect, so how do you use behaviour to lead the code?

I’ve used Ruby for scripting, and deploying PHP applications with custom Capistrano recipes for years now, but I’ve never tried any of the available web frameworks.

This week I switched to Ruby on Rails, and I’ve accomplished more in a couple of days than in a couple of months with CodeIgniter.

I’m not trying to claim that there’s anything fundamentally wrong with PHP, so don’t beat me up over it, but I find working with Ruby and Java much more intuitive, enjoyable and productive: it’s a personal choice, I feel more inspired.

I’m particularly loving the default support for unit, functional and integration testing; I now feel in control of my code and I’ve yet to explore the full range of testing frameworks and approaches available for Rails.

I know that CakePHP mirrors Rails functionality very closely, but I’m afraid it’s the PHP language that I find too ugly to love – personal choice again, don’t shoot – consequently this is one developer who may have written his last line of PHP code…… maybe.

I’m now hoping to have the first release of the nature and wildlife recording application I’ve been promising Clare for…… much too long, up and running in the next couple of weeks.

My experiences got me thinking about what I needed to code confidently. As a minimum, I need to know that everything works before committing code to version control, but security comes with regular testing, and this is no use unless everything is covered.

Based on web development frameworks using the nearly ubiquitous MVC design pattern, the logic and side effects at each application tier must be tested, and I came up with this list.

1. The Database tier schema, whether RDBMS, XML or anything else.
2. Data Access logic is usually implemented in models, but often uses built-in features of the framework, such as ActiveRecord.
3. Business logic is encapsulated in the models, libraries, and sometimes controllers.
4. Presentation logic at the server comprising controllers and their respective views.
5. Presentation and business logic at the client tier implemented by DOM scripting, mostly in JavaScript.
6. The actual data presentation at the client tier based on XHTML and CSS.

I’ve tried to order it from inside the application, working out from the data tier to the client, and it’s quite a list; I’d be interested to hear what I’ve missed.

Since this is a huge topic, I hope to write a series of posts isolating specific areas as I encounter them, and comparing tools and approaches. The first will look at how a few development frameworks in popular languages appear to measure up.

Unfortunately, testing anything other than libraries and models is difficult because there’s no way to access the another important type of object: controllers. CodeIgniter positively encourages using controllers to implement business logic, consequently not being able to test them is a serious anomaly.

Integrating a front-end testing framework, such as Selenium, might be the solution, but does that properly test the controller code? I don’t think it does; the target there is the presentation tier at the browser.

The lack of good code coverage bothers me a lot, but I continue to struggle on with CodeIgniter because I’ve found other PHP frameworks to be just as lacking. Is this a general problem with frameworks? I’m tempted to try Ruby on Rails next to find out.

Which programming platform to use for the server-side application? Whilst I have to admit that I’m not the greatest fan of PHP, it’s definitely the best option. Why? Because I need to run this application locally on a minimal server and PHP is available wherever you find Apache, and the skills should have some commercial value.

I’ve recently read a great deal about agile development, TDD and employing software design patterns. As part of this project I’d like to apply some of what I’ve learned.

A test framework.

Now I’m going to need a testing framework, and I’ve gone for SimpleTest. This framework not only provides unit testing, but the ability to create tests for web pages. I prefer to run my test suites from the command line, which is relatively easy to arrange with the TextReporter object. I’ve combined the whole thing with Apache Ant to automate most of the tasks in the project, including deployment.

Unfortunately, it appears that SimpleTest doesn’t play particularly well with PHP5, although they’re in the process of making the transition.

I’ve encountered the mass of error messages generated as the result of E_STRICT. This is easily solved by using a customised php.ini file as an option at the command prompt when executing the test code. Once this is done you can see the actual test messages!

A more significant problem is that the Mock object code cannot be called as static class methods in the way the documentation suggests. A little snooping through the code leads me to think that it’s due to PHP4 without the static keyword in the method headers required by PHP5. I don’t have a work-round for this, and I don’t want to have to alter all this code. I hope they address this as the transition to PHP5 continues, but at the moment my code is simple enough for me to write my own mocks.

When all is said and done, if you know how to use any of the xUnit test frameworks, SimpleTest is very easy to set-up and use.

Driving with tests.

Simple the tests may be, but using them to steer the direction of your coding effort takes a different mindset. The hardest part is learning which questions to ask when developing your tests. Asking the right questions about functionality will result in clean, precise code.

There’s always a temptation add just a little more functionality, but resist it. The point is to remain in control of the code at all times. When it’s not working, it must be because you’ve added new tests describing new functionality. The code should never contain functionality that hasn’t been demanded by a test. Good refactoring can produce beautiful code without breaking the tests — still in control.

I think I’m getting the hang of it in relatively simple cases, but there’s much more to learn. I’ve found it a very liberating way to develop software, whilst remaining in total control — you are using version control?

Patterns in the code

Whilst there are loads of MVC based frameworks out there, I want to know how it works first hand. This topic is worth an article of it’s own, and that’s what I’ll give it.

There’s a good chance that the core application model will need to implement a facade pattern, but lets not make any assumptions.