Noel Rappin Writes Here

Book Status

The Shoulda chapter is draft complete, after a slight restructuring to change the emphasis of the chapter, and a lot of syntax changes. My previous version of the chapter was written before Shoulda went in the direction of RSpec compatibility and so there were a lot of syntax changes that needed to be made, particularly to the way you create Shoulda extensions, which used to be much simpler.

Promotion

WindyCityRails has extended the early bird pricing through August 11, because of the addition of Ryan Singer from 37signals to the schedule. Those of you who are obsessively following the schedule with an eye on how it affects me – which, I suppose, is pretty much just me – now see that my tutorial session no longer overlaps with Yehuda Katz, but does overlap with Ryan Singer.

My tutorial is called “Testing in a Legacy Environment”, and will talk about adding TDD/BDD to an existing code base, with a focus on practical ideas and working with an actual fake legacy code base. I think it’ll be a lot of fun, and I understand that tickets are still available. So register.

Editiorializing

One of the issues that made the Shoulda chapter require some rework is that the Shoulda team has changed how they think of Shoulda. I’m paraphrasing here, but I think it’s gone from “RSpec alternative for use with Test::Unit” to “Tool for single-assertion shoulda-style testing in either library. But especially in RSpec.”

On the one hand, I really like having Shoulda syntax available in RSpec. It makes RSpec a lot more interesting to me, and I like the way single-assertion style looks in RSpec. That said, and also knowing that the Should team owes me nothing and absolutely needs to write the tool they want, I do think I’ll miss having Shoulda as a full alternative to RSpec.

Let me back up. When I first started using Rails, I used Test::Unit because it was most similar to the tools I had been using (JUint, PyUnit, SUnit). As I got integrated into the Rails community, I became aware of RSpec, and thought it looked cool.

My first experience or two with RSpec went badly. RSpec, at that time, was very heavily into a mockist style of testing (or at least that’s how it seemed to me), and for whatever reason I really struggled with making mockist testing work for me in any kind of reasonable flow.

If I remember correctly, Shoulda came out while I was in the middle of my first major Rails project as a consultant. I liked the single-assertion style immediately, and also liked the ability to get some RSpec flexibility without having to make the commitment to RSpec. Shoulda was much easier to add to an existing project.

Shoulda got popular quickly, I remember a talk at RailsConf ‘08 comparing all the testing tools and concluding that Shoulda’s big advantage over RSpec was that it was much easier to extend. Shortly after that, as I got into a position where people would ask me questions about testing, “which framework should I use” was a popular first question.

When I started writing the Lulu book, it made perfect sense to have the book not focus on RSpec, since the non-RSpec tools at the time had very close parity to the RSpec feature set. I believed (still do) that it makes sense for a new user to start with the baseline Test::Unit features because they are simpler and because most Rails programmers know them. The fact that there was also already an RSpec book in development, I admit, was also a consideration.

A couple of interrelated things happened over time:

The Test::Unit ecosystem, including Shoulda, Jeremy McAnally’s context, and other add-ons like Zebra basically stopped being worked on.

Cucumber became very popular, and integrates with RSpec better than Test::Unit, making the RSpec ecosystem stronger.

I had my first really good experience with RSpec, and I’m now much more comfortable with it than I was. There are a lot of RSpec features I didn’t know about before that I love now.

As a result, or at least at the same time, I don’t get asked the question about which framework to use any more.

In some ways this is too bad, some people genuinely don’t like RSpec syntax, and I think that if somebody was to fork the pre-RSpec version of Shoulda and maintain it, that would still be a viable tool for some members of the community. At the same time, it’s not like I’m jumping up and down to be that maintainer, so take that with a grain of salt.

Anyway, this leaves me in a weird place, with a Rails test book that covers RSpec, but isn’t really about RSpec. I think that a lot of the advice and tool coverage in the book is applicable to RSpec or Test::Unit users, but I worry that Rails users who are already in the RSpec camp will assume that my book has nothing for them. (Note: I think it does. But then I would, wouldn’t I?) But this isn’t the only decision I made in the book that looks different a year or so later. (For example, I picked Machinist over factory_girl as factory tool to emphasize. I might have to redo that one also…)

I’m not sure what my point is by now. I like RSpec, and I like Shoulda, and I even like them together. But I also liked them apart. And what makes writing in this community both so much fun and so agonizing is that everything changes all the time.