Comments on: Cucumber: Why Bother?

By: Jared

Jared — Wed, 06 Apr 2011 01:35:03 +0000

http://www.software-testing.com.au/blog/2010/08/31/does-cucumber-suck/

I’m yet to be convinced it’s not a tool that has a very narrow area of benefit, being ridiculously overused and adding substantial cost to trivial tests. On the plus side, it’s reminding people that they should pay attention to behaviour, but I suspect a lot of people are really unclear on how much behaviour they should be testing.

One tip for maintainability would be to abstract your data. This would let you write things like

‘Given an account with available funds…’

As it stands, it’s not clear to me whether the dollar amounts for withdrawal are pertinent details of the test, or just noise.

By: Matt

Matt — Tue, 05 Apr 2011 20:50:33 +0000

@Siggeb, @unclebob I'm absolutely advocating that all the writing is done collaboratively. The features are the place where you document the discussions you've had together. I want that documentation to feel as accessible as possible to people how can't (and don't want to have to) read code.

@Nat, @ben fair cop, that code sample is a bit of a straw man, but even with a sweet Ruby DSL for expressing your tests, you're still going to put off many non-technical readers, in my experience.

By: Siggeb

Siggeb — Tue, 05 Apr 2011 20:27:41 +0000

I would say that like many other things, this depends on the context. But for me, Cucumber is a collaboration tool more than its anything else.

"The benefit is clarity: by separating the what (the features) from the how (the ruby automation code), you keep each part simpler and easier for its target audience to understand."

This said, I think the most important thing you should avoid is making the two target audiences write those things separately. The gherkin features should be the collaborative environment of discussions and decision on what the functionality should be. Only when you discuss those things between BA/QA/Dev you will develop the common understanding you need to build great software.

To sum up, Samnang Chhun, if QA/BA/Client dont have time to look at the cucumber features/tests, they dont know what their job is, and I would teach them the value of being a part of it. If they dont understand that this will make it possible for them to ditch parts of their own tool for test cases/requirements, I would fire them.

By: Samnang Chhun

Samnang Chhun — Sat, 02 Apr 2011 03:26:47 +0000

I agree, some of QA/BA/client don't have time to look at the tests, so why do we need to write another extra layer to increase my app's complexity.

By: Andrew

Andrew — Thu, 31 Mar 2011 19:57:33 +0000

I completely agree. Cucumber features make it easy to read what is actually going on. And easy to reuse common step definitions. We use Cucumber and Selenium for testing our PHP applications. Previously, we wrote Selenium tests in PHP and they were so hard to read and maintain that we gave up on Selenium testing altogether! Once we started using Cucumber (a Ruby library for testing our PHP code) we can actually read the tests and track down which features have changed and update our tests accordingly. Much easier to maintain by using this feature/step-definition abstraction than writing tests all in PHP.

By: Ben Biddington

Ben Biddington — Wed, 30 Mar 2011 23:54:36 +0000

(Oh dear, formatting fail, sorry.)

By: Ben Biddington

Ben Biddington — Wed, 30 Mar 2011 23:53:20 +0000

Applying extract method yields:

class WithdrawlTests < Test::Unit::TestCase
  def test_attempt_widthrawl_using_stolen_card
    given_I_have_$100_in_my_account
    given_I_have_a_stolen_card
    when_I_request_$50
    then_my_card_is_not_returned
    then_I_am_told_to_contact_the_bank
  end
 
  def given_I_have_$100_in_my_account 
    @bank = Bank.new
    @account = Account.new(@bank)
    @account.deposit(100)
  end
 
  def given_I_have_a_stolen_card 
    @card = DebitCard.new(account)
    @bank.lock_out(card)
  end
 
  def when_I_request_$50
    @atm = Atm.new(@bank)
    @atm.insert_card(@card)
    @atm.enter_pin(@card.pin)
    @atm.withdraw(50)
  end
 
  def then_my_card_is_not_returned 
    assert @atm.card_withheld?, "Expected the card to be withheld by the ATM"
  end
 
  def then_I_am_told_to_contact_the_bank
    assert_equal "Please contact the bank.", @atm.message_on_screen
  end
end

By: Simon Rentzke

Simon Rentzke — Wed, 30 Mar 2011 23:38:58 +0000

You could have setup your test to read more better. How about:

def test_attempt_withdrawl_using_stolen_card
  @account.deposit(100)
  @atm.authenticate(@cancelled_card)
  @atm.withdraw(50)
  assert @atm.card_withheld?, true
  assert_equal "Please contact the bank.", @atm.message_on_screen
end

Any easier? I think you could simplify this even further, and then even more by using shoulda. I think an analyst could be taught how to read this, most analysts I have worked with could understand this. Also if developers know that an analyst will be reading their test case - they'll strive to keep it more readable. That has a great knock-on effect as it forces the developer to think about naming conventions - and structure of the the system. It has worked for me in the past, but perhaps I've only worked with tech-savvy analysts?

By: Uncle Bob

Uncle Bob — Wed, 30 Mar 2011 23:04:10 +0000

The real issue is that programmers should NOT be writing these tests. They should be written by BA/QA. I know I'm dreaming. But it's a good dream.

By: Nat

Nat — Wed, 30 Mar 2011 22:07:20 +0000

You don't have to write your Ruby like that! You could refactor it so that analysts who cannot program can read it as easilly as the cucumber spec. Because you're not restricted to Cucumber's stilted style, a refactored Ruby version could be more expressive. I've done it in Java, so it should be easy in Ruby.