The third AAFTT workshop today and I was lucky enough to participate. This was the first one I was at, but I had seen the videos from the first one before. The format was an open space which was a bit chaotic, but I think everyone got what they were looking for out of it which means it was a success.

I spent the morning session with a couple other people in what was labelled ‘Advanced Fitnesse’, but it was more tips-n-tricks and lessons-learned about it which is was more useful I think. Here are the notes I took which don’t necessarily reflect everything, just the parts I kept.

  • Be careful with too descriptive fixture names on windows as there is a limit in length (on windows)
  • Structuring tests is a hard problem to solve. By functional area? By persona? By tags?
  • I actually really like the idea of tagging tests
  • Write a single unit test for the data access stuff to ensure the linkage works then stub out that whole section of dependency
  • When talking to business folk, focus on the story
  • Think of Fitnesse as a substitute UI. This substitution forces business logic out of the UI and into the app — where it belongs
  • Useful to have fixtures with no teardown section as an assistant for environment prep/exploration
  • Idea (from I think, the Cucumber world) – test results are sized according to duration, so slow tests are shown in a huge font as a bit indicator to refactor right here
  • Trick – Don’t embed user messages in the scripts, instead use the id of it. This way the message can change, but the script doesn’t break.
  • (Maybe) Trick – Don’t put exception handling in your fixture. Let it blow up.

After lunch I sat in on half of the Cucumber demo/introduction. I had seen all the twitter love on it but never actually used it before. And it is pretty cool. What was cooler was that Aslak, the principle developer of it, was the one doing the demo. I’m having a bit of a hard time figuring out how we would use it for our project, but BDD in general is kinda magic to me still. Certainly nice syntax on the user facing side though.

The rest of the day I spent talking to Jason Huggins (of Selenium infamy) about what to do with the IDE. The answer that seemed to arise is that we can’t ‘kill’ the IDE in general as too many people use it and it a large driver of Selenium’s success. But what can be done is make it more obvious to users that the IDE is not the end of the Selenium chain, but the beginning. The two metaphors floating around are ‘training wheels’ and ‘tutor aircraft’. But those are even flawed as there are situations where the IDE is actually the only step necessary. A better take that is starting to emerge is around complexity. If the IDE had a visual indicator that the script was getting ‘complex’ and that RC is starting to become a better solution, then maybe we can get people further up the value chain faster. And with a real language (that RC forces), you would be able to leverage real IDEs as such which a lot of people seem to be clambering for.

All in all, a good day. Got to meet a number of people in real-life for the first time, met a number I had not met online or in person yet and saw a couple tools I haven’t had opportunity to use yet.