In a nutshell, what does BDD _software_ do?

[Mark Pawelek]

I realize that Cucumber is all about business processes and getting developers / testers / product owners engaged, etc.  I take that as given, but exactly how you business develops (or should develop) software is another thread entirely. But my questions relates to the specific way the software works to achieve this end. And, therefore, to the features which any BDD process should have. To the best of my knowledge the software (BDD / ATDD) may be summarized below. Is this correct?  Did I leave a step out. 

My understanding of what BDD software (Cucumber) is aiming to do:

1. Specifications are written as business rules in a formal language, (e.g. Gherkin).

2. These specifications are compiled to test stubs (usually codegen). In a distinct compile phase. A test runner may do this transparently (invisibly).

3. Running these test stubs initially shows failing tests (which correspond to unmet business features).

4. The test stubs are edited to pass.

5. In this test stub editing phase (4) a programmer creates the program code which implements each business feature/rule.

6. When the tests run, there is feedback to the original Specs. So you can see, by looking at the specs, which ones fail, pass or lack an implementation (red / green / amber).

7. Alternatively/additionally test reports are created. These reports demonstrate which business rules/features work.

8. We have a kind of audit trail, from specifications, to tests, to code, to test results which demonstrate what works, or does not.

In your opinion, is the list above the least required to implement a suitable (software) system which forms the bedrock of a process we may call BDD, or ATDD?  Am I right in thinking that Cucumber, FIT, and Fitnesse do all steps above?

[aslak hellesoy]

On Tue, May 15, 2018 at 9:55 AM, Mark Pawelek <mark...@gmail.com> wrote:

I realize that Cucumber is all about business processes and getting developers / testers / product owners engaged, etc.  I take that as given, but exactly how you business develops (or should develop) software is another thread entirely. But my questions relates to the specific way the software works to achieve this end. And, therefore, to the features which any BDD process should have. To the best of my knowledge the software (BDD / ATDD) may be summarized below. Is this correct?  Did I leave a step out. 

My understanding of what BDD software (Cucumber) is aiming to do:

1. Specifications are written as business rules in a formal language, (e.g. Gherkin).

Not rules, but scenarios that are derived from *examples*. There is a distinct difference between rules and examples.

Examples illustrate rules, using concrete values. For a more in-depth description see https://leanpub.com/bddbooks-discovery

 

2. These specifications are compiled to test stubs (usually codegen). In a distinct compile phase. A test runner may do this transparently (invisibly).

Cucumber does print "snippets" for undefined steps, but I wouldn't call it code generation, because needs to be modified

by a human before it can do anything useful. It's just "coding assistance".

 

3. Running these test stubs initially shows failing tests (which correspond to unmet business features).

For an interpreted programming language - correct.

For a compiled programming language there is an intermediary phase - the code doesn't compile.

 

4. The test stubs are edited to pass.

Not quite. The test is not modified at this point. Instead, the production system is modified to make the test pass. Just like in TDD: 1) Write a failing test. 2) Make it pass (by implementing production code). 3) Refactor.

 

5. In this test stub editing phase (4) a programmer creates the program code which implements each business feature/rule.

They create program code which makes *that particular scenario* pass, which may or may not (usually not) implement the full business rule.

The business rule is gradually implemented by adding more and more scenarios and/or unit tests.

 

6. When the tests run, there is feedback to the original Specs. So you can see, by looking at the specs, which ones fail, pass or lack an implementation (red / green / amber).

Yes

 

7. Alternatively/additionally test reports are created. These reports demonstrate which business rules/features work.

Yes

 

8. We have a kind of audit trail, from specifications, to tests, to code, to test results which demonstrate what works, or does not.

Yes

 

In your opinion, is the list above the least required to implement a suitable (software) system which forms the bedrock of a process we may call BDD, or ATDD?  Am I right in thinking that Cucumber, FIT, and Fitnesse do all steps above?

You've omitted a crucial part here - Discovery. This is where stakeholders with different perspectives have conversations about concrete examples.

It's not just about gaining a common understanding and designing examples. It's just as much about discovering what you don't know, and what

you need to find out before you head down a rabbit hole of development. The technique we recommend is https://cucumber.io/blog/2015/12/08/example-mapping-introduction

Writing executable specs without first doing collaborative discovery usually leads to a lot of rework, because they can easily be misunderstood. They're also usually wrong unless a diverse group of people have provided their input.

From a technical perspective it doesn't matter what tool you use. Any test automation tool will do.

From a stakeholder feedback perspective, it *does* matter what tool you choose. Non-technical stakeholders may find it

more or less easy to understand and provide feedback on acceptance tests based on a number of factors:

* What syntax are they written in? (Programming language or something less technical like tables or Gherkin)

* How were they written (It's possible to write incomprehensible gibberish in any syntax, including Gherkin)

Cheers,

Aslak

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.