4 ms·

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

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/ http://pivotallabs.com/getting-by-with-rspec-feature-specs/

dpeck 13y ago
I wouldn't say I'm doing it well, but I'm doing it. I resolved to make myself do TDD for a few projects and today signed up for a month of Thoughtbots Learn program. They're big advocates of integration spec testing, and have written quite a bit about it. I'm not wholly convinced its the best way to go, but it does offer some advantages.
thisisauserid 13y ago
I do this with RSpec + PageObject: https://github.com/cheezy/page-object https://github.com/cheezy/page-object An example that's similar to what I do: http://youtu.be/e9tfC-gLW8c?t=8m28s http://youtu.be/e9tfC-gLW8c?t=8m28s
karmajunkie 13y ago
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.
foz 13y ago
In my frontend web team, we used Cucumber for over a year. We slowly came to the same conclusion - Cucumber tests are hard to maintain, run more slowly, and overall take more effort to develop. 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.
jsnk 13y ago
I use both RSpec and Cucumber often, and easiness wise, I think Cucumber is just easier to write. RSpec verbs and scoping still messes with my head, and I always have to debug why the tests are breaking.

dpeck 13y ago

I wouldn't say I'm doing it well, but I'm doing it. I resolved to make myself do TDD for a few projects and today signed up for a month of Thoughtbots Learn program. They're big advocates of integration spec testing, and have written quite a bit about it. I'm not wholly convinced its the best way to go, but it does offer some advantages.

thisisauserid 13y ago

I do this with RSpec + PageObject: https://github.com/cheezy/page-object https://github.com/cheezy/page-object An example that's similar to what I do: http://youtu.be/e9tfC-gLW8c?t=8m28s http://youtu.be/e9tfC-gLW8c?t=8m28s

karmajunkie 13y ago

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.

foz 13y ago

In my frontend web team, we used Cucumber for over a year. We slowly came to the same conclusion - Cucumber tests are hard to maintain, run more slowly, and overall take more effort to develop. 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.

jsnk 13y ago

I use both RSpec and Cucumber often, and easiness wise, I think Cucumber is just easier to write. RSpec verbs and scoping still messes with my head, and I always have to debug why the tests are breaking.