Thursday 30th meeting : Charlie Poole - When Tests seem hard

I'm thrilled to announce that Agile & Nunit guru Charlie Poole has kindly offered to speak to AgileScotland while he is in the UK to present at the XP2005 conference*. The meeting will be held on Thursday 30th June, at 7:30 (but try to arrive early) in the Currie and Brown offices, Ground Floor, No. 1 Osborne Terrace, Edinburgh, eh12 5hg.

This should be a particularily good one ...

Clarke - www.clarkeching.com

When Tests Seem Hard( And Why That’s a Good Thing )
It doesn’t take long for developers exposed to automated testing to become test-infected. And it doesn’t take much longer to be converted to the cycle of TDD. But then, we hit a wall. There are areas that seem much harder than others to test. One such wall is GUI testing, and that’s what I’ll use for examples in this talk.

So why is GUI hard – or perceived as such? Why does any kind of testing seem hard?
Based on my own extensive experience running into walls, I offer the following as possibilities:

Programmer testing is focused – or should be focused – on the expression of small bits of intention about what the code needs to do next. Small bits of intention generally mean small bits of code, tested in isolation.

But of course, various dependencies creep in. Classes are coupled tightly to other classes. Entire chains of objects need to be created before even the simplest operation can be performed. We are forced – or appear to be forced – to test many things together when we would prefer to test only one.

GUI code is a good example of this. Tempted by an overly naïve understanding of “the simplest thing” and possibly encouraged by our toolkits, we end up putting pieces of domain logic into our so-called gui layer. Even when this obvious pitfall is avoided, we often end up with extensive bits of ui logic – described a bit further below – mixed in with the code that controls the content and appearance of our user interface.

It’s definitely painful to test when these kinds of dependencies have crept in. And a good thing too, because just as with our bodies, testing pain serves the purpose of telling us that something is wrong and that maybe we should stop doing the thing that hurts us.

Charlie Poole has spent more than 30 years as a software developer, designer, project manager, trainer and coach. He works through his own company, Poole Consulting , in the US and recently joined Dublin-based Exoftware as a mentor, in order to work with European clients. He is one of the authors of the NUnit testing framework for .NET.

* Charlie is also delivering an Agile Workshop with Mary Poppendieck in Dublin on June 28 and in London on June 29.