DHH on Unit Testing : Is RSpec indeed needlessly complicated?

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 :)

It's a matter of personal taste.

I like to write easy cucumber tests without worrying about details. Just testing the "happy" paths of my app. (portable, understandable, slow)

I leave the details to Test/Unit. (easy, fast)

It takes more time to understand:

get :products, :session => @session_id_for_product_bananaassert_select "table" do  assert_select "td#name", "Banana"end

instead of

When I go to the banana pageThen I should see "Banana"

Sure those tests are not equal but who cares whether "Banana" is in a div or a table or doesn't have the right html-id.

I dont' like functional tests because after refactoring, the id's could be gone, the session expectation could be changed. If that's the case you will need to refactor your code AND tests. If you'd use cucumber you wouldn't have to change your scenario's.