I've done integration testing just about every way I can think of. I've "cuked it wrong". I've used plain rspec. I've used rspec with features. I've written an

I've done integration testing just about every way I can think of. I've "cuked it wrong". I've used plain rspec. I've used rspec with features. I've written an equivalent framework for use in a test::unit shop. 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.