I happen to be a subscriber of Ruby Inside, since I'm particularly interested in Rails. Yesterday, the creator of Rails, David Heinemeier Hansson, pretty much said that he's just using test/unit. I would understand that, since it's Rails internal, but he seems to have given a strong opinion. He believes that RSpec and Cucumber are needlessly complicated.
I would normally not pay much attention, but it depends on who says something. I respect Hansson a lot and his opinion got me thinking. When I started with Rails, I never really looked into test/unit. Just RSpec and Cucumber.
And that is why I want your insight. Do you think that RSpec is indeed complicated for not much added value? Does writing test/unit take less time and effort?
My recommendation would be to use either Shoulda (extends Test::Unit) or RSpec with Capybara, and -no- Cucumber.
I think that the use of either RSpec or Shoulda for nested contexts is definitely worth doing. RSpec is definitely heavy-weight (perhaps overweight) though, and I'm on the fence with it for that reason.
Cucumber, I've finally come to understand, is waaay more cumbersome than it's usually worth. You can accomplish what you need more simply and robustly with plain ol' integration tests and Capybara. Remember -- Capybara != Cucumber, and Capybara is quite capable all on its own.
Shoulda is nice, because it simply adds conveniences to the standard Test::Unit framework, and is therefore much lighter-weight than RSpec (technically, each solves a different set of problems, but they both provide nested-context capabilities). RSpec has the advantage of making assertions read more naturally, and also generating more helpful failure messages in many cases, without the need for writing message arguments on the assertions.
Also, remember that Cucumber does not actually require RSpec, so if you want to keep using Cucumber, you can do that with just Test::Unit. Choices abound.
It's all about semantics. RSpec and Test::Unit are similar functionally. Personally I've always preferred RSpec because I found it more natural to write tests using it. I also like the simplicity of writing custom matchers, and the default matchers provided are useful.
Cucumber is a different beast entirely. Yes it's fairly cumbersome and becomes hard to maintain if you don't organise your step definitions properly but it does have one very strong use case and that is when your client is writing your specifications.
I've worked on projects where the client has been writing Cucumber scenarios together with one of our QA team. As a non-technical person it's an extremely approachable and natural way to specify user stories in the code. Cucumber really helped us walk the walk when it came to following our agile practices. The quality of the end product benefitted from that but no I do not like Cucumber as a developer :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With