Live data from Hacker News

Saving Agile with BDD and Cucumber

blog.fogcreek.com

1–10 of 48 posts

Re: Saving Agile with BDD and Cucumber

#2
I can get behind the message that Scrum has been problematic because it focuses too much on selling PMs on practices to the exclusion of developer practices.

XP was much more balanced in this regard. I think Scrum loses a lot in both being so free-form to start and in being so often something that PMs or management bring to the table. XP in my experience always seemed to be more of a developer lead movement and ultimately a development process without developer buy in becomes a command and control process that kills creativity and stifles feedback.

Re: Saving Agile with BDD and Cucumber

#4

> Saving Agile with BDD and Cucumber First value of Agile Manifesto: "Individuals and interactions over processes and tools "

"over", not "instead of".

Having not yet read this interview (did you?), I'm willing to give the benefit of the doubt that he identifies some problems with Agile teams that COULD be solved with BDD and Cucumber (for teams that want and choose this approach)

Re: Saving Agile with BDD and Cucumber

#5
Most of the time I've spent with Cucumber in actual work projects has been wasted on trying to write steps to wrap idiosyncratic UI patterns which aren't handled out of the box - of course its been years since then and the UI on that project was particularly horrendous.

That being said, I do find a lot of value in being able to translate text from a story - "As a user I should see " directly into a test.

Re: Saving Agile with BDD and Cucumber

#6

> Saving Agile with BDD and Cucumber First value of Agile Manifesto: "Individuals and interactions over processes and tools "

One of the nice things about BDD tests in Cucumber/Gherkin is that they're written down in plain text (English), a language that managers, testers, and developers all presumably speak. The Gherkin language is actually very useful for facilitating communication/interactions.

Re: Saving Agile with BDD and Cucumber

#7

> Saving Agile with BDD and Cucumber First value of Agile Manifesto: "Individuals and interactions over processes and tools "

One of the nice things about BDD tests in Cucumber/Gherkin is that they're written down in plain text (English), a language that managers, testers, and developers all presumably speak. The Gherkin language is actually very useful for facilitating communication/interactions.

The myths of having non-developers read tests have been dispelled for years. I'm not even going there.

Re: Saving Agile with BDD and Cucumber

#8
TL;DR: Matt Wayne (the interviewee) talks about a basic problem that agile was supposed to solve: creating software that actually satisfies business requirements. For him, Cucumber and BDD solves this problem.

But for all other bugs and code defects that happen during software development, mutation analysis works great at increasing the quality of unit tests: https://en.m.wikipedia.org/wiki/Mutation_testing

Re: Saving Agile with BDD and Cucumber

#9
Note from the field: the purpose of BDD/ATDD and Cucumber (aside from validating work and making sure the system is still up) is to work with the business to get agreement on common business terms. That means there's a fair bit of factoring involved as the system grows. Things like "When you say 'content', do you mean 'html content', or also user manuals?'.

It's like English is the programming language, and you're constantly looking to refactor terms so that the English used is more structured.

What I'm beginning to see is cucumber being used for system or even unit tests. You'll get Cucumber full of magic numbers, table names, API calls, and it looks very scripty.

Testing is great, but this is using the wrong tool for the job. We end up confusing terms and thinking we understand BDD/ATDD when in reality -- not so much. (Insert long discussion here about teams working on middle layers, how APIs and microservices fit into the picture, and so on)

Post reply on HN