New Location for Charlie Poole's session

Based on the emails that I've received, I suspect that Charlie Poole's session on Thursday night is going to be far too popular for our normal meeting space ... so I've found a new location with a bit more space.

All things being equal -  the room is free but the booking is not confirmed yet - we should be meeting in the Apex hotel just across the road from at Currie and Brown.  That is, it is just a  30 second walk from the normal meeting place.

Sorry about the late notice.  I will confirm the location tomorrow.  If you can't check your email between now and then ... just come to Currie and Brown at 1 Osbourne Terrace and one of us will be waiting outside to redirect you.

Clarke
p.s Thanks to Ali Law from Vison for kindly sponsoring our new (exhorbitantly priced) location.

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.