Motivation or Problem

Fri, 23 May 2008 11:30:59 +0100

Okay so I'm pleased to say that Alan Bradburne is helping out at Reeplay.it as we get ready to launch. I worked with Alan for all too brief a time while I was at Cominded but, due to the setup there, we never really had much opportunity to interact.

A few months ago, since we live pretty close to each other, we started hanging out at the Global Cafe in Reading on Wednesday afternoons. We both work from home which can be a little isolating so it was nice to be out and have someone else to work with. When I needed help with reeplay.it Alan was an obvious choice and, fortunately, he was able to fit us in with his other gigs.

It didn't take Alan long to realize what I was already quite uncomfortable about. The application I had written was suffering for lonedeveloperitis which is that peculiar disease that can affect a code base where the developer didn't have other people to chat things over with. I made a number of decisions, largely because I had to, that I later came to regret. The most serious of those was not paying sufficient attention to testing, especially of controllers.

That is not to say that nothing was tested. Far from it, I had tests for quite a lot of the functionality. Unfortunately Test::Unit doesn't give you much encouragement in how you structure your tests and I had reached the point where the tests were more a hindrance than a help in changing functionality. Sure I could check what breaks but they didn't guide me.

One of the first decisions we made together was to switch to RSpec. I think we both believe that the extra semantic guidance involved in RSpecs nestable describe is valuable since it offers so much more context allowing you to group together related specs. Also the shared behaviours, though I'm still getting my head around how to use them, suggest that this facility runs deep.

Watching Topfunky's RSpec basics and RSpec controllers and tools peepecode movies has helped a lot with getting acquianted with RSpec. One thing that comes across loudly is "Use mocks not fixtures" which, having gone through the pain of maintaining fixtures, seems like a blessing.

Although I've used Mocha quite a bit I decided we would go with RSpec's built in mock framework to make it easier to re-use the tutorials (also if I had trouble converting mock_model to work properly under Mocha). We've been going along good converting tests to specs and I think the resulting specs are clearer and better guides to the code.

However it's not all roses. Today I have spent 2 hours trying to write a spec for a controller action and it's been pain all the way. The issue was setting up all of the mocks, and related mocks, and related mocks to satisfy the operations the controller invokes. My inexperience probably makes this harder but it was a lot of trial and error.

I can look at this in two ways:

Using mocks & stubs for anything but the simplest case makes you long for the pain of maintaining fixtures, mock & stubs suck
Using mocks & stubs for anything but the simplest case makes you long for the pain of maintaining fixtures, so keep things simple stupid

It would be useful to know whether my unpleasant spec could be improved on it's own merits.. am I using RSpec's resources properly? I've not enough experience to judge.

As a motivation to keep things simple I can understand their value. It's just that it's very hard when you want to refactor something unpleasant (and in this case the controller clearly has wayyy too much responsibility) that you have to go through the pain of speccing the existing behaviour before you can actually change it.

I suppose this is the sharp end of behavioural modification :)

Curiouser and Curiouser! on rspec

Motivation or Problem