Sunday, December 12, 2010

Rspec 2 at Wellrailed

I gave a talk to Wellrailed at the end of October on Rspec 2 which drew the largest crowd that Wellrailed has had in a while. I was hoping to put a shiny video of the event up here, but unfortunately the sound didn't come out. Here's a brief recap of what I said instead.

I had two distinct segments in my talk in that I started off talking about TDD for a while to try and convince people of it before moving on to the nitty gritty of Rspec 2. So that they could really understand some of the philosophical stuff that goes on in Rspec and how it's best to work with it. Using a tool right is by far the best way to avoid coming across difficult problems.

There was quite a spread of Rails and Rspec experience in the crowd from a couple of people who knew very little Rails all the way up to people with massive test suites that wanted just any useful extra things I could throw their way. I think I managed to give everyone something but it is one good point about larger gatherings like Rails camp (Tickets available now for Rails Camp NZ) that you have enough people to split up and focus on things a bit more.

One of the things that seems to be happening with Rspec is that it's getting a larger number of nuanced ways of matching things that make test failures easy to understand. It's much easier to see what's gone wrong if the error message is " should be valid but is not" rather than "false should == true" as would happen if you just asserted the result of valid. By having an intuitive error you'll start thinking about what might be wrong and the possible fix sooner which speeds development up. Unfortunately this plethora of options does make the system much more scary for someone just picking up the framework.

It was also a great opportunity for me to pick up some new shiny Rspec tricks. I'm particularly happy with the addition of importance filters for managing which groups of tests run when in Rspec. Being able to easily have you default autotest not run slow tests or ones that rely on some external resource is a vast improvement for anyone who has had to deal with the growth of their test suite on a larger project.

I continue to happily proselytise TDD. It's great that more and more people are open to it and joining in and I didn't have anyone loudly disagreeing with the concept for a change.

Well
(Yeah, the slides are pretty horrible. In my defense I mostly stayed on a couple of the more content free ones while I talked. Going to have to look at making better ones now that I've read Presentation Zen though)