Discussion:
[Cucumber] In a nutshell, what does BDD _software_ do?
(too old to reply)
Mark Pawelek
2018-05-15 08:55:02 UTC
Permalink
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?
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
aslak hellesoy
2018-05-15 15:17:33 UTC
Permalink
Post by 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.
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
Post by Mark Pawelek
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".
Post by Mark Pawelek
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.
Post by Mark Pawelek
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.
Post by Mark Pawelek
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.
Post by Mark Pawelek
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
Post by Mark Pawelek
7. Alternatively/additionally test reports are created. These reports
demonstrate which business rules/features work.
Yes
Post by Mark Pawelek
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
Post by Mark Pawelek
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
Post by Mark Pawelek
--
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
For more options, visit https://groups.google.com/d/optout.
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...