CenturyLinkLabs/panamax-api — pull request #256 by dpetersen (2014-11-26 19:04:34+00:00)
Title: Upgrade to rspec3 without mock/stub upgrade.

I had a conversation with @dharmamike about new and old stubbing syntax, and it got me wondering what it would take to upgrade the API to the latest version of Rspec. It turns out that API has a fair amount of the new syntax already(`expect(object).to receive(:method)`), which I didn't even know was available in 2.x. It also turns out that Rspec 3 allows you to use the old and new syntax in a mix without deprecation warnings as long as you specifically configure it to allow both.

This seems like a good half-step upgrade, although I am going to take a shot at upgrading to the newer syntax throughout. They have made it clear that the new syntax is their recommended style, even though the old is allowed.

Most of this PR is straightforward. I specifically did not want to screw around refactoring any tests. I did the minimum to get them passing again. We use two styles of testing that have been ripped from rspec core:
* *its* - e.g. `its(:color) { should eq("blue") }`
* *collections* - e.g. `expect(my_array).to have(1).item` and `expect(model).to have(1).error_on(:foo)`

They have both been gemified, but I only brought in the first. I'm on the fence about it, but I figured the fewer gems the better. The tests that used the collection methods can be very easily rewritten. It hides from you the fact that it checks your models for validity before checking for errors, but you could argue that it's helpful to know the fact that your errors aren't available until `valid?` is called. If you've ever gotten bitten by that one, it sucks.