Ivan Moore

This started with the presenter giving his experiences with tracking on agile projects and then became an open discussion with those present sharing their thoughts and experiences.

A couple of points that struck me:

• you can track done story points on a graph, if the graph flatlines for a few days it maybe an indication that the stories are too big – the team I’m in have recently (prior to XP Day) started tracking done story points in addition to tracking remaining estimated hours, I was dubious about what we would get from this but it’ll now be interesting to see what we get
• mark cards as done and not done (or a finer resolution, under development, ready for test, tested etc), e.g. using little coloured stickers, but don’t overwrite or replace one mark with another. If you see cards appearing with the same mark on them multiple times indicating they are bouncing back and forwards between states, e.g. not done and done, it’s a good indication there’s a problem somewhere.

One thing that did strike me was how comfortable everyone was in the room with doing different things at different times and in different situations – more than once someone started with “sometimes I’ve …” and the inexact nature of plans. I know I shouldn’t be surprised by this – responding to change over following a plan, continuous feedback and adjustment are all part of Agile – but it was reassuring to see, working in a company that’s trying to become Agile but with a long way to go where fixed scope and timescales still predominate where most still believe in the infallibility of ‘the plan’.

Nat Pryce and Steve Freeman

I won’t write much about this because should this be presented again and you attend knowing too much about it, it will, I think, spoil it a bit – but if you do get a chance to see this do, Nat and Steve very effectively make their point.
So, hopefully, without giving things away…

Do your tests really communicate their intent?

• don’t use magic numbers in your tests just as you wouldn’t in your production code
• consider creating value types where you might typically use primitive types – a parameter to a method of type PhoneNumber rather than just a simple String conveys far more information, even if the PhoneNumber class is just a very simple wrapper around a String
• a comment here and there can make a big difference
• where a method under test is returning a numerical result based on values passed to the method, express the expected result in terms of the values passed to the method, e.g. assertEquals(2+2, billingService.caclculateCharge(2,2)) rather than assertEquals(4, billingService.caclculateCharge(2,2))

Dan North, Joe Walnes

There’s nothing wrong with having asserts in your tests that are unrelated to what you are actually trying to test but instead check the sanity of your test so that when they fail it’s easier to workout why.

As an example:

You have a test that logs into the system, goes to a search page, fills it in and checks the results. One day this test suddenly starts to fail, it turns out that the password for the user the test is login in as has expired, if after the login step you checked that the title of the page was “Welcome” proving that you had logged in successfully it would be very easy to spot that the test failed as a result of failing to log in rather than something being wrong with the search functionality.

How fast do your acceptance tests run? Joe’s rule of thumb is about 100 ATs/minute.

How do you go about setting up test data – do you do inserts directly into the database using SQL or do your tests click about in the GUI creating data for use later in the test? Why not use the code for the domain model you’ve written to set up the data – so you’ve written your own blogging system, rather than poking around in the database to create a blog entry with a comment for the test or getting the test to click around in the GUI to create the blog entry and comment why not just instantiate a new Blog domain object and Comment object and persist them to the database using your BlogDAO object. Of course to be able to do this your AT must be implemented in the same language as your domain language but I think thats quite a strong argument for doing so (or of course now if your system is implemented in Java you can write your tests in Ruby but still access you domain code via the magic of JRuby ).

How readable are your ATs? Could someone who doesn’t know, for example, Java read them? With the grouping of steps into carefully named methods you can end up with something very readable.

Implicit assumptions:

You complete a story, later you think of a new scenario, do you reopen the old story? If this situation comes up it suggests that your initial story had an implicit assumption so rename your original story to include that assumption explicit and create a new story for the other case. e.g. you write a story for withdrawing money from an ATM – WithdrawMoneyFromATM. You then think “What happens if the network connection from the ATM to the bank is flaky?”. The original story had the implicit assumption that the ATM was working correctly so rename it WithdrawMoneyFromWorkingATM making it explicit that it’s for a working ATM and add a second story WithdrawMoneyFromFlakyATM.
Given – When – Then – Behaviour Driven Development

Dan explained the ideas behind Behaviour-Driven Development and the idea of splitting a test down into a precondition – the given – an event – the when – and the expected result – the then. I quite like this idea, if done properly it makes the test very readable. Some code was presented from jBehave, a BDD tool for Java, illustrating the idea. The code (if I understood right) represented the latest thinking of those working on JBehave and was being carried out in private, what is present on the jBehave site is out of date.

DBDeploy – a new open source tool from ThoughtWorks – whilst in its current form it’s new but variations of it have been used in numerous projects for a while.

It currently supports 4 databases – Oracle, SQLServer, Hypersonic, Sybase, more coming soon including MySQL and ProgresSQL.

Incremental changes are specified, as ANSI standard SQL, in files named with numerical prefixes. DBDeploy checks which have already been applied and generates an output file containing the changes as database vendor specific SQL that have not yet been applied. This output file can then be applied, after being examined by a DBA if necessary, to the database.
DBDeploy also supports downgrades. Think carefully before using this capability (and this advice applies to any similar tool) – do you really need to be able to rollback a change. The time you really need a script to undo changes is when the easy option of doing an export before the upgrade and reimporting it if something goes wrong is not possible due to the large volume of data involved would mean it takes too long.

If you use the downgrade functionality don’t forget you need to test peforming downgrades as well as upgrades.

There were numerous interesting sessions and, with the exception of a couple that required an additional fee, you were free to choose which ones you attended. There were 4 streams run in parallel, the real problem was deciding which of the sessions not to attend. Fortunately I was there with a couple of colleagues so even though I didn’t manage to attend all that I was interested in I did get to hear about them second hand.

More to follow in other posts on the individual sessions.
One general thought that did strike me about the sessions was that most had two presenters, and by that I don’t mean one stood up and talked a bit then sat down and the other then did their bit but rather one person said something, the other would elaborate, give a counter view or just start on the next point and this alternating would carry on through the presentation. This wasn’t the first time I’d seen a presentation done in this way, that one done by Martin Fowler and Dan North which I think I’d have to class as the best presentation I’ve seen. I’m not sure why it seems to work so well, is it because you feel in some way, even if it is passive, part of a conversation rather than just someone being talked at, is it as simple as a little variety helps keep ones attention or is it because of the dynamic between the presenters? Maybe when I’ve seen it done badly it’ll be apparent what makes it work.

Based on this years I’ll certainly try to attend next years and would recommend it to anyone else involved in Agile, just don’t book your place before I get mine!