So it seems like the new hot way to do integration testing with RSpec + Features [1]. Any sources on doing this well? I find myself writing methods that read like cucumber.
[1] http://pivotallabs.com/getting-by-with-rspec-feature-specs/
[1] http://pivotallabs.com/getting-by-with-rspec-feature-specs/
As of today, we're in the process of ripping out all of our Cucumber tests and replacing them all with RSpec features.
In our largish company we found that product owners generally didn't care about reading Cucumber features. The definition of the products and how they works are defined in the agile boards and cards we write together, along with documentation and wireframes which live on our intranet.
They're all fine. They get the job done.
I've also done acceptance testing with all of the above, and it works great as well. It's a language thing. My AT's are rarely more than half a dozen lines, and many of them are less than 5.
Whether or not you should do ATs at all really comes down to the process culture. If you have someone signing off on whether a feature works, I think it's great to do. If you're the only one signing off, I think it's worth doing as a tool to help implement the feature, but then convert it to an integration test, trim the AT to be part of a very limited suite, or toss it altogether. They're not unit tests, and not meant to be voluminous documentation of your app. That doesn't mean don't do them. It means learn how to do them well.
An example that's similar to what I do: http://youtu.be/e9tfC-gLW8c?t=8m28s
I'm not wholly convinced its the best way to go, but it does offer some advantages.
RSpec verbs and scoping still messes with my head, and I always have to debug why the tests are breaking.