What is a legitimate reason to use Cucumber?

Question

I've worked in several contracts where the client used Cucumber and I've often felt that the testing suite didn't really have a place in our stack.

From what I understand, business analysts/non-technical coworkers write up the tests and the developers make the step definitions work. My problem with this approach is the tests are never valid or terse enough to be used without rewriting the whole file.

Answer 1

You're right that it's a myth that non-technical people can write Gherkin (Cucumber, SpecFlow, Cuke4Duke) tests without help.

However, they can write requirements in a Given-When-Then format and they should still be able to read it after you've tidied them up, confirm that this is their intent and give more info/test cases, where necessary.

It's certainly legitimate in that sense.

But there are certainly times when the effort expended outweighs the benefits and you need to watch out for that.

Answer 2

I'd suggest letting the BAs write test requirements using Gherkin, and developers write the Unit Test.

I've had excellent luck using SpecFlow and having interested parties write the Business Case skeleton, and me just implementing it. That way, I can just pay attention to the code and not have to do a QA Lead's job as a programmer (I've been both in my career, and I don't like doing them both at the same time.)

Answer 3

The gherkin language (In order to.. I want .. so that ...; Given ... When ... then ...) used by cocumber and bdd is a way to write specs that a non technical business expert can understand and a software tool (like cucumber) can verify.

What is a legitimate reason to use Cucumber?

Using these is usfull to define acceptance criteria for your work: Definition of done

In my opinion these automatic verifyable acceptance criteria must be written by a team of businessexperts and softwaredeveloppers.

I agree to @pdr that a businessexpert writing the spec alone makes not sensce.