The Co-operative Bank online banking… again (!)

The uselessness of Co-op Bank’s online business banking is a long running saga on my blog.

The latest twist, which I noticed some weeks ago, is as follows. Previously lots of problems with CORBA_NO_RESOURCES errors coming back to you when you try to do stuff.

It doesn’t take an IT consultant to guess this means their servers are overloaded.

Which is why I am a little cynical when I see that they have changed all the payment reporting screens to default to show only payments from TODAY by default. Where you used to see a history of recent payments immediately, you always have to select a date range and do a report now.

Why cynical? Well you could argue that this was a cheap way to further inconvenience customers reduce load on the database systems.

Dear Co-op bank. I’m getting more and more people contacting me via blog comments saying how fed up they are. You are going to lose a lot of business if you don’t sort this out.

So wrong its not even funny

I just read this at Wired, about US Military desire for a robot that children of servicemen and women can “talk” to, to reduce the anxiety of their loved one being away killing or being killed in some conflict.

They obviously envisage some delivery problems with fighting robots for the battlefield, so this smaller more attainable robot project is going to tide over loved ones until such a point robots fight the wars for us.

Oh, but do you get to keep the little robot once your loved one returns home, or worse dies in the field? Does it become some kind of sick stand-in for them?

These people are nuts. If you have to go out of your way to try to make things OK, you have to think about what was wrong in the first place.

Functional testing in Grails just got a bit sexier

Ok so here’s the 1.0 release in the spirit of “don’t worry be crappy” (can’t use that phrase enough these days) of a new functional testing plugin for Grails.

Actually its far from crappy already.

I have developed this partly as part of my work for my generous client Historic Futures Ltd. who agreed to open source this.

I plan to continue improving and maintaining it personally. It’s surely a bit rough around the edges but the benefits should be pretty obvious to those who use it.

So what are you waiting for? Run:

grails install-plugin functional-test

See the documentation

…but in a nutshell it is HTTP testing with HtmlUnit under the hood but the rest is pure groovy smarts, leveraging standard JUnit.

Example:

import functionaltestplugin.*
class TwitterTests extends FunctionalTestCase {
  void testSearch() {
    get('http://www.twitter.com')

    click "Search"

    assertStatus 200
    assertContentContains "search"

    form('searchForm') {
      q = "#grails"
      click "Search"
    }

    assertStatus 200
    assertContentContains "#grails"
  }
}

What’s special about this?

1. Simplicity and “elasticity” by default = less fragile functional tests as a result
2. Simple compact DSL/methods to learn – it tries to “do the right thing”. Let’s face it writing tests is really boring.
3. Ability to get/post directly without browsing to a page first. eg REST testing
4. No .properties configs

…and one more thing URL stacktrace. When a test fails the report includes a stack of the URLs at the point of failure. The xxx-out.txt file contains request parameters+headers, content received etc. This feature will be expanded in future to allow a proper request/response chain autopsy.

Caveats – things I definitely want to sort out pronto:

• currently test output is a bit ropey, I would like to do much nicer stuff with custom output xml and rendering
• no simple way to set post body
• no simple way to parse out json/xml responses yet

All this and more will come, with your support! Contribs also welcome!

ENJOY!