Every once in a while, I’m working on a project with Cucumber in place, and I wonder if I should be adding an rspec feature spec, or venturing into Cucumber land.
Please don’t use Cucumber: “Gherkin is really just glorified comments.” Argues costs far outweigh benefits.
Overall, a limited benefit for high cost suggests RSpec feature specs (Capybara) are the sweet spot for integration testing. @geoffevason, anything to add?
Most of the arguments in the first article apply just as much to rspec or test unit as they do to cucumber. They basically boil down the fact that people cb write bad, poorly organized code. You can just as easily have repeated code in rspec, abstractions or methods that you forgot about it are hard to communicate. It’s just the nature of software. The point about an extra abstraction to the routes is actually a valid point though.
So, the reasons you might like cucumber over rspec are exactly the same as the reasons you might like rspec over test unit - syntax and personal preference.
I love to think about the user experience first - and being able to write a whole test in English so I can just focus on the user. To do this I also use very abstract step definitions, and aim for clarity over cleverness for steps (no crazy regex).
As for editors - ruby mine just does fine with steps. No reason other editors can’t do it too.
@geoffevason I think the regexp matching just does not outweigh the extra complexity over just creating methods in Ruby and then including them in the spec file. One thing to keep in mind is that when requiring a file with common methods, the path must be relative to the whole spec directory. Even better is to simply put
require_relative("./shared_methods")
The bottom line for me is that if the business folks don’t need or want to read the cucumber specs, then Ruby methods and other language constructs are a much better tool for DRY’ing up and clarifying tests.
We went through this discussion at my company. I tried creating a parallel Cucumber suite of specs but got burnt out on it. It seems really nice at first for doing very very high level specs, but you’re right that if business people aren’t invested in reading in it the value is lost. As a programmer, its easier to read and verify what is going on in an RSpec feature spec.
Cucumber is first and foremost BDD. It forces you to write code from outside-in and puts the user experience in center stage. You end up with a software that meets all the requirements, no more and no less. The “no more” part is key to me - we, as engineers, often have a tendency to build functionality that’s not immediately needed, just because we think it’s “cool” or we think it might be useful, at some point. And in the process we forget that every line of code has a cost.
Cucumber also inherently brings structure to your tests. When working with a larger team with various levels of experience and proficiency, it’s nice to know that you can rely on your test framework to keep things in check.
All this is obviously doable with RSpec but it requires more discipline and consensus across the board.
@justin - I don’t think cucumber scenarios should’ve geared towards business or product owners. I think in the best case scenario - a business analyst can confirm (or even write) then. For me - its largely about BDD as @martin mentioned. Working in English forces me to think from the outside - and results in only writing the minimum amount of code.
I’ve seem cucumber stories and steps get really ugly though. This is especially true when too many people are writing them with their own style, and regexes are overused.
The same is true if rspec though. If too many people have different styles - the code suffers. What is missing from both rspec and cucumber are accepted patterns for style, structure, code organization, etc. any large project ought to have testing guidelines along with coding standards. (Eg - when is it okay to mock. When should code be shared, and where does it live. How do you name factories - especially those with relatins or sub factories. When do you use sub factories vs setting up data directly in a test. Etc)
Indeed - all tools have a cost - but they also have a reward.