IBBRE

In last week’s post, I described some mistakes and blunders that I had made while writing code for IBBRE.

It seems clear what the main lesson is – I need to do more testing before updating the main server. I can try running the system on my local machine, or on the “beta” server that we use for making new functionality available before unleashing it on the whole IBBRE community. But these will not get the extensive use that the main server receives.

Possibly the most common problem that we get is access control. Different users are allowed to access different parts of the site, with admin users being able to access everything, and regular users able to access just the basics. There are a couple of other access levels in between: researcher and moderator. The main testing procedure is just to log on as these user types on a test server, and see if the new functionality is available or not. But if you’re in a hurry, it’s easy to forget one of the user types. I suspect that we are usually erring on the side of caution, as I will always log in as an admin, and see that it’s possible to do the new function X (which is intended for all users), but forget to log in as a regular user. But if there’s an admin-only function, then I’ll automatically be more careful. But that’s no real excuse, of course.

The best solution would be to automate these tests using the Grails testing framework. The book “Grails in Action” by Smith and Ledbrook has a good chapter on access control (ch. 10) including how to test it. It’s my new year’s resolution (or Friday 13th resolution at least…), to automatically test the access control on new functionality from now on.

And finally, I think testing should be planned for from the start. It’s very easy not to do testing properly, either because it seems like a chore compared to writing code, or because there never seems to be enough time. But possibly the main reason that there’s not enough time is because you have to spend lots of time fixing old code…? Either way, I think that testing and documenting should be built into the project plan, with enough time allocated to do it, and some deliverables to make sure that it’s done. And the tests should probably be written up front: test driven development.

Next week, I’ve got some more Grails gotchas that I found this week. Note: gotchas, not mistakes – as the behaviour that I expected (but didn’t get), seemed very reasonable to expect…

Tags: Grails (framework), Programming, Test-driven development

This entry was posted on Friday, August 13th, 2010 at 1:19 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.