Testing POROs In Rails

A lot of smarter people than I have come up with the idea that moving your business logic out of framework based classes and into Plain Old Ruby Objects (POROs) is a Good Thing.

Being less tied to your framework makes upgrades easier. It also means you can test these objects without loading rails. That’s really the only way to get super fast unit tests. It’s also the only way to get true and isolated unit tests.

The problem is that even our PORO code will have some implicit dependencies on parts of rails. Some of these are Good Things that we don’t want to stamp out, others are just too annoying to work around in the PORO or its spec. This makes testing them in isolation difficult and awkward, which is a key indicator of a Bad Idea.

What we need is a compromising spec helper. One which brings in just enough rails so these niceties work as any rails developer might expect but not so much rails that it slows down the suite in any noticeable way. This lets our rails app be developed using common conventions and idioms but we also get a sick-fast Unit suite.

I’m figuring this out as I go, exploring through a toy application, but here’s what I’ve got so far:


11 Feb 2013, tagged with ruby