> Cucumber lets you write automated tests in plain language

No, it doesn't.

Or to be more precise: Cucumber lets you write your tests twice - once in something that isn't nearly as close "plain language" as it seems at first glance, and then again in a horrible mismash of regex spaghetti code that will make you wish you'd been born a thousand years before computers were invented.

I was forced to try to use it about 15 years ago and spent literally twice as much time debugging the testing framework as I did actually implementing code - velocity on actual feature development ground to a halt. I think the most hilarious part about this was that it was completely incapable of finding the most common class of problem we tended to run into at the time - cross-browser presentation issues.

One of the big problems you'll find if you try to use this trash is that nobody except a software engineer will be really able to write tests in a consistent enough way that you'll be able to implement them without a truly horrible regex soup: even if you can actually get a non-software-engineer to write cucumber tests for you (dubious), the non-engineer-types will write "given I'm logged in" for one test and then "given I have logged in" for another, and "given I gave gone through the login process" for a third. And it doesn't matter how many regexs you implement to try to cover all their variations in their language, or how clever your regexs are - the nature of natural language means there's near-infinite variations, and they'll come up with new and more annoying variations just when you start feeling confident. And that's before we even start talking about the ambiguity of natural language.

I did manage to find a decent use for cucumber-style language a couple of years ago, though - we started commenting our unit tests using this style:

  def test_something():
     """ test some thing """

     # given some prerequisite
     set_up_prerequisite()

     # when I perform some action
     perform_some_action()

     # then some condition should be true, because <reason>
     assert some_condition is True

At first I was dubious, given my previous experience, but I quickly found this to be a very nice way to document your unit tests and make them super-readable and easy to understand at a glance. And you don't even need to install any software to start doing it. I highly recommend it!

It's dashboard-oriented development for MBAs and PMPs.