[Cucumber] Cucumber Preprocessor

[k***@gmail.com]

Here's a pre-processor for Cucumber An explanation of its purpose is
here:

https://github.com/atdd-bdd/preprocessor/blob/master/Cucumber%20Preprocessor%20Introduction.pdf

It uses #define and #include directives to transform feature files in one
directory into processed files in another directory. It stands separate
from Cucumber and is executed prior in the build to running cucumber.
I'm trying it out as an experiment. One feature is the ability to
include csv files as tables. Someone had mentioned that a few years ago
in a separate thread.

The code is at:

https://github.com/atdd-bdd/preprocessor/

and further documentation is at:

https://github.com/atdd-bdd/preprocessor/blob/master/CucumberPreprocessorExplanation.pdf

Ken

[Roberto Lo Giacco]

This post might be inappropriate. Click to display it.

[k***@gmail.com]

Roberto,

Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not contain
any data, then there is no need for this preprocessor, as you illustrated.
The more data one places in a feature file, then the possibility of values
that represent one domain term can be duplicated. Having #defines for
those terms can make for easier maintenance. In addition, giving names
to values helps create ubiquitous terms for understanding for the entire
team (e.g. MAXIMUM_VALUE).

I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to contain
these values reduces the number of step definitions that need to be
created.

As far as CSV files, see my response to Halfordian Golfer.
Ken





Ken

Post by Roberto Lo Giacco

Post by k***@gmail.com
Here's a pre-processor for Cucumber An explanation of its purpose is
https://github.com/atdd-bdd/preprocessor/blob/master/Cucumber%20Preprocessor%20Introduction.pdf
It uses #define and #include directives to transform feature files in one
directory into processed files in another directory. It stands separate
from Cucumber and is executed prior in the build to running cucumber.
I'm trying it out as an experiment. One feature is the ability to
include csv files as tables. Someone had mentioned that a few years ago
in a separate thread.

My personal opinion is this pre-processor is actually against BDD and ATDD
concepts and brings test features into a non-test context: it turns a
feature file, which should be focused on project documentation, into a
test, which also depends on another file.
Following BDD and ATDD principles the #define could be simply avoided with
When value is over the 200 maximum

Post by k***@gmail.com
Then report error

I could argue that 200 should be just a system parameter, so having it
inside the feature file makes the feature file more brittle and increases
maintenance costs, but that is another story. Honestly, while I can see a
value in the #define directive I believe it's implemented the wrong way,
from the perspective of a developer.
From a business point of view it should look something like
Given a maximum of 200
When the value is over the maximum
Then report error
Better, giving a little personalization and readability, IMHO it should be
Given maximum value is set to 200
When the user sets a value above the maximum
Then an error is reported
With regards to the #include directive, I believe it simply breaks the
feature file "contract" of being a self-contained system documentation,
other than making the file not self-explanatory, not counting the thing
could just be implemented as
When the dataset matches the expected content
With a step definition which simply reads the appropriate file in CSV
format. If I have a number of files and I really want to make those
explicit, I would go for something like
When the dataset matches the list of "banned users"
With a step definition that converts "banned users" in "banend-users.csv"
(or whatever convention you like) and the calls a helper function with the
converted value...
What benefit do you see in having the table being put into the feature
file? Are you aware that your Cucumber output will report the whole content
of the CSV? Don't you think that your business partner will feel
overwhelmed by a report containing a table with hundreds of data he doesn't
understand?
Sorry if I came across like I'm attacking your solution, that's not my
intention: in the end, I can simply not use your pre-processor.
My intention is to discuss the reasons behind your project, as I believe
you too should not be using it if you want to take the benefits Cucumber
can provide.
Regards,
Roberto

[George Dinwiddie]

Ken,

Post by k***@gmail.com
Roberto,
Thanks for your reply.   We have different approaches to what a feature
file represents and how it is used.   If a feature file does not contain
any data, then there is no need for this preprocessor, as you
illustrated.  The more data one places in a feature file, then the
possibility of values that represent one domain term can be
duplicated.   Having #defines for those terms can make for easier
maintenance.    In addition, giving names to values helps create
ubiquitous terms for understanding for the entire team (e.g.
MAXIMUM_VALUE).

As Brian Marick says, "An example would be handy right now."

Have you used this and found patterns that have worked well, or are you
still exploring and looking for those patterns? If you have found
patterns, would you share examples of them with this list?

- George

Post by k***@gmail.com
I've found that having specific values in a scenario really helps in
discussion between the business and development.  Using tables to
contain these values reduces the number of step definitions that need to
be created.
As far as CSV files, see my response to Halfordian Golfer.
Ken

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[k***@gmail.com]

George,

I'm still exploring potential patterns. However some of the things I have
seen in the past are:

*Business Rule Pattern*

Business person creates a spreadsheet that contains a table representing a
requirement (a business rule or tests for that business rule). Developers
copy and paste that table into a feature file as a table (typically an
example table). Now the business person updates the values. The
developers need to update the feature file manually.

One alternative used was to read the spreadsheet into the test via an Excel
library. Changes to the spreadsheet would be then incorporated into the
test. The code to read the Excel spreadsheet was a bit of work.

So here's an alternative using the proposed #include.

Business person updates the spreadsheet and saves it as a CSV file in a
shared location.
Build script copies the CSV file and checks it into source repository.
(If business person could easily update source repository, this could be
combined with previous step)
Preprocessor run, inserts the file, then Cucumber runs.
Output shows results.

*Domain Term Pattern*

I've also seen a lot of duplication with values in tests, such as:

When value is greater than 200
....
When value is equal to 200

Here's the alternative with #define:

#define MAXIMUM_VALUE 200

When value is greater than MAXIMUM_VALUE
...
When value is equal to MAXIMUM_VALUE

This is equivalent to using named constants in code, which makes code much
easier to maintain. In addition, it creates a domain term - MAXIMUM_VALUE
that is shared among the team and appears in the feature file for
documentation.


Let me know if these examples resonant with you. Every context is
different.

Ken

Post by George Dinwiddie
Ken,

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not contain
any data, then there is no need for this preprocessor, as you
illustrated. The more data one places in a feature file, then the
possibility of values that represent one domain term can be
duplicated. Having #defines for those terms can make for easier
maintenance. In addition, giving names to values helps create
ubiquitous terms for understanding for the entire team (e.g.
MAXIMUM_VALUE).

As Brian Marick says, "An example would be handy right now."
Have you used this and found patterns that have worked well, or are you
still exploring and looking for those patterns? If you have found
patterns, would you share examples of them with this list?
- George

Post by k***@gmail.com
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to
contain these values reduces the number of step definitions that need to
be created.
As far as CSV files, see my response to Halfordian Golfer.
Ken

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[George Dinwiddie]

Ken,

Post by k***@gmail.com
George,
I'm still exploring potential patterns.   However some of the things I
*Business Rule Pattern*
Business person creates a spreadsheet that contains a table representing
a requirement (a business rule or tests for that business rule).
Developers copy and paste that table into a feature file as a table
(typically an example table).   Now the business person updates the
values.   The developers need to update the feature file manually.

I feel the pain of working with business people who would rather work
with Microsoft Office than text files. I've known BAs who would write
gherkin in Word.

How often do these spreadsheets change? I might be inclined to stick
with copying the data in to have one file that clearly describes that
business rule, rather than having it spread between files that can get
out of sync.

Post by k***@gmail.com
One alternative used was to read the spreadsheet into the test via an
Excel library.  Changes to the spreadsheet would be then incorporated
into the test.    The code to read the Excel spreadsheet was a bit of work.

Not a terrible amount of work. I wrote
https://github.com/gdinwiddie/Spreadsheet when working with a client
some years back. The idea (which never came to fruition while I was
there) was to be able to specify "a customer with only one policy" in
the test, and have the step definitions map that to a user ID behind the
scenes. This would allow the Data Group to maintain the test data (which
development wasn't allowed to change) and provide the appropriate IDs in
the spreadsheet. Given that they were looking for data that matched
conditions rather than creating it to match the conditions, it was
likely to change frequently. The QA Department was using the same
database for their manual testing. The data was populated with a
sanitized extract from production. Not ideal, but it seemed like a good
compromise for the context.

Post by k***@gmail.com
So here's an alternative using the proposed #include.
    Business person updates the spreadsheet and saves it as a CSV file
in a shared location.
    Build script copies the CSV file and checks it into source
repository.    (If business person could easily update source
repository, this could be combined with previous step)
    Preprocessor run, inserts the file, then Cucumber runs.
    Output shows results.

After running the preprocessor, do you end up with a normal gherkin
feature file? If so, that seems like an easy way to let the business
people edit the part of the gherkin they want to edit in a tool that is
familiar to them. I suggest versioning the processed file as the
canonical description of the functionality.

Post by k***@gmail.com
*Domain Term Pattern*
When value is greater than 200
....
When value is equal to 200
#define MAXIMUM_VALUE 200
When value is greater than MAXIMUM_VALUE
...
When value is equal to MAXIMUM_VALUE
This is equivalent to using named constants in code, which makes code
much easier to maintain.  In addition, it creates a domain term -
MAXIMUM_VALUE that is shared among the team and appears in the feature
file for documentation.

This I don't like so much. I'd rather put this in the Background if the
steps need it.

Background:
Given the maximum value is 200

Scenario: Greater than maximum
When the value is greater than the maximum value

Scenario: Equal to maximum
When the value is equal to the maximum value

Using a #define construct is too much like C programming for my taste.
Not that I dislike C programming, but that I think it's inappropriate to
share with the business. And I think it puts me into a programmers
mindset when reading it, rather than thinking about the
business/customer/user POV.

For one thing, it leads to terms like MAXIMUM_VALUE when, as I reword
it, is clearly the wrong name. The computer doesn't care, but value can
obviously be greater than the maximum value, which means it's something
else than a maximum value. Perhaps maximum allowed value?

Keeping things in English helps my brain notice such things.

Post by k***@gmail.com
Let me know if these examples resonant with you.   Every context is
different.

Yes, and experimentation is how we learn. Not every experiment is
something we want to continue doing, however. And I try to be very
careful to look for the limitations of new approaches.

- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Roberto Lo Giacco]

Il giorno venerdì 15 giugno 2018 21:46:27 UTC+2, George Dinwiddie ha

Post by George Dinwiddie
Ken,

Post by k***@gmail.com
George,
So here's an alternative using the proposed #include.
Business person updates the spreadsheet and saves it as a CSV file
in a shared location.
Build script copies the CSV file and checks it into source
repository. (If business person could easily update source
repository, this could be combined with previous step)
Preprocessor run, inserts the file, then Cucumber runs.
Output shows results.

After running the preprocessor, do you end up with a normal gherkin
feature file? If so, that seems like an easy way to let the business
people edit the part of the gherkin they want to edit in a tool that is
familiar to them. I suggest versioning the processed file as the
canonical description of the functionality.

I would be greatly concerned about what would be the report content of such
execution: tons of data describing the test details transforming the report
into a something nobody will take the time to look at....

[Matt Wynne]

Post by k***@gmail.com
George,
I'm still exploring potential patterns. However some of the things I
*Business Rule Pattern*
Business person creates a spreadsheet that contains a table representing a
requirement (a business rule or tests for that business rule). Developers
copy and paste that table into a feature file as a table (typically an
example table). Now the business person updates the values. The
developers need to update the feature file manually.
One alternative used was to read the spreadsheet into the test via an
Excel library. Changes to the spreadsheet would be then incorporated into
the test. The code to read the Excel spreadsheet was a bit of work.
So here's an alternative using the proposed #include.
Business person updates the spreadsheet and saves it as a CSV file in
a shared location.
Build script copies the CSV file and checks it into source
repository. (If business person could easily update source repository,
this could be combined with previous step)
Preprocessor run, inserts the file, then Cucumber runs.
Output shows results.

I'm wondering: if we had a native way to pull table content into Gherkin
from a CSV file, would that solve this problem for you?

e.g.

Given the maximum values are:
|<< maximum_values.csv >>|
When I ...

Post by k***@gmail.com
*Domain Term Pattern*
When value is greater than 200
....
When value is equal to 200
#define MAXIMUM_VALUE 200
When value is greater than MAXIMUM_VALUE
...
When value is equal to MAXIMUM_VALUE
This is equivalent to using named constants in code, which makes code much
easier to maintain. In addition, it creates a domain term - MAXIMUM_VALUE
that is shared among the team and appears in the feature file for
documentation.

I like the solution George suggests (which in fact he taught me) of writing
these in Gherkin steps, often in a Background.

Does that not work for you because you want these terms to be global?

Post by k***@gmail.com

Post by Roberto Lo Giacco
Ken,

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not

contain

Post by k***@gmail.com
any data, then there is no need for this preprocessor, as you
illustrated. The more data one places in a feature file, then the
possibility of values that represent one domain term can be
duplicated. Having #defines for those terms can make for easier
maintenance. In addition, giving names to values helps create
ubiquitous terms for understanding for the entire team (e.g.
MAXIMUM_VALUE).

As Brian Marick says, "An example would be handy right now."
Have you used this and found patterns that have worked well, or are you
still exploring and looking for those patterns? If you have found
patterns, would you share examples of them with this list?
- George

Post by k***@gmail.com
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to
contain these values reduces the number of step definitions that need

to

Post by k***@gmail.com
be created.
As far as CSV files, see my response to Halfordian Golfer.
Ken

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

--
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited
company registered in Scotland, number 456793.


Registered address:
Cucumber Ltd, The Melting Pot, 5 Rose Street, Edinburgh EH2 2PR, Scotland,
United Kingdom.
CONFIDENTIALITY NOTICE: The information in this e-mail is
confidential and privileged; it is intended for use solely by the
individual or entity named as the recipient hereof. Disclosure, copying,
distribution, or use of the contents of this e-mail by persons other than
the intended recipient is strictly prohibited and may violate applicable
laws. If you have received this e-mail in error, please delete the original
message and notify us by email immediately. Thank you. Cucumber Ltd.

[k***@gmail.com]

One of the reasons for using #defines is to clearly indicate domain terms
(as in Domain Driven Design) which should be global as you mentioned. As
George suggested, he didn't like the term MAXIMUM_VALUE, he would rather
have it be MAXIMUM_ALLOWED_VALUE. By agreeing on the term and using it
everywhere, then misunderstanding decreases.


For example, one might write two scenarios containing:

When value is less than maximum value

When values is greater than maximum allowed value

Then one might ask whether these are referring to the same domain term and
simply expressed with different text.

With #defines, scenarios would look like:

When value is less than MAXIMUM_VALUE

When values is greater than MAXIMUM_ALLOWED_VALUE

The terms stand out.


With free text, it's less easy to spot domain terms unless they are denoted
somehow. If the triad did not like all caps, they could use MaximumValue
or some other convention to designate the terms.

Post by Matt Wynne

Post by k***@gmail.com
George,
I'm still exploring potential patterns. However some of the things I
*Business Rule Pattern*
Business person creates a spreadsheet that contains a table representing
a requirement (a business rule or tests for that business rule).
Developers copy and paste that table into a feature file as a table
(typically an example table). Now the business person updates the
values. The developers need to update the feature file manually.
One alternative used was to read the spreadsheet into the test via an
Excel library. Changes to the spreadsheet would be then incorporated into
the test. The code to read the Excel spreadsheet was a bit of work.
So here's an alternative using the proposed #include.
Business person updates the spreadsheet and saves it as a CSV file in
a shared location.
Build script copies the CSV file and checks it into source
repository. (If business person could easily update source repository,
this could be combined with previous step)
Preprocessor run, inserts the file, then Cucumber runs.
Output shows results.

I'm wondering: if we had a native way to pull table content into Gherkin
from a CSV file, would that solve this problem for you?
e.g.
|<< maximum_values.csv >>|
When I ...

Post by k***@gmail.com
*Domain Term Pattern*
When value is greater than 200
....
When value is equal to 200
#define MAXIMUM_VALUE 200
When value is greater than MAXIMUM_VALUE
...
When value is equal to MAXIMUM_VALUE
This is equivalent to using named constants in code, which makes code
much easier to maintain. In addition, it creates a domain term -
MAXIMUM_VALUE that is shared among the team and appears in the feature file
for documentation.

I like the solution George suggests (which in fact he taught me) of
writing these in Gherkin steps, often in a Background.
Does that not work for you because you want these terms to be global?

Post by k***@gmail.com

Post by k***@gmail.com
Ken,

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a

feature

Post by k***@gmail.com
file represents and how it is used. If a feature file does not

contain

Post by k***@gmail.com
any data, then there is no need for this preprocessor, as you
illustrated. The more data one places in a feature file, then the
possibility of values that represent one domain term can be
duplicated. Having #defines for those terms can make for easier
maintenance. In addition, giving names to values helps create
ubiquitous terms for understanding for the entire team (e.g.
MAXIMUM_VALUE).

As Brian Marick says, "An example would be handy right now."
Have you used this and found patterns that have worked well, or are you
still exploring and looking for those patterns? If you have found
patterns, would you share examples of them with this list?
- George

Post by k***@gmail.com
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to
contain these values reduces the number of step definitions that need

to

Post by k***@gmail.com
be created.
As far as CSV files, see my response to Halfordian Golfer.
Ken

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Tim Walker]

Post by k***@gmail.com
One of the reasons for using #defines is to clearly indicate domain terms
(as in Domain Driven Design) which should be global as you mentioned. As
George suggested, he didn't like the term MAXIMUM_VALUE, he would rather
have it be MAXIMUM_ALLOWED_VALUE. By agreeing on the term and using it
everywhere, then misunderstanding decreases.
When value is less than maximum value
When values is greater than maximum allowed value
Then one might ask whether these are referring to the same domain term and
simply expressed with different text.
When value is less than MAXIMUM_VALUE
When values is greater than MAXIMUM_ALLOWED_VALUE
The terms stand out.

[tim] Creeping towards programmatic notation in my mind. You can upper case
that term in the Gherkin, match it, and give it context all in the glue and
the SUT already?

Post by k***@gmail.com
With free text, it's less easy to spot domain terms unless they are
denoted somehow. If the triad did not like all caps, they could use
MaximumValue or some other convention to designate the terms.

Post by Matt Wynne

Post by k***@gmail.com
George,
I'm still exploring potential patterns. However some of the things I
*Business Rule Pattern*
Business person creates a spreadsheet that contains a table representing
a requirement (a business rule or tests for that business rule).
Developers copy and paste that table into a feature file as a table
(typically an example table). Now the business person updates the
values. The developers need to update the feature file manually.
One alternative used was to read the spreadsheet into the test via an
Excel library. Changes to the spreadsheet would be then incorporated into
the test. The code to read the Excel spreadsheet was a bit of work.
So here's an alternative using the proposed #include.
Business person updates the spreadsheet and saves it as a CSV file
in a shared location.
Build script copies the CSV file and checks it into source
repository. (If business person could easily update source repository,
this could be combined with previous step)
Preprocessor run, inserts the file, then Cucumber runs.
Output shows results.

I'm wondering: if we had a native way to pull table content into Gherkin
from a CSV file, would that solve this problem for you?
e.g.
|<< maximum_values.csv >>|
When I ...

Post by k***@gmail.com
*Domain Term Pattern*
When value is greater than 200
....
When value is equal to 200
#define MAXIMUM_VALUE 200
When value is greater than MAXIMUM_VALUE
...
When value is equal to MAXIMUM_VALUE
This is equivalent to using named constants in code, which makes code
much easier to maintain. In addition, it creates a domain term -
MAXIMUM_VALUE that is shared among the team and appears in the feature file
for documentation.

I like the solution George suggests (which in fact he taught me) of
writing these in Gherkin steps, often in a Background.
Does that not work for you because you want these terms to be global?

Post by k***@gmail.com

Post by k***@gmail.com
Ken,

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a

feature

Post by k***@gmail.com
file represents and how it is used. If a feature file does not

contain

Post by k***@gmail.com
any data, then there is no need for this preprocessor, as you
illustrated. The more data one places in a feature file, then the
possibility of values that represent one domain term can be
duplicated. Having #defines for those terms can make for easier
maintenance. In addition, giving names to values helps create
ubiquitous terms for understanding for the entire team (e.g.
MAXIMUM_VALUE).

As Brian Marick says, "An example would be handy right now."
Have you used this and found patterns that have worked well, or are you
still exploring and looking for those patterns? If you have found
patterns, would you share examples of them with this list?
- George

Post by k***@gmail.com
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to
contain these values reduces the number of step definitions that need

to

Post by k***@gmail.com
be created.
As far as CSV files, see my response to Halfordian Golfer.
Ken

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
--

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.

[Matt Wynne]

@Ken I’m wondering, would one way of solving this problem be to add a new keyword to Gherkin that acts like a global Background, say we call it Define? You could use it to specify global terms like in Gherkin this which could then be used by steps elsewhere:

# in Gherkin (somewhere)

Define:
Given the Maximum Allowed Value is 500


# in steps:

Given(“the Maximum Allowed Value is {int}”) do |max|
@maximum_allowed_value = max
end

When(“the value is less that the Maximum Allowed Value”) do
@value = @maximum_allowed_value - 1
end

WDYT?

One of the reasons for using #defines is to clearly indicate domain terms (as in Domain Driven Design) which should be global as you mentioned. As George suggested, he didn't like the term MAXIMUM_VALUE, he would rather have it be MAXIMUM_ALLOWED_VALUE. By agreeing on the term and using it everywhere, then misunderstanding decreases.
When value is less than maximum value
When values is greater than maximum allowed value
Then one might ask whether these are referring to the same domain term and simply expressed with different text.
When value is less than MAXIMUM_VALUE
When values is greater than MAXIMUM_ALLOWED_VALUE
The terms stand out.
With free text, it's less easy to spot domain terms unless they are denoted somehow. If the triad did not like all caps, they could use MaximumValue or some other convention to designate the terms.
George,
Business Rule Pattern
Business person creates a spreadsheet that contains a table representing a requirement (a business rule or tests for that business rule). Developers copy and paste that table into a feature file as a table (typically an example table). Now the business person updates the values. The developers need to update the feature file manually.
One alternative used was to read the spreadsheet into the test via an Excel library. Changes to the spreadsheet would be then incorporated into the test. The code to read the Excel spreadsheet was a bit of work.
So here's an alternative using the proposed #include.
Business person updates the spreadsheet and saves it as a CSV file in a shared location.
Build script copies the CSV file and checks it into source repository. (If business person could easily update source repository, this could be combined with previous step)
Preprocessor run, inserts the file, then Cucumber runs.
Output shows results.
I'm wondering: if we had a native way to pull table content into Gherkin from a CSV file, would that solve this problem for you?
e.g.
|<< maximum_values.csv >>|
When I ...
Domain Term Pattern
When value is greater than 200
....
When value is equal to 200
#define MAXIMUM_VALUE 200
When value is greater than MAXIMUM_VALUE
...
When value is equal to MAXIMUM_VALUE
This is equivalent to using named constants in code, which makes code much easier to maintain. In addition, it creates a domain term - MAXIMUM_VALUE that is shared among the team and appears in the feature file for documentation.
I like the solution George suggests (which in fact he taught me) of writing these in Gherkin steps, often in a Background.
Does that not work for you because you want these terms to be global?
Ken,

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not contain
any data, then there is no need for this preprocessor, as you
illustrated. The more data one places in a feature file, then the
possibility of values that represent one domain term can be
duplicated. Having #defines for those terms can make for easier
maintenance. In addition, giving names to values helps create
ubiquitous terms for understanding for the entire team (e.g.
MAXIMUM_VALUE).

As Brian Marick says, "An example would be handy right now."
Have you used this and found patterns that have worked well, or are you
still exploring and looking for those patterns? If you have found
patterns, would you share examples of them with this list?
- George

Post by k***@gmail.com
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to
contain these values reduces the number of step definitions that need to
be created.
As far as CSV files, see my response to Halfordian Golfer.
Ken

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com <http://blog.gdinwiddie.com/>
Software Development http://www.idiacomputing.com <http://www.idiacomputing.com/>
Consultant and Coach http://www.agilemaryland.org <http://www.agilemaryland.org/>
----------------------------------------------------------------------
--
Posting rules: http://cukes.info/posting-rules.html <http://cukes.info/posting-rules.html>
---
You received this message because you are subscribed to a topic in the Google Groups "Cukes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe <https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

cheers,
Matt

—
[phone]
***@cucumber.io
https://cucumber.io
https://twitter.com/mattwynne
--
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited
company registered in Scotland, number 456793.


Registered address:
Cucumber Ltd, The Melting Pot, 5 Rose Street, Edinburgh EH2 2PR, Scotland,
United Kingdom.
CONFIDENTIALITY NOTICE: The information in this e-mail is
confidential and privileged; it is intended for use solely by the
individual or entity named as the recipient hereof. Disclosure, copying,
distribution, or use of the contents of this e-mail by persons other than
the intended recipient is strictly prohibited and may violate applicable
laws. If you have received this e-mail in error, please delete the original
message and notify us by email immediately. Thank you. Cucumber Ltd.

[Roberto Lo Giacco]

Post by Matt Wynne
@Ken I’m wondering, would one way of solving this problem be to add a new
keyword to Gherkin that acts like a global Background, say we call it
Define? You could use it to specify global terms like in Gherkin this which
# in Gherkin (somewhere)

​The "somewhere" is what makes me think about this: aren't we going to end
up with something like the old Constants java interface antipattern?​

​I do understand it can be a commodity, but it also​ tend to mess things
up: you are prone to create one long file with lots of definitions and
colliding names...

Post by Matt Wynne
Given the Maximum Allowed Value is 500

​Let's make it more real:

Define:
​ Given the maximum password lenght is 25 chars
And the maximum username lenght is 120 chars
And the maximum first name lenght is 60 chars
And the maximum email address lenght is 255 chars
And the minimum witdrawal value is 1 USD
And the maximum withdrawal value is 9999 USD
And the maximum comment lenght is 3000 chars
And the minimum comment lenght is 30 chars
And the longest loan duration is 12 months
But the longest mortgage duration is 240 months
And ...
And ...
And ...


I see this list growing pretty fast, with increasing risk of naming
collisions and misuse...

[Matt Wynne]

Roberto,

Post by Matt Wynne
# in Gherkin (somewhere)
​The "somewhere" is what makes me think about this: aren't we going to end up with something like the old Constants java interface antipattern?​
​I do understand it can be a commodity, but it also​ tend to mess things up: you are prone to create one long file with lots of definitions and colliding names...
Given the Maximum Allowed Value is 500
​ Given the maximum password lenght is 25 chars
And the maximum username lenght is 120 chars
And the maximum first name lenght is 60 chars
And the maximum email address lenght is 255 chars
And the minimum witdrawal value is 1 USD
And the maximum withdrawal value is 9999 USD
And the maximum comment lenght is 3000 chars
And the minimum comment lenght is 30 chars
And the longest loan duration is 12 months
But the longest mortgage duration is 240 months
And ...
And ...
And ...
I see this list growing pretty fast, with increasing risk of naming collisions and misuse


There are already myriad ways for people to abuse Gherkin and get themselves into a mess. I’m not really convinced that this is a good reason for not adding a feature that other people are saying they would find useful.

Would you mind holding fire for a bit while we explore this with Ken and see where it leads?

cheers,
Matt

—
[phone]
***@cucumber.io
https://cucumber.io
https://twitter.com/mattwynne
--
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited
company registered in Scotland, number 456793.


Registered address:
Cucumber Ltd, The Melting Pot, 5 Rose Street, Edinburgh EH2 2PR, Scotland,
United Kingdom.
CONFIDENTIALITY NOTICE: The information in this e-mail is
confidential and privileged; it is intended for use solely by the
individual or entity named as the recipient hereof. Disclosure, copying,
distribution, or use of the contents of this e-mail by persons other than
the intended recipient is strictly prohibited and may violate applicable
laws. If you have received this e-mail in error, please delete the original
message and notify us by email immediately. Thank you. Cucumber Ltd.

[Roberto Lo Giacco]

Post by k***@gmail.com
Roberto,
@Ken I’m wondering, would one way of solving this problem be to add a new

Post by Matt Wynne
keyword to Gherkin that acts like a global Background, say we call it
Define? You could use it to specify global terms like in Gherkin this which
# in Gherkin (somewhere)

​The "somewhere" is what makes me think about this: aren't we going to end
up with something like the old Constants java interface antipattern?​
​I do understand it can be a commodity, but it also​ tend to mess things
up: you are prone to create one long file with lots of definitions and
colliding names...

Post by Matt Wynne
Given the Maximum Allowed Value is 500

​ Given the maximum password lenght is 25 chars
And the maximum username lenght is 120 chars
And the maximum first name lenght is 60 chars
And the maximum email address lenght is 255 chars
And the minimum witdrawal value is 1 USD
And the maximum withdrawal value is 9999 USD
And the maximum comment lenght is 3000 chars
And the minimum comment lenght is 30 chars
And the longest loan duration is 12 months
But the longest mortgage duration is 240 months
And ...
And ...
And ...
I see this list growing pretty fast, with increasing risk of naming
collisions and misuse

There are already myriad ways for people to abuse Gherkin and get
themselves into a mess. I’m not really convinced that this is a good reason
for not adding a feature that other people are saying they would find
useful.
Would you mind holding fire for a bit while we explore this with Ken and
see where it leads?

No worries Matt, my mistake.

Post by k***@gmail.com
cheers,
Matt
—
[phone]
https://cucumber.io
https://twitter.com/mattwynne
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited
company registered in Scotland, number 456793.
Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street,
Edinburgh EH2 2PR, Scotland, United Kingdom
<https://maps.google.com/?q=5+Rose+Street,+Edinburgh+EH2+2PR,+Scotland,+United+Kingdom&entry=gmail&source=g>
.
CONFIDENTIALITY NOTICE: The information in this e-mail is confidential and
privileged; it is intended for use solely by the individual or entity named
as the recipient hereof. Disclosure, copying, distribution, or use of the
contents of this e-mail by persons other than the intended recipient is
strictly prohibited and may violate applicable laws. If you have received
this e-mail in error, please delete the original message and notify us by
email immediately. Thank you. Cucumber Ltd.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[Matt Wynne]

Post by k***@gmail.com
Roberto,

Post by Matt Wynne
# in Gherkin (somewhere)
​The "somewhere" is what makes me think about this: aren't we going to end up with something like the old Constants java interface antipattern?​
​I do understand it can be a commodity, but it also​ tend to mess things up: you are prone to create one long file with lots of definitions and colliding names...
Given the Maximum Allowed Value is 500
​ Given the maximum password lenght is 25 chars
And the maximum username lenght is 120 chars
And the maximum first name lenght is 60 chars
And the maximum email address lenght is 255 chars
And the minimum witdrawal value is 1 USD
And the maximum withdrawal value is 9999 USD
And the maximum comment lenght is 3000 chars
And the minimum comment lenght is 30 chars
And the longest loan duration is 12 months
But the longest mortgage duration is 240 months
And ...
And ...
And ...
I see this list growing pretty fast, with increasing risk of naming collisions and misuse


There are already myriad ways for people to abuse Gherkin and get themselves into a mess. I’m not really convinced that this is a good reason for not adding a feature that other people are saying they would find useful.
Would you mind holding fire for a bit while we explore this with Ken and see where it leads?
No worries Matt, my mistake.

😃 thanks! 👍

Post by k***@gmail.com
cheers,
Matt
—
[phone]
https://cucumber.io <https://cucumber.io/>
https://twitter.com/mattwynne <https://twitter.com/mattwynne>
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited company registered in Scotland, number 456793.
Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street, Edinburgh EH2 2PR, Scotland, United Kingdom <https://maps.google.com/?q=5+Rose+Street,+Edinburgh+EH2+2PR,+Scotland,+United+Kingdom&entry=gmail&source=g>.
CONFIDENTIALITY NOTICE: The information in this e-mail is confidential and privileged; it is intended for use solely by the individual or entity named as the recipient hereof. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient is strictly prohibited and may violate applicable laws. If you have received this e-mail in error, please delete the original message and notify us by email immediately. Thank you. Cucumber Ltd.
--
Posting rules: http://cukes.info/posting-rules.html <http://cukes.info/posting-rules.html>
---
You received this message because you are subscribed to a topic in the Google Groups "Cukes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe <https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
--
Posting rules: http://cukes.info/posting-rules.html <http://cukes.info/posting-rules.html>
---
You received this message because you are subscribed to a topic in the Google Groups "Cukes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe <https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

cheers,
Matt

—
[phone]
***@cucumber.io
https://cucumber.io
https://twitter.com/mattwynne
--
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited
company registered in Scotland, number 456793.


Registered address:
Cucumber Ltd, The Melting Pot, 5 Rose Street, Edinburgh EH2 2PR, Scotland,
United Kingdom.
CONFIDENTIALITY NOTICE: The information in this e-mail is
confidential and privileged; it is intended for use solely by the
individual or entity named as the recipient hereof. Disclosure, copying,
distribution, or use of the contents of this e-mail by persons other than
the intended recipient is strictly prohibited and may violate applicable
laws. If you have received this e-mail in error, please delete the original
message and notify us by email immediately. Thank you. Cucumber Ltd.

[k***@gmail.com]

Post by Matt Wynne
@Ken I’m wondering, would one way of solving this problem be to add a new
keyword to Gherkin that acts like a global Background, say we call it
Define? You could use it to specify global terms like in Gherkin this which
# in Gherkin (somewhere)
Given the Maximum Allowed Value is 500
That's a possibility, particularly if the missing step def creator did the

creation of @maximum_allowed_value


Another possibility could be:

Define Maximum Allowed Value is 500

The question is when would the substitution be made. It could be that

Given the value is less that the Maximum Allowed Value

matches the step def

"the value is less that the Maximum Allowed Value"
i
or it could match a step def with a parameter :

"the value ish less that the %d"

Ken

Post by Matt Wynne
Given(“the Maximum Allowed Value is {int}”) do |max|
@maximum_allowed_value = max
end
When(“the value is less that the Maximum Allowed Value”) do
@value = @maximum_allowed_value - 1
end
WDYT?
One of the reasons for using #defines is to clearly indicate domain terms
(as in Domain Driven Design) which should be global as you mentioned. As
George suggested, he didn't like the term MAXIMUM_VALUE, he would rather
have it be MAXIMUM_ALLOWED_VALUE. By agreeing on the term and using it
everywhere, then misunderstanding decreases.
When value is less than maximum value
When values is greater than maximum allowed value
Then one might ask whether these are referring to the same domain term and
simply expressed with different text.
When value is less than MAXIMUM_VALUE
When values is greater than MAXIMUM_ALLOWED_VALUE
The terms stand out.
With free text, it's less easy to spot domain terms unless they are
denoted somehow. If the triad did not like all caps, they could use
MaximumValue or some other convention to designate the terms.

Post by Matt Wynne

Post by k***@gmail.com
George,
I'm still exploring potential patterns. However some of the things I
*Business Rule Pattern*
Business person creates a spreadsheet that contains a table representing
a requirement (a business rule or tests for that business rule).
Developers copy and paste that table into a feature file as a table
(typically an example table). Now the business person updates the
values. The developers need to update the feature file manually.
One alternative used was to read the spreadsheet into the test via an
Excel library. Changes to the spreadsheet would be then incorporated into
the test. The code to read the Excel spreadsheet was a bit of work.
So here's an alternative using the proposed #include.
Business person updates the spreadsheet and saves it as a CSV file
in a shared location.
Build script copies the CSV file and checks it into source
repository. (If business person could easily update source repository,
this could be combined with previous step)
Preprocessor run, inserts the file, then Cucumber runs.
Output shows results.

I'm wondering: if we had a native way to pull table content into Gherkin
from a CSV file, would that solve this problem for you?
e.g.
|<< maximum_values.csv >>|
When I ...

Post by k***@gmail.com
*Domain Term Pattern*
When value is greater than 200
....
When value is equal to 200
#define MAXIMUM_VALUE 200
When value is greater than MAXIMUM_VALUE
...
When value is equal to MAXIMUM_VALUE
This is equivalent to using named constants in code, which makes code
much easier to maintain. In addition, it creates a domain term -
MAXIMUM_VALUE that is shared among the team and appears in the feature file
for documentation.

I like the solution George suggests (which in fact he taught me) of
writing these in Gherkin steps, often in a Background.
Does that not work for you because you want these terms to be global?

Post by k***@gmail.com

Post by k***@gmail.com
Ken,

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a

feature

Post by k***@gmail.com
file represents and how it is used. If a feature file does not

contain

Post by k***@gmail.com
any data, then there is no need for this preprocessor, as you
illustrated. The more data one places in a feature file, then the
possibility of values that represent one domain term can be
duplicated. Having #defines for those terms can make for easier
maintenance. In addition, giving names to values helps create
ubiquitous terms for understanding for the entire team (e.g.
MAXIMUM_VALUE).

As Brian Marick says, "An example would be handy right now."
Have you used this and found patterns that have worked well, or are you
still exploring and looking for those patterns? If you have found
patterns, would you share examples of them with this list?
- George

Post by k***@gmail.com
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to
contain these values reduces the number of step definitions that need

to

Post by k***@gmail.com
be created.
As far as CSV files, see my response to Halfordian Golfer.
Ken

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.
cheers,
Matt
—
[phone]
https://cucumber.io
https://twitter.com/mattwynne
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited
company registered in Scotland, number 456793.
Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street,
Edinburgh EH2 2PR, Scotland, United Kingdom.
CONFIDENTIALITY NOTICE: The information in this e-mail is confidential and
privileged; it is intended for use solely by the individual or entity named
as the recipient hereof. Disclosure, copying, distribution, or use of the
contents of this e-mail by persons other than the intended recipient is
strictly prohibited and may violate applicable laws. If you have received
this e-mail in error, please delete the original message and notify us by
email immediately. Thank you. Cucumber Ltd.

[Matt Wynne]

Post by Matt Wynne
# in Gherkin (somewhere)
Given the Maximum Allowed Value is 500
Define Maximum Allowed Value is 500
The question is when would the substitution be made. It could be that
Given the value is less that the Maximum Allowed Value
matches the step def
"the value is less that the Maximum Allowed Value"
i
"the value ish less that the %d"
Ken

We have a new thing in Cucumber called parameter types[1] which, if these Define steps became simply global Givens, could I think be used to set up a placeholder that would then be substituted in whether the name of the domain term was used.

[1] https://cucumber.io/blog/2017/07/26/announcing-cucumber-expressions <https://cucumber.io/blog/2017/07/26/announcing-cucumber-expressions>

Ken, do you think it’s worth us turning this specific idea (a global Background) into a ticket on the Gherkin repo for further discussion there?

Post by Matt Wynne
Given(“the Maximum Allowed Value is {int}”) do |max|
@maximum_allowed_value = max
end
When(“the value is less that the Maximum Allowed Value”) do
@value = @maximum_allowed_value - 1
end
WDYT?

One of the reasons for using #defines is to clearly indicate domain terms (as in Domain Driven Design) which should be global as you mentioned. As George suggested, he didn't like the term MAXIMUM_VALUE, he would rather have it be MAXIMUM_ALLOWED_VALUE. By agreeing on the term and using it everywhere, then misunderstanding decreases.
When value is less than maximum value
When values is greater than maximum allowed value
Then one might ask whether these are referring to the same domain term and simply expressed with different text.
When value is less than MAXIMUM_VALUE
When values is greater than MAXIMUM_ALLOWED_VALUE
The terms stand out.
With free text, it's less easy to spot domain terms unless they are denoted somehow. If the triad did not like all caps, they could use MaximumValue or some other convention to designate the terms.
George,
Business Rule Pattern
Business person creates a spreadsheet that contains a table representing a requirement (a business rule or tests for that business rule). Developers copy and paste that table into a feature file as a table (typically an example table). Now the business person updates the values. The developers need to update the feature file manually.
One alternative used was to read the spreadsheet into the test via an Excel library. Changes to the spreadsheet would be then incorporated into the test. The code to read the Excel spreadsheet was a bit of work.
So here's an alternative using the proposed #include.
Business person updates the spreadsheet and saves it as a CSV file in a shared location.
Build script copies the CSV file and checks it into source repository. (If business person could easily update source repository, this could be combined with previous step)
Preprocessor run, inserts the file, then Cucumber runs.
Output shows results.
I'm wondering: if we had a native way to pull table content into Gherkin from a CSV file, would that solve this problem for you?
e.g.
|<< maximum_values.csv >>|
When I ...
Domain Term Pattern
When value is greater than 200
....
When value is equal to 200
#define MAXIMUM_VALUE 200
When value is greater than MAXIMUM_VALUE
...
When value is equal to MAXIMUM_VALUE
This is equivalent to using named constants in code, which makes code much easier to maintain. In addition, it creates a domain term - MAXIMUM_VALUE that is shared among the team and appears in the feature file for documentation.
I like the solution George suggests (which in fact he taught me) of writing these in Gherkin steps, often in a Background.
Does that not work for you because you want these terms to be global?
Ken,

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not contain
any data, then there is no need for this preprocessor, as you
illustrated. The more data one places in a feature file, then the
possibility of values that represent one domain term can be
duplicated. Having #defines for those terms can make for easier
maintenance. In addition, giving names to values helps create
ubiquitous terms for understanding for the entire team (e.g.
MAXIMUM_VALUE).

As Brian Marick says, "An example would be handy right now."
Have you used this and found patterns that have worked well, or are you
still exploring and looking for those patterns? If you have found
patterns, would you share examples of them with this list?
- George

Post by k***@gmail.com
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to
contain these values reduces the number of step definitions that need to
be created.
As far as CSV files, see my response to Halfordian Golfer.
Ken

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com <http://blog.gdinwiddie.com/>
Software Development http://www.idiacomputing.com <http://www.idiacomputing.com/>
Consultant and Coach http://www.agilemaryland.org <http://www.agilemaryland.org/>
----------------------------------------------------------------------
--
Posting rules: http://cukes.info/posting-rules.html <http://cukes.info/posting-rules.html>
---
You received this message because you are subscribed to a topic in the Google Groups "Cukes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe <https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

cheers,
Matt
—
[phone]
https://cucumber.io <https://cucumber.io/>
https://twitter.com/mattwynne <https://twitter.com/mattwynne>
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited company registered in Scotland, number 456793.
Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street, Edinburgh EH2 2PR, Scotland, United Kingdom.
CONFIDENTIALITY NOTICE: The information in this e-mail is confidential and privileged; it is intended for use solely by the individual or entity named as the recipient hereof. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient is strictly prohibited and may violate applicable laws. If you have received this e-mail in error, please delete the original message and notify us by email immediately. Thank you. Cucumber Ltd.
--
Posting rules: http://cukes.info/posting-rules.html <http://cukes.info/posting-rules.html>
---
You received this message because you are subscribed to a topic in the Google Groups "Cukes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe <https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

cheers,
Matt

—
[phone]
***@cucumber.io
https://cucumber.io
https://twitter.com/mattwynne
--
Inspiring meaningful, effective collaboration in every software delivery
organisation.





The Cucumber logo is the intellectual property of
Cucumber Ltd, a limited company registered in Scotland, number 456793.



Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street, Edinburgh
EH2 2PR, Scotland, United Kingdom.
CONFIDENTIALITY NOTICE: The information
in this e-mail is confidential and privileged; it is intended for use
solely by the individual or entity named as the recipient hereof.
Disclosure, copying, distribution, or use of the contents of this e-mail by
persons other than the intended recipient is strictly prohibited and may
violate applicable laws. If you have received this e-mail in error, please
delete the original message and notify us by email immediately. Thank you.
Cucumber Ltd.

[k***@gmail.com]

We have a new thing in Cucumber called *parameter types[1]* which, if
these Define steps became simply global Givens, could I think be used to
set up a placeholder that would then be substituted in whether the name of
the domain term was used.
[1] https://cucumber.io/blog/2017/07/26/announcing-cucumber-expressions
Ken, do you think it’s worth us turning this specific idea (a global
Background) into a ticket on the Gherkin repo for further discussion there?
That's an interesting idea. As understand them to work from that

description, one could have:

ParameterType(
name: 'MaximumValue',
regexp: /(MaximumValue)/,
transformer: -> (identifer) { 200 })

And then:

When value is less than MaximumValue
would have MaximumValue replaced by 200

Here's another example following along the previous ideas.

#defines (or Define if a Gherkin keyword)
| SomeOne| "Bill" |
| SomeOneElse | "Jane" |
| ValidMessage | "Hi" |
| DistanceInRange | 100 |
| MaximumDelay | 2 |

Scenario: Shout Out
Given that SomeOne and SomeOneElse are in DistanceInRange
When SomeOne shouts a ValidMessage
Then SomeOneElse sees ValidMessage before MaximumDelay

This abstracts out a specific example into a generic one.
The preprocessor would transform it back to a specific one.

The question is whether having the specific values be available in the feature file or having them in the glue code would be preferable.

If you think putting this on the Gherkin repo would be a good idea, I'll do it. I was keeping things as a preprocessor for more experimentation purposes.



Ken

Post by Matt Wynne
Given(“the Maximum Allowed Value is {int}”) do |max|
@maximum_allowed_value = max
end
When(“the value is less that the Maximum Allowed Value”) do
@value = @maximum_allowed_value - 1
end
WDYT?
One of the reasons for using #defines is to clearly indicate domain terms
(as in Domain Driven Design) which should be global as you mentioned. As
George suggested, he didn't like the term MAXIMUM_VALUE, he would rather
have it be MAXIMUM_ALLOWED_VALUE. By agreeing on the term and using it
everywhere, then misunderstanding decreases.
When value is less than maximum value
When values is greater than maximum allowed value
Then one might ask whether these are referring to the same domain term
and simply expressed with different text.
When value is less than MAXIMUM_VALUE
When values is greater than MAXIMUM_ALLOWED_VALUE
The terms stand out.
With free text, it's less easy to spot domain terms unless they are
denoted somehow. If the triad did not like all caps, they could use
MaximumValue or some other convention to designate the terms.

Post by Matt Wynne

Post by k***@gmail.com
George,
I'm still exploring potential patterns. However some of the things I
*Business Rule Pattern*
Business person creates a spreadsheet that contains a table
representing a requirement (a business rule or tests for that business
rule). Developers copy and paste that table into a feature file as a
table (typically an example table). Now the business person updates the
values. The developers need to update the feature file manually.
One alternative used was to read the spreadsheet into the test via an
Excel library. Changes to the spreadsheet would be then incorporated into
the test. The code to read the Excel spreadsheet was a bit of work.
So here's an alternative using the proposed #include.
Business person updates the spreadsheet and saves it as a CSV file
in a shared location.
Build script copies the CSV file and checks it into source
repository. (If business person could easily update source repository,
this could be combined with previous step)
Preprocessor run, inserts the file, then Cucumber runs.
Output shows results.

I'm wondering: if we had a native way to pull table content into Gherkin
from a CSV file, would that solve this problem for you?
e.g.
|<< maximum_values.csv >>|
When I ...

Post by k***@gmail.com
*Domain Term Pattern*
When value is greater than 200
....
When value is equal to 200
#define MAXIMUM_VALUE 200
When value is greater than MAXIMUM_VALUE
...
When value is equal to MAXIMUM_VALUE
This is equivalent to using named constants in code, which makes code
much easier to maintain. In addition, it creates a domain term -
MAXIMUM_VALUE that is shared among the team and appears in the feature file
for documentation.

I like the solution George suggests (which in fact he taught me) of
writing these in Gherkin steps, often in a Background.
Does that not work for you because you want these terms to be global?

Post by k***@gmail.com

Post by k***@gmail.com
Ken,

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a

feature

Post by k***@gmail.com
file represents and how it is used. If a feature file does not

contain

Post by k***@gmail.com
any data, then there is no need for this preprocessor, as you
illustrated. The more data one places in a feature file, then the
possibility of values that represent one domain term can be
duplicated. Having #defines for those terms can make for easier
maintenance. In addition, giving names to values helps create
ubiquitous terms for understanding for the entire team (e.g.
MAXIMUM_VALUE).

As Brian Marick says, "An example would be handy right now."
Have you used this and found patterns that have worked well, or are you
still exploring and looking for those patterns? If you have found
patterns, would you share examples of them with this list?
- George

Post by k***@gmail.com
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to
contain these values reduces the number of step definitions that

need to

Post by k***@gmail.com
be created.
As far as CSV files, see my response to Halfordian Golfer.
Ken

--
----------------------------------------------------------------------
* George Dinwiddie *
http://blog.gdinwiddie.com
Software Development
http://www.idiacomputing.com
Consultant and Coach
http://www.agilemaryland.org
----------------------------------------------------------------------

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.
cheers,
Matt
—
[phone]
https://cucumber.io
https://twitter.com/mattwynne
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited
company registered in Scotland, number 456793.
Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street,
Edinburgh EH2 2PR, Scotland, United Kingdom.
CONFIDENTIALITY NOTICE: The information in this e-mail is confidential
and privileged; it is intended for use solely by the individual or entity
named as the recipient hereof. Disclosure, copying, distribution, or use of
the contents of this e-mail by persons other than the intended recipient is
strictly prohibited and may violate applicable laws. If you have received
this e-mail in error, please delete the original message and notify us by
email immediately. Thank you. Cucumber Ltd.

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.
cheers,
Matt
—
[phone]
https://cucumber.io
https://twitter.com/mattwynne
Inspiring meaningful, effective collaboration in every software delivery
organisation.
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited
company registered in Scotland, number 456793.
Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street,
Edinburgh EH2 2PR, Scotland, United Kingdom.
CONFIDENTIALITY NOTICE: The information in this e-mail is confidential and
privileged; it is intended for use solely by the individual or entity named
as the recipient hereof. Disclosure, copying, distribution, or use of the
contents of this e-mail by persons other than the intended recipient is
strictly prohibited and may violate applicable laws. If you have received
this e-mail in error, please delete the original message and notify us by
email immediately. Thank you. Cucumber Ltd.

[Matt Wynne]

Post by k***@gmail.com

We have a new thing in Cucumber called *parameter types[1]* which, if
these Define steps became simply global Givens, could I think be used to
set up a placeholder that would then be substituted in whether the name of
the domain term was used.
[1] https://cucumber.io/blog/2017/07/26/announcing-cucumber-expressions
Ken, do you think it’s worth us turning this specific idea (a global
Background) into a ticket on the Gherkin repo for further discussion there?
That's an interesting idea. As understand them to work from that

ParameterType(
name: 'MaximumValue',
regexp: /(MaximumValue)/,
transformer: -> (identifer) { 200 })

Well, kinda. I more thought that you'd want to keep the 200 on the surface
in the Gherkin, so something more like:

ParameterType(
name: 'MaximumValue',
regexp: /(MaximumValue)/,
transformer: -> (identifer) { @maximum_value })

Given(/the MaximumValue is {int}/) do |max|
@maximum_value = max
end

Post by k***@gmail.com
When value is less than MaximumValue
would have MaximumValue replaced by 200
Here's another example following along the previous ideas.
#defines (or Define if a Gherkin keyword)
| SomeOne| "Bill" |
| SomeOneElse | "Jane" |
| ValidMessage | "Hi" |
| DistanceInRange | 100 |
| MaximumDelay | 2 |
Scenario: Shout Out
Given that SomeOne and SomeOneElse are in DistanceInRange
When SomeOne shouts a ValidMessage
Then SomeOneElse sees ValidMessage before MaximumDelay
This abstracts out a specific example into a generic one.
The preprocessor would transform it back to a specific one.
The question is whether having the specific values be available in the feature file or having them in the glue code would be preferable.
My thinking is that if these values are important to the example, it would

make sense to surface them to the reader, at least at some level.

What do you think?

Post by k***@gmail.com
If you think putting this on the Gherkin repo would be a good idea, I'll do it. I was keeping things as a preprocessor for more experimentation purposes.
Ken

Post by Matt Wynne
Given(“the Maximum Allowed Value is {int}”) do |max|
@maximum_allowed_value = max
end
When(“the value is less that the Maximum Allowed Value”) do
@value = @maximum_allowed_value - 1
end
WDYT?
One of the reasons for using #defines is to clearly indicate domain
terms (as in Domain Driven Design) which should be global as you mentioned.
As George suggested, he didn't like the term MAXIMUM_VALUE, he would
rather have it be MAXIMUM_ALLOWED_VALUE. By agreeing on the term and
using it everywhere, then misunderstanding decreases.
When value is less than maximum value
When values is greater than maximum allowed value
Then one might ask whether these are referring to the same domain term
and simply expressed with different text.
When value is less than MAXIMUM_VALUE
When values is greater than MAXIMUM_ALLOWED_VALUE
The terms stand out.
With free text, it's less easy to spot domain terms unless they are
denoted somehow. If the triad did not like all caps, they could use
MaximumValue or some other convention to designate the terms.

Post by Matt Wynne

Post by k***@gmail.com
George,
I'm still exploring potential patterns. However some of the things I
*Business Rule Pattern*
Business person creates a spreadsheet that contains a table
representing a requirement (a business rule or tests for that business
rule). Developers copy and paste that table into a feature file as a
table (typically an example table). Now the business person updates the
values. The developers need to update the feature file manually.
One alternative used was to read the spreadsheet into the test via an
Excel library. Changes to the spreadsheet would be then incorporated into
the test. The code to read the Excel spreadsheet was a bit of work.
So here's an alternative using the proposed #include.
Business person updates the spreadsheet and saves it as a CSV file
in a shared location.
Build script copies the CSV file and checks it into source
repository. (If business person could easily update source repository,
this could be combined with previous step)
Preprocessor run, inserts the file, then Cucumber runs.
Output shows results.

I'm wondering: if we had a native way to pull table content into
Gherkin from a CSV file, would that solve this problem for you?
e.g.
|<< maximum_values.csv >>|
When I ...

Post by k***@gmail.com
*Domain Term Pattern*
When value is greater than 200
....
When value is equal to 200
#define MAXIMUM_VALUE 200
When value is greater than MAXIMUM_VALUE
...
When value is equal to MAXIMUM_VALUE
This is equivalent to using named constants in code, which makes code
much easier to maintain. In addition, it creates a domain term -
MAXIMUM_VALUE that is shared among the team and appears in the feature file
for documentation.

I like the solution George suggests (which in fact he taught me) of
writing these in Gherkin steps, often in a Background.
Does that not work for you because you want these terms to be global?

Post by k***@gmail.com

Post by k***@gmail.com
Ken,

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a

feature

Post by k***@gmail.com
file represents and how it is used. If a feature file does not

contain

Post by k***@gmail.com
any data, then there is no need for this preprocessor, as you
illustrated. The more data one places in a feature file, then the
possibility of values that represent one domain term can be
duplicated. Having #defines for those terms can make for easier
maintenance. In addition, giving names to values helps create
ubiquitous terms for understanding for the entire team (e.g.
MAXIMUM_VALUE).

As Brian Marick says, "An example would be handy right now."
Have you used this and found patterns that have worked well, or are you
still exploring and looking for those patterns? If you have found
patterns, would you share examples of them with this list?
- George

Post by k***@gmail.com
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to
contain these values reduces the number of step definitions that

need to

Post by k***@gmail.com
be created.
As far as CSV files, see my response to Halfordian Golfer.
Ken

--
----------------------------------------------------------------------
* George Dinwiddie *
http://blog.gdinwiddie.com
Software Development
http://www.idiacomputing.com
Consultant and Coach
http://www.agilemaryland.org
----------------------------------------------------------------------

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.
cheers,
Matt
—
[phone] <+44%207974%20430184>
https://cucumber.io
https://twitter.com/mattwynne
The Cucumber logo is the intellectual property of Cucumber Ltd, a
limited company registered in Scotland, number 456793.
Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street,
Edinburgh EH2 2PR, Scotland, United Kingdom
<https://maps.google.com/?q=5+Rose+Street,+Edinburgh+EH2+2PR,+Scotland,+United+Kingdom&entry=gmail&source=g>
.
CONFIDENTIALITY NOTICE: The information in this e-mail is confidential
and privileged; it is intended for use solely by the individual or entity
named as the recipient hereof. Disclosure, copying, distribution, or use of
the contents of this e-mail by persons other than the intended recipient is
strictly prohibited and may violate applicable laws. If you have received
this e-mail in error, please delete the original message and notify us by
email immediately. Thank you. Cucumber Ltd.

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.
cheers,
Matt
—
[phone] <+44%207974%20430184>
https://cucumber.io
https://twitter.com/mattwynne
Inspiring meaningful, effective collaboration in every software delivery
organisation.
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited
company registered in Scotland, number 456793.
Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street,
Edinburgh EH2 2PR, Scotland, United Kingdom
<https://maps.google.com/?q=5+Rose+Street,+Edinburgh+EH2+2PR,+Scotland,+United+Kingdom&entry=gmail&source=g>
.
CONFIDENTIALITY NOTICE: The information in this e-mail is confidential
and privileged; it is intended for use solely by the individual or entity
named as the recipient hereof. Disclosure, copying, distribution, or use of
the contents of this e-mail by persons other than the intended recipient is
strictly prohibited and may violate applicable laws. If you have received
this e-mail in error, please delete the original message and notify us by
email immediately. Thank you. Cucumber Ltd.

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

--
Inspiring meaningful, effective collaboration in every software delivery
organisation.





The Cucumber logo is the intellectual property of
Cucumber Ltd, a limited company registered in Scotland, number 456793.



Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street, Edinburgh
EH2 2PR, Scotland, United Kingdom.
CONFIDENTIALITY NOTICE: The information
in this e-mail is confidential and privileged; it is intended for use
solely by the individual or entity named as the recipient hereof.
Disclosure, copying, distribution, or use of the contents of this e-mail by
persons other than the intended recipient is strictly prohibited and may
violate applicable laws. If you have received this e-mail in error, please
delete the original message and notify us by email immediately. Thank you.
Cucumber Ltd.

[k***@gmail.com]

Post by Matt Wynne
Well, kinda. I more thought that you'd want to keep the 200 on the surface
ParameterType(
name: 'MaximumValue',
regexp: /(MaximumValue)/,
Given(/the MaximumValue is {int}/) do |max|
@maximum_value = max
end

I really like the idea of a Define keyword. It might allow both

Define MaximumAllowedValue 200

and

Define:
|MaximumAllowedValue|200|
|SomethingElse| 300|

One key idea as you mentioned is to have the 200 value transparent to the
reader of the feature. Another is to have the domain term
MaximumAllowedValue be part of the ubiquitous language. Taking a key from
wikis, the syntax of a Define term could be anything in camel case. That
would keep the term visibly separated from the rest of the statement. The
parser could denote any undefined terms.

Ken




#defines (or Define if a Gherkin keyword)

Post by Matt Wynne

Post by k***@gmail.com
| SomeOne| "Bill" |
| SomeOneElse | "Jane" |
| ValidMessage | "Hi" |
| DistanceInRange | 100 |
| MaximumDelay | 2 |
Scenario: Shout Out
Given that SomeOne and SomeOneElse are in DistanceInRange
When SomeOne shouts a ValidMessage
Then SomeOneElse sees ValidMessage before MaximumDelay

[k***@gmail.com]

Post by k***@gmail.com
I really like the idea of a Define keyword. It might allow both
Define MaximumAllowedValue 200
and
|MaximumAllowedValue|200|
|SomethingElse| 300|
Just thought of another thing that could be added that goes along with the

Parameter Types. Suppose there was one like:

ParameterType(
name: 'Dollar',
regexp: /(\$?\d+\.?)/,
transformer: -> (identifer) { new Dollar(identifier) })



Define MaximumAllowedValue is 200 as Dollar

or

Define:
|MaximumAllowedValue | 200 | Dollar |
|SomethingElse | 300 | Dollar |

Now the domain terms can have formatting applied to them to make sure they
match up to the expected parameter type when used.

Post by k***@gmail.com
Ken

[Matt Wynne]

Post by k***@gmail.com
I really like the idea of a Define keyword. It might allow both
Define MaximumAllowedValue 200
and
|MaximumAllowedValue|200|
|SomethingElse| 300|
ParameterType(
name: 'Dollar',
regexp: /(\$?\d+\.?)/,
transformer: -> (identifer) { new Dollar(identifier) }
)
Define MaximumAllowedValue is 200 as Dollar
or
|MaximumAllowedValue | 200 | Dollar |
|SomethingElse | 300 | Dollar |
Now the domain terms can have formatting applied to them to make sure they match up to the expected parameter type when used.

Yep that’s pretty much how parameter types are intended to be used!

To be clear, I’m thinking we would be best to add Define: as another keyword a lot like Background:, but applying to all scenarios in your whole suite. It would have one or more steps, and it would be up to the step definitions to use them in a way that added these definitions of terms.

e.g.

Define:
Given the MaximumAllowedValue is $200

It would be really useful to get some triangulation on this. Is there anyone else on this list who thinks they might make use of this feature?

Post by k***@gmail.com
Ken
--
Posting rules: http://cukes.info/posting-rules.html <http://cukes.info/posting-rules.html>
---
You received this message because you are subscribed to a topic in the Google Groups "Cukes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe <https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

cheers,
Matt

—
[phone]
***@cucumber.io
https://cucumber.io
https://twitter.com/mattwynne
--
Inspiring meaningful, effective collaboration in every software delivery
organisation.





The Cucumber logo is the intellectual property of
Cucumber Ltd, a limited company registered in Scotland, number 456793.



Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street, Edinburgh
EH2 2PR, Scotland, United Kingdom.
CONFIDENTIALITY NOTICE: The information
in this e-mail is confidential and privileged; it is intended for use
solely by the individual or entity named as the recipient hereof.
Disclosure, copying, distribution, or use of the contents of this e-mail by
persons other than the intended recipient is strictly prohibited and may
violate applicable laws. If you have received this e-mail in error, please
delete the original message and notify us by email immediately. Thank you.
Cucumber Ltd.

[aslak hellesoy]

Post by k***@gmail.com

Post by k***@gmail.com
I really like the idea of a Define keyword. It might allow both
Define MaximumAllowedValue 200
and
|MaximumAllowedValue|200|
|SomethingElse| 300|
Just thought of another thing that could be added that goes along with

ParameterType(
name: 'Dollar',
regexp: /(\$?\d+\.?)/,
transformer: -> (identifer) { new Dollar(identifier) })
Define MaximumAllowedValue is 200 as Dollar
or
|MaximumAllowedValue | 200 | Dollar |
|SomethingElse | 300 | Dollar |
Now the domain terms can have formatting applied to them to make sure they
match up to the expected parameter type when used.
Yep that’s pretty much how parameter types are intended to be used!
To be clear, I’m thinking we would be best to add Define: as another
keyword a lot like Background:, but applying to all scenarios in your whole
suite.

That won’t work if it’s defined in a.feature and you only run b.feature.

I’m not very keen on adding more “programmer” features to Gherkin. That’s
been my stance for 10 years now.

Aslak

It would have one or more steps, and it would be up to the step definitions

Post by k***@gmail.com
to use them in a way that added these definitions of terms.
e.g.
Given the MaximumAllowedValue is $200
It would be really useful to get some triangulation on this. Is there
anyone else on this list who thinks they might make use of this feature?
Ken
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.
cheers,
Matt
—
[phone]
https://cucumber.io
https://twitter.com/mattwynne
Inspiring meaningful, effective collaboration in every software delivery
organisation.
The Cucumber logo is the intellectual property of Cucumber Ltd, a limited
company registered in Scotland, number 456793.
Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street,
Edinburgh EH2 2PR, Scotland, United Kingdom
<https://maps.google.com/?q=5+Rose+Street,+Edinburgh+EH2+2PR,+Scotland,+United+Kingdom&entry=gmail&source=g>
.
CONFIDENTIALITY NOTICE: The information in this e-mail is confidential and
privileged; it is intended for use solely by the individual or entity named
as the recipient hereof. Disclosure, copying, distribution, or use of the
contents of this e-mail by persons other than the intended recipient is
strictly prohibited and may violate applicable laws. If you have received
this e-mail in error, please delete the original message and notify us by
email immediately. Thank you. Cucumber Ltd.
--
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.

[George Dinwiddie]

That won’t work if it’s defined in a.feature and you only run b.feature.

If it's going to be done, I suggest making it explicitly global. Perhaps
a somename.global file to hold this for all runs, no matter what feature
file or portion thereof is being run.

If there's ever a before_all and after_all at the gherkin level, it
could live here, too.

I’m not very keen on adding more “programmer” features to Gherkin.
That’s been my stance for 10 years now.

I thank you for that. I wonder if this is something that would
communicate with business users. It's awfully easy to accomplish the
same results in the code level, using a step definition to retrieve the
constant from the name.

E.g.,
When the customer withdraws the maximum amount
can be handled by a step definition that looks up what is the current
value defined for "maximum amount" and use that.

Aslak

My 2 cents,
George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[k***@gmail.com]

Post by George Dinwiddie

Post by aslak hellesoy
I’m not very keen on adding more “programmer” features to Gherkin.
That’s been my stance for 10 years now.

I thank you for that. I wonder if this is something that would
communicate with business users. It's awfully easy to accomplish the
same results in the code level, using a step definition to retrieve the
constant from the name.
E.g.,
When the customer withdraws the maximum amount
can be handled by a step definition that looks up what is the current
value defined for "maximum amount" and use that.
There are a couple of issues here. The first is domain terms. . If

the term Maximum Allowed Value is significant to the customer, then I feel
it should appear somewhere in the scenarios. The second is
transparency. If the value of Maximum Allowed Value is significant to the
customer, than it also should appear somewhere in the scenarios. I've
been in situations where both are of interest to the customer. Having a
consistent way of expressing a domain term and its value makes for more
readable scenarios. Others may not have had those situations.

If the #include filename (or equivalent) is added, then the defines can be
included where they are needed.

One could also use the defines as generic values, e.g.

define InvalidUserName fred(123)
When user enters InvalidUserNameis

instead of

When user enters fred(123)

I've seen a lot of scenarios where this added layer of abstraction can make
them more readable and decrease the number of step defs.

Ken

[k***@gmail.com]

There are at least three ways that domain terms and their values could be
visible in feature files. Here are some facets of each as I see them.





*Preprocessor*



#define MaximumAllowedValue 32

When amount is greater than MaximumAllowedValue



or


#define

| MaximumAllowedValue | 32 |

When amount is greater than MaximumAllowedValue


- No additional step definition code to implement
- Additional step in transformation (preprocessor)
- New "keyword" in feature files (but not in Gherkin)



*Code *



Background:

Given Defines are:

| MaximumAllowedValue | 32 |



The corresponding step def saves away these strings in a DefineCollection.

A step def that wants to use them would change from:



@Given (“^amount is greater than (\\d+)$")

void StepDefinition(int value){



To


@Given (“^amount is greater than (\\w+)$")

void StepDefinition(String inputValue){

int value = DefineCollection.getAsInt(inputValue);




- Uses current Gherkin syntax
- Change in step definitions needed where used





*New keyword *



Define:

Given the MaximumAllowedValue is 32



with step definitions containing:


ParameterType(

name: 'MaximumAllowedValue',

regexp: /(MaximumAllowedValue)/,

transformer: -> (identifer) { @maximum_value }

)

Given(/the MaximumAllowedValue is {int}/) do |max|

@maximum_value = max

end



- Requires ParameterType for each value

[Tim Walker]

[tim] I line below

Post by k***@gmail.com
There are at least three ways that domain terms and their values could be
visible in feature files. Here are some facets of each as I see them.
*Preprocessor*
#define MaximumAllowedValue 32
When amount is greater than MaximumAllowedValue
or
#define
| MaximumAllowedValue | 32 |
When amount is greater than MaximumAllowedValue
- No additional step definition code to implement
- Additional step in transformation (preprocessor)
- New "keyword" in feature files (but not in Gherkin)
*Code *
| MaximumAllowedValue | 32 |
The corresponding step def saves away these strings in a
DefineCollection.
@Given (“^amount is greater than (\\d+)$")
void StepDefinition(int value){
To
@Given (“^amount is greater than (\\w+)$")
void StepDefinition(String inputValue){
int value = DefineCollection.getAsInt(inputValue);
- Uses current Gherkin syntax
- Change in step definitions needed where used
*New keyword *
Given the MaximumAllowedValue is 32

[tim] I would very respectfully submit the Define: keyword is unnecessary
as the same thing could exist in a Background: with very little loss in
performance or expressiveness. Just my opinion. Thank you!

Post by k***@gmail.com
ParameterType(
name: 'MaximumAllowedValue',
regexp: /(MaximumAllowedValue)/,
)
Given(/the MaximumAllowedValue is {int}/) do |max|
@maximum_value = max
end
- Requires ParameterType for each value
--
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.

[Roberto Lo Giacco]

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not contain
any data, then there is no need for this preprocessor, as you illustrated.
The more data one places in a feature file, then the possibility of values
that represent one domain term can be duplicated. Having #defines for
those terms can make for easier maintenance. In addition, giving names
to values helps create ubiquitous terms for understanding for the entire
team (e.g. MAXIMUM_VALUE).
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to contain
these values reduces the number of step definitions that need to be
created.

True, but that could be achieved in a non programmer way:

Background
Given the system is set up for with
| param | value |
| maximum | 200 |
| minimum | 50 |
| min length | 6 |


When the user inputs a value above the maximum allowed value
Then an error is shown


You should now question yourself: is what is written above a functional
requirement or a test? If your answer is the former within your context,
than you are ok. If it's the latter than why bother use Gherkin?

Post by k***@gmail.com
As far as CSV files, see my response to Halfordian Golfer.

My take on that is if I need a CSV to describe a business rule then that
business rule doesn't require Gherkin. I would also question myself why I
call "business rule" a CSV file and if I'm misinterpreting the concept of
business rule if I am thinking as a developer, trying to squeeze business
rules in a tabular format rather than trying to describe the business rule
for what it is... Does a table communicate better than natural language?
We, as software developers, are used to communicating in ways our business
partners do not understand, but if we don't treat Gherkin as a tool for
bridging communication between those two parties, why should we bother?


Regards,
Roberto

[k***@gmail.com]

Roberto,

This is an experiment. I've introduced #defines to a select audience and
gotten positive feedback. However it appears they don't resonate with
you.

See my answer to George regarding CSV files. Tables are a natural form of
communication. I've seen them used in lots of places.

| Value | Result | Notes |
| 200 | Accepted | |
| 201 | Error | Above Maximum |
| 50 | Accepted | |
| 49 | Error | Below Minimum |


Ken

Post by Roberto Lo Giacco

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not contain
any data, then there is no need for this preprocessor, as you illustrated.
The more data one places in a feature file, then the possibility of values
that represent one domain term can be duplicated. Having #defines for
those terms can make for easier maintenance. In addition, giving names
to values helps create ubiquitous terms for understanding for the entire
team (e.g. MAXIMUM_VALUE).
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to contain
these values reduces the number of step definitions that need to be
created.

Background
Given the system is set up for with
| param | value |
| maximum | 200 |
| minimum | 50 |
| min length | 6 |
When the user inputs a value above the maximum allowed value
Then an error is shown
You should now question yourself: is what is written above a functional
requirement or a test? If your answer is the former within your context,
than you are ok. If it's the latter than why bother use Gherkin?

Post by k***@gmail.com
As far as CSV files, see my response to Halfordian Golfer.

My take on that is if I need a CSV to describe a business rule then that
business rule doesn't require Gherkin. I would also question myself why I
call "business rule" a CSV file and if I'm misinterpreting the concept of
business rule if I am thinking as a developer, trying to squeeze business
rules in a tabular format rather than trying to describe the business rule
for what it is... Does a table communicate better than natural language?
We, as software developers, are used to communicating in ways our business
partners do not understand, but if we don't treat Gherkin as a tool for
bridging communication between those two parties, why should we bother?
Regards,
Roberto

[k***@gmail.com]

Roberto,

I think I see where a misunderstanding lies.

I am experimenting with Gherkin to become a more useful tool for testing as
well as communication. One of the original purposes of Gherkin was as
an alternative to JUnit.

See https://dannorth.net/introducing-bdd/

Take a look at my Deliver Agile Session (you need to login as an agile
alliance member) https://lnkd.in/enCkUVf

There are two advantages:of using Gherkin

1.) The test is independent of the implementation. It specifies the
behavior of a unit.

2.) The test is readable by all members of the triad (customer, developer,
tester).


Ken

Post by Roberto Lo Giacco

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not contain
any data, then there is no need for this preprocessor, as you illustrated.
The more data one places in a feature file, then the possibility of values
that represent one domain term can be duplicated. Having #defines for
those terms can make for easier maintenance. In addition, giving names
to values helps create ubiquitous terms for understanding for the entire
team (e.g. MAXIMUM_VALUE).
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to contain
these values reduces the number of step definitions that need to be
created.

Background
Given the system is set up for with
| param | value |
| maximum | 200 |
| minimum | 50 |
| min length | 6 |
When the user inputs a value above the maximum allowed value
Then an error is shown
You should now question yourself: is what is written above a functional
requirement or a test? If your answer is the former within your context,
than you are ok. If it's the latter than why bother use Gherkin?

Post by k***@gmail.com
As far as CSV files, see my response to Halfordian Golfer.

My take on that is if I need a CSV to describe a business rule then that
business rule doesn't require Gherkin. I would also question myself why I
call "business rule" a CSV file and if I'm misinterpreting the concept of
business rule if I am thinking as a developer, trying to squeeze business
rules in a tabular format rather than trying to describe the business rule
for what it is... Does a table communicate better than natural language?
We, as software developers, are used to communicating in ways our business
partners do not understand, but if we don't treat Gherkin as a tool for
bridging communication between those two parties, why should we bother?
Regards,
Roberto

[Roberto Lo Giacco]

Post by k***@gmail.com
Roberto,
I think I see where a misunderstanding lies.
I am experimenting with Gherkin to become a more useful tool for testing
as well as communication. One of the original purposes of Gherkin was
as an alternative to JUnit.
See https://dannorth.net/introducing-bdd/

​Ken, did you notice the whole article written by Dan doesn't mention
Gherkin at all? Actually Gherkin was an addition to JBehave, it didn't
support Gherkin at the beginning... Nonetheless, if you look at JBehave
syntax, you'll find very quickly it does in fact have some common grounds
with JUnit (one above all, the After element), which is the main reason why
I'm not a fan of JBehave Story syntax... but that's more a personal taste
than anything.

Back on track, sorry for the diversion., I'll try to put two different hats
on my little head, just to word what I think are the two perspectives here.

As an experienced developer ​I wouldn't pick Gherkin (or Cucumber) over
JUnit for testing not even if my only option would be JUnit version 1.0.0:
Gherkin is not a testing framework, nor is Cucumber, and if they were, they
would have been a very very poor one.​

​As a business representative/product owner I couldn't care less if you
have tests behind a Gherkin file: all I would care is if the feature
described in the file accurately matches with what I need the software to
do. As a PO I've probably done that for years using Use Case Scenarios and
MS Word, but I would probably accept a different format if it can provide
the same or a better result​.

My opinion is Gherkin + Cucumber represent a decent bridge between these
two worlds, but it does provide the most of its value only if you walk this
bridge in one direction: from the specification to the tests.

What I am trying to say is that if your focus is on specifications and
requirements, than Gherkin can help you a lot in defining those in a manner
you can then decide what needs to be automatically tested, resolving the
need for validating the acceptance tests before the software gets into the
hands of the PO, who can get really frustrated by a failing software.
But if you are focused on testing than why use a language/framework which
doesn't even have an assertion structure? I mean, Cucumber by itself
doesn't even allow you to check if two strings are equal each other... And
I believe there is a good reason for the lack of those tools.
If my focus is on testing I would pick a testing framework and use it, like
JUnit, TestNG, etc... Something that helps me execute the checks I need to
perform to verify my assertions.

I perfectly understand the reasoning of Dan in his article and I've
personally partially experienced his very same frustrations during my
professional life, but I don't agree with you in summarizing it in
"Gherking (or JBehave, it doesn't really matter) was an alternative to
JUnit". My take from that article is the tool was intended to help you move
from TDD to BDD or, in other words, move from testing for the purpose of
verifying the code to checking the behaviour correctness.

It's a not a slight difference, but rather a huge leap: when we switch the
point of view, we also need to switch the language, stepping away from
computer programming and get our feet in the business language, the
language spoken by those who don't develop software.

Hence the natural language approach, hence the localization support and the
file format, hence the HTML reports: it must be readable and accessible to
people who don't have much of computer science in their DNA.

When we introduce pre-processor macros (#define and #include) we are
bringing this back into our programmer's lingo: sure, we can teach to our
business partners and product owners what #define and #include are and they
surely already understand tables, but is this what we should be doing?
Teaching them our geeky vocabulary?

I believe Gherkin and Cucumber aim at inverting this approach, letting the
business express their intentions using their own vocabulary, a vocabulary
that is finally shared between the parties.

Given I've signed up
I can log in
But only after I've confirmed my email address


Rather than


assertNotNull(username)
assertNotNull(password)
assertTrue(emailConfirmed)
assertEquals(username, storedUsername)
assertEquals(hash(password), storedPassword)



True, the above example is comparing potatoes and apples, I'm only trying
to express how distinct I see the world of testing from the world of
requirement specifications.

Post by k***@gmail.com
Take a look at my Deliver Agile Session (you need to login as an agile
alliance member) https://lnkd.in/enCkUVf

​Sorry, I'm not a member of such alliance, can't access it, but this
article on my blog
<https://rlogiacco.wordpress.com/2016/01/18/cucumber-is-not-a-testing-framework/>
is freely accessible.

​

Post by k***@gmail.com
There are two advantages:of using Gherkin
1.) The test is independent of the implementation. It specifies the
behavior of a unit.
2.) The test is readable by all members of the triad (customer, developer,
tester).

​I see... Your focus is on the tests. My take is different​:

1) the triad shares the same ubiquitous language

2) the specification is described in terms of what is needed, not on how it
has to be implemented (this is a very good match with Agile practices,
where you don't think on how things are going to be implemented beforehand,
but rather decide it when you start implementing)

3) The requirements are live and maintainable by all members of the triad

As I'm a plain user of Cucumber and not an agile guru or something, I can't
say my take is better than yours, but it's definitely very different: to
me, tests are far away from being the driver for Cucumber adoption.

Apologies for the length of my reply, I didn't realize it was so long
winded until I re-read it.

Thanks for the time,
Roberto

Post by k***@gmail.com
Ken

Post by Roberto Lo Giacco

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not contain
any data, then there is no need for this preprocessor, as you illustrated.
The more data one places in a feature file, then the possibility of values
that represent one domain term can be duplicated. Having #defines for
those terms can make for easier maintenance. In addition, giving names
to values helps create ubiquitous terms for understanding for the entire
team (e.g. MAXIMUM_VALUE).
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to contain
these values reduces the number of step definitions that need to be
created.

Background
Given the system is set up for with
| param | value |
| maximum | 200 |
| minimum | 50 |
| min length | 6 |
When the user inputs a value above the maximum allowed value
Then an error is shown
You should now question yourself: is what is written above a functional
requirement or a test? If your answer is the former within your context,
than you are ok. If it's the latter than why bother use Gherkin?

Post by k***@gmail.com
As far as CSV files, see my response to Halfordian Golfer.

My take on that is if I need a CSV to describe a business rule then that
business rule doesn't require Gherkin. I would also question myself why I
call "business rule" a CSV file and if I'm misinterpreting the concept of
business rule if I am thinking as a developer, trying to squeeze business
rules in a tabular format rather than trying to describe the business rule
for what it is... Does a table communicate better than natural language?
We, as software developers, are used to communicating in ways our business
partners do not understand, but if we don't treat Gherkin as a tool for
bridging communication between those two parties, why should we bother?
Regards,
Roberto

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[k***@gmail.com]

Roberto,

We do have different perspectives.

I've found Given/When/Then (similar to Arrange/Act/Assert,
PreConditions/Action/PostConditions, etc.) to be extremely useful in
expressing requirements/tests. In one sense, the only difference between
a requirement and a test is that the Then part checks the actual result to
the expected result.

Given/When/Then can have varying levels of expression:

Here's an generic one. It really doesn't have enough in it to be a test.

Given a calculator
When I add two numbers
The sum is correct

Here's a specific example, which is found during discovery phase This
could be used as a test.

Given a calculator
When I add 2 and 2
The sum is 4

Here's a specific example, which also documents domain terms (e.g. addend)


Given a calculator
When I add <addend1> and <addend2>
Then the sum is <sum>
Examples:
|addend1 |addend2 |sum|
|2 | 2 | 4 |

If the Given/When/Then is in this form, then it's ready for step defs to
turn in into an automated test. But it's also in the language of the
customer. So it has a dual purpose. Expressing the requirement and
being the test for the requirement. And a tester can easily add
additional examples to check on boundary conditions or edge cases without
having to do any copy and paste.


Ken

Post by Roberto Lo Giacco

Post by k***@gmail.com
Roberto,
I think I see where a misunderstanding lies.
I am experimenting with Gherkin to become a more useful tool for testing
as well as communication. One of the original purposes of Gherkin was
as an alternative to JUnit.
See https://dannorth.net/introducing-bdd/

​Ken, did you notice the whole article written by Dan doesn't mention
Gherkin at all? Actually Gherkin was an addition to JBehave, it didn't
support Gherkin at the beginning... Nonetheless, if you look at JBehave
syntax, you'll find very quickly it does in fact have some common grounds
with JUnit (one above all, the After element), which is the main reason why
I'm not a fan of JBehave Story syntax... but that's more a personal taste
than anything.
Back on track, sorry for the diversion., I'll try to put two different
hats on my little head, just to word what I think are the two perspectives
here.
As an experienced developer ​I wouldn't pick Gherkin (or Cucumber) over
Gherkin is not a testing framework, nor is Cucumber, and if they were, they
would have been a very very poor one.​
​As a business representative/product owner I couldn't care less if you
have tests behind a Gherkin file: all I would care is if the feature
described in the file accurately matches with what I need the software to
do. As a PO I've probably done that for years using Use Case Scenarios and
MS Word, but I would probably accept a different format if it can provide
the same or a better result​.
My opinion is Gherkin + Cucumber represent a decent bridge between these
two worlds, but it does provide the most of its value only if you walk this
bridge in one direction: from the specification to the tests.
What I am trying to say is that if your focus is on specifications and
requirements, than Gherkin can help you a lot in defining those in a manner
you can then decide what needs to be automatically tested, resolving the
need for validating the acceptance tests before the software gets into the
hands of the PO, who can get really frustrated by a failing software.
But if you are focused on testing than why use a language/framework which
doesn't even have an assertion structure? I mean, Cucumber by itself
doesn't even allow you to check if two strings are equal each other... And
I believe there is a good reason for the lack of those tools.
If my focus is on testing I would pick a testing framework and use it,
like JUnit, TestNG, etc... Something that helps me execute the checks I
need to perform to verify my assertions.
I perfectly understand the reasoning of Dan in his article and I've
personally partially experienced his very same frustrations during my
professional life, but I don't agree with you in summarizing it in
"Gherking (or JBehave, it doesn't really matter) was an alternative to
JUnit". My take from that article is the tool was intended to help you move
from TDD to BDD or, in other words, move from testing for the purpose of
verifying the code to checking the behaviour correctness.
It's a not a slight difference, but rather a huge leap: when we switch the
point of view, we also need to switch the language, stepping away from
computer programming and get our feet in the business language, the
language spoken by those who don't develop software.
Hence the natural language approach, hence the localization support and
the file format, hence the HTML reports: it must be readable and accessible
to people who don't have much of computer science in their DNA.
When we introduce pre-processor macros (#define and #include) we are
bringing this back into our programmer's lingo: sure, we can teach to our
business partners and product owners what #define and #include are and they
surely already understand tables, but is this what we should be doing?
Teaching them our geeky vocabulary?
I believe Gherkin and Cucumber aim at inverting this approach, letting the
business express their intentions using their own vocabulary, a vocabulary
that is finally shared between the parties.
Given I've signed up
I can log in
But only after I've confirmed my email address
Rather than
assertNotNull(username)
assertNotNull(password)
assertTrue(emailConfirmed)
assertEquals(username, storedUsername)
assertEquals(hash(password), storedPassword)
True, the above example is comparing potatoes and apples, I'm only trying
to express how distinct I see the world of testing from the world of
requirement specifications.

Post by k***@gmail.com
Take a look at my Deliver Agile Session (you need to login as an agile
alliance member) https://lnkd.in/enCkUVf

​Sorry, I'm not a member of such alliance, can't access it, but this
article on my blog
<https://rlogiacco.wordpress.com/2016/01/18/cucumber-is-not-a-testing-framework/>
is freely accessible.
​

Post by k***@gmail.com
There are two advantages:of using Gherkin
1.) The test is independent of the implementation. It specifies the
behavior of a unit.
2.) The test is readable by all members of the triad (customer,
developer, tester).

1) the triad shares the same ubiquitous language
2) the specification is described in terms of what is needed, not on how
it has to be implemented (this is a very good match with Agile practices,
where you don't think on how things are going to be implemented beforehand,
but rather decide it when you start implementing)
3) The requirements are live and maintainable by all members of the triad
As I'm a plain user of Cucumber and not an agile guru or something, I
to me, tests are far away from being the driver for Cucumber adoption.
Apologies for the length of my reply, I didn't realize it was so long
winded until I re-read it.
Thanks for the time,
Roberto

Post by k***@gmail.com
Ken

Post by Roberto Lo Giacco

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not contain
any data, then there is no need for this preprocessor, as you illustrated.
The more data one places in a feature file, then the possibility of values
that represent one domain term can be duplicated. Having #defines for
those terms can make for easier maintenance. In addition, giving names
to values helps create ubiquitous terms for understanding for the entire
team (e.g. MAXIMUM_VALUE).
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to contain
these values reduces the number of step definitions that need to be
created.

Background
Given the system is set up for with
| param | value |
| maximum | 200 |
| minimum | 50 |
| min length | 6 |
When the user inputs a value above the maximum allowed value
Then an error is shown
You should now question yourself: is what is written above a functional
requirement or a test? If your answer is the former within your context,
than you are ok. If it's the latter than why bother use Gherkin?

Post by k***@gmail.com
As far as CSV files, see my response to Halfordian Golfer.

My take on that is if I need a CSV to describe a business rule then that
business rule doesn't require Gherkin. I would also question myself why I
call "business rule" a CSV file and if I'm misinterpreting the concept of
business rule if I am thinking as a developer, trying to squeeze business
rules in a tabular format rather than trying to describe the business rule
for what it is... Does a table communicate better than natural language?
We, as software developers, are used to communicating in ways our business
partners do not understand, but if we don't treat Gherkin as a tool for
bridging communication between those two parties, why should we bother?
Regards,
Roberto

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[Roberto Lo Giacco]

Post by k***@gmail.com
Roberto,
We do have different perspectives.

​We do, indeed​

I've found Given/When/Then (similar to Arrange/Act/Assert,

Post by k***@gmail.com
PreConditions/Action/PostConditions, etc.) to be extremely useful in
expressing requirements/tests. In one sense, the only difference between
a requirement and a test is that the Then part checks the actual result to
the expected result.

​The difference I see is a test aims at verifying a requirement is
implemented as expected, so a test follows a requirement. If you follow me
on this thinking, then a feature file, expressed in Gherkin aims at
describing the requirement, the stepdefs, defined implementing the Cucumber
framework, help you realize the associated test which is implemented with
whatever testing framework of your choice.
If you keep along with me along this path it should be clear why I'm
against having #includes and #defines in the Gherkin while I have
absolutely no problem in having those included in the stepdefs: the former
describes the requirement, the latter is closer to the test.

Post by k***@gmail.com
Here's an generic one. It really doesn't have enough in it to be a test.
Given a calculator
When I add two numbers
The sum is correct
Here's a specific example, which is found during discovery phase This
could be used as a test.
Given a calculator
When I add 2 and 2
The sum is 4
Here's a specific example, which also documents domain terms (e.g. addend)
Given a calculator
When I add <addend1> and <addend2>
Then the sum is <sum>
|addend1 |addend2 |sum|
|2 | 2 | 4 |
If the Given/When/Then is in this form, then it's ready for step defs to
turn in into an automated test. But it's also in the language of the
customer. So it has a dual purpose. Expressing the requirement and
being the test for the requirement. And a tester can easily add
additional examples to check on boundary conditions or edge cases without
having to do any copy and paste.

​While I agree with you the above examples are increments in describing the
feature, they still don't represent a test: you are moving toward what is
commonly described as Specification By Example: the feature, initially
described in a generic form is refactored to use examples to increase it's
clearness. I feel that very different from a test and I truly believe you
too should: if we don't do that distinction it's a small step to mevo into
something like

Given the calculator has been started
When I set the addend 1 to <addend1>
And I set the addend 2 to <addend2>
Then the sum ​is <sum>
Examples:
#here all possible edge cases the QA might identify valid for testing

This last example is how a requirement can be easily torn into a test,
destroying its value of clearly communicating the requirement to the
occasional reader.

This gets even worse when the above is turned into

Given the calculator has been started
When I set the addend 1 to <addend1>
And I set the addend 2 to <addend2>
Then the sum ​is <sum>
Examples:
#include <edge-cases.csv>

This is the final step toward misuse: now not only it has been turned into
a test, but all the edge cases have been separated somewhere for the sake
of ease manipulation... But if they need to be changed, why are those in
there at all? If they can change then they are not part of the
requirement...

Now, if I want to create a test for the above feature I would simply go for:

open the CSV
for each row in the CSV
Calculator calc = new Calculator();
assertEquals(3, calc.sum(1,2) );

What is the difference between those two approaches? Why spend your time in
writing a test in natural language when you can code it straight away? The
communication? But aren't you progressively subtracting communication value
when you move important bits away from where the communication occurs? Or
may be those are not so important bits... then don't clutter the
communication channel with unecessary information...

Well, I guess you got my point already, it's simply a matter of opposite
point of views.

Post by k***@gmail.com
Ken

​BTW, I suggest you have a look at the posting rules ;-)

[k***@gmail.com]

Roberto,

As you suggest, having a table rather than #defines would be less
programmer-like. So instead of #defines, one might use syntax like:

#DefinedValues
| Maximum | 200 |
| Minimum | 50 |
| MinimumLength | 6 |

The preprocessor would read these lines and do the same substitutions.


Ken .

Post by Roberto Lo Giacco

Post by k***@gmail.com
Roberto,
I think I see where a misunderstanding lies.
I am experimenting with Gherkin to become a more useful tool for testing
as well as communication. One of the original purposes of Gherkin was
as an alternative to JUnit.
See https://dannorth.net/introducing-bdd/

​Ken, did you notice the whole article written by Dan doesn't mention
Gherkin at all? Actually Gherkin was an addition to JBehave, it didn't
support Gherkin at the beginning... Nonetheless, if you look at JBehave
syntax, you'll find very quickly it does in fact have some common grounds
with JUnit (one above all, the After element), which is the main reason why
I'm not a fan of JBehave Story syntax... but that's more a personal taste
than anything.
Back on track, sorry for the diversion., I'll try to put two different
hats on my little head, just to word what I think are the two perspectives
here.
As an experienced developer ​I wouldn't pick Gherkin (or Cucumber) over
Gherkin is not a testing framework, nor is Cucumber, and if they were, they
would have been a very very poor one.​
​As a business representative/product owner I couldn't care less if you
have tests behind a Gherkin file: all I would care is if the feature
described in the file accurately matches with what I need the software to
do. As a PO I've probably done that for years using Use Case Scenarios and
MS Word, but I would probably accept a different format if it can provide
the same or a better result​.
My opinion is Gherkin + Cucumber represent a decent bridge between these
two worlds, but it does provide the most of its value only if you walk this
bridge in one direction: from the specification to the tests.
What I am trying to say is that if your focus is on specifications and
requirements, than Gherkin can help you a lot in defining those in a manner
you can then decide what needs to be automatically tested, resolving the
need for validating the acceptance tests before the software gets into the
hands of the PO, who can get really frustrated by a failing software.
But if you are focused on testing than why use a language/framework which
doesn't even have an assertion structure? I mean, Cucumber by itself
doesn't even allow you to check if two strings are equal each other... And
I believe there is a good reason for the lack of those tools.
If my focus is on testing I would pick a testing framework and use it,
like JUnit, TestNG, etc... Something that helps me execute the checks I
need to perform to verify my assertions.
I perfectly understand the reasoning of Dan in his article and I've
personally partially experienced his very same frustrations during my
professional life, but I don't agree with you in summarizing it in
"Gherking (or JBehave, it doesn't really matter) was an alternative to
JUnit". My take from that article is the tool was intended to help you move
from TDD to BDD or, in other words, move from testing for the purpose of
verifying the code to checking the behaviour correctness.
It's a not a slight difference, but rather a huge leap: when we switch the
point of view, we also need to switch the language, stepping away from
computer programming and get our feet in the business language, the
language spoken by those who don't develop software.
Hence the natural language approach, hence the localization support and
the file format, hence the HTML reports: it must be readable and accessible
to people who don't have much of computer science in their DNA.
When we introduce pre-processor macros (#define and #include) we are
bringing this back into our programmer's lingo: sure, we can teach to our
business partners and product owners what #define and #include are and they
surely already understand tables, but is this what we should be doing?
Teaching them our geeky vocabulary?
I believe Gherkin and Cucumber aim at inverting this approach, letting the
business express their intentions using their own vocabulary, a vocabulary
that is finally shared between the parties.
Given I've signed up
I can log in
But only after I've confirmed my email address
Rather than
assertNotNull(username)
assertNotNull(password)
assertTrue(emailConfirmed)
assertEquals(username, storedUsername)
assertEquals(hash(password), storedPassword)
True, the above example is comparing potatoes and apples, I'm only trying
to express how distinct I see the world of testing from the world of
requirement specifications.

Post by k***@gmail.com
Take a look at my Deliver Agile Session (you need to login as an agile
alliance member) https://lnkd.in/enCkUVf

​Sorry, I'm not a member of such alliance, can't access it, but this
article on my blog
<https://rlogiacco.wordpress.com/2016/01/18/cucumber-is-not-a-testing-framework/>
is freely accessible.
​

Post by k***@gmail.com
There are two advantages:of using Gherkin
1.) The test is independent of the implementation. It specifies the
behavior of a unit.
2.) The test is readable by all members of the triad (customer,
developer, tester).

1) the triad shares the same ubiquitous language
2) the specification is described in terms of what is needed, not on how
it has to be implemented (this is a very good match with Agile practices,
where you don't think on how things are going to be implemented beforehand,
but rather decide it when you start implementing)
3) The requirements are live and maintainable by all members of the triad
As I'm a plain user of Cucumber and not an agile guru or something, I
to me, tests are far away from being the driver for Cucumber adoption.
Apologies for the length of my reply, I didn't realize it was so long
winded until I re-read it.
Thanks for the time,
Roberto

Post by k***@gmail.com
Ken

Post by Roberto Lo Giacco

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not contain
any data, then there is no need for this preprocessor, as you illustrated.
The more data one places in a feature file, then the possibility of values
that represent one domain term can be duplicated. Having #defines for
those terms can make for easier maintenance. In addition, giving names
to values helps create ubiquitous terms for understanding for the entire
team (e.g. MAXIMUM_VALUE).
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to contain
these values reduces the number of step definitions that need to be
created.

Background
Given the system is set up for with
| param | value |
| maximum | 200 |
| minimum | 50 |
| min length | 6 |
When the user inputs a value above the maximum allowed value
Then an error is shown
You should now question yourself: is what is written above a functional
requirement or a test? If your answer is the former within your context,
than you are ok. If it's the latter than why bother use Gherkin?

Post by k***@gmail.com
As far as CSV files, see my response to Halfordian Golfer.

My take on that is if I need a CSV to describe a business rule then that
business rule doesn't require Gherkin. I would also question myself why I
call "business rule" a CSV file and if I'm misinterpreting the concept of
business rule if I am thinking as a developer, trying to squeeze business
rules in a tabular format rather than trying to describe the business rule
for what it is... Does a table communicate better than natural language?
We, as software developers, are used to communicating in ways our business
partners do not understand, but if we don't treat Gherkin as a tool for
bridging communication between those two parties, why should we bother?
Regards,
Roberto

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[k***@gmail.com]

Here's a link to the PDF of the presentation: :

https://drive.google.com/open?id=1WpumtdiG8ZlB6ER4Ihi4OiyLLZMTD9LY

Ken

Post by Roberto Lo Giacco

Post by k***@gmail.com
Roberto,
I think I see where a misunderstanding lies.
I am experimenting with Gherkin to become a more useful tool for testing
as well as communication. One of the original purposes of Gherkin was
as an alternative to JUnit.
See https://dannorth.net/introducing-bdd/

​Ken, did you notice the whole article written by Dan doesn't mention
Gherkin at all? Actually Gherkin was an addition to JBehave, it didn't
support Gherkin at the beginning... Nonetheless, if you look at JBehave
syntax, you'll find very quickly it does in fact have some common grounds
with JUnit (one above all, the After element), which is the main reason why
I'm not a fan of JBehave Story syntax... but that's more a personal taste
than anything.
Back on track, sorry for the diversion., I'll try to put two different
hats on my little head, just to word what I think are the two perspectives
here.
As an experienced developer ​I wouldn't pick Gherkin (or Cucumber) over
Gherkin is not a testing framework, nor is Cucumber, and if they were, they
would have been a very very poor one.​
​As a business representative/product owner I couldn't care less if you
have tests behind a Gherkin file: all I would care is if the feature
described in the file accurately matches with what I need the software to
do. As a PO I've probably done that for years using Use Case Scenarios and
MS Word, but I would probably accept a different format if it can provide
the same or a better result​.
My opinion is Gherkin + Cucumber represent a decent bridge between these
two worlds, but it does provide the most of its value only if you walk this
bridge in one direction: from the specification to the tests.
What I am trying to say is that if your focus is on specifications and
requirements, than Gherkin can help you a lot in defining those in a manner
you can then decide what needs to be automatically tested, resolving the
need for validating the acceptance tests before the software gets into the
hands of the PO, who can get really frustrated by a failing software.
But if you are focused on testing than why use a language/framework which
doesn't even have an assertion structure? I mean, Cucumber by itself
doesn't even allow you to check if two strings are equal each other... And
I believe there is a good reason for the lack of those tools.
If my focus is on testing I would pick a testing framework and use it,
like JUnit, TestNG, etc... Something that helps me execute the checks I
need to perform to verify my assertions.
I perfectly understand the reasoning of Dan in his article and I've
personally partially experienced his very same frustrations during my
professional life, but I don't agree with you in summarizing it in
"Gherking (or JBehave, it doesn't really matter) was an alternative to
JUnit". My take from that article is the tool was intended to help you move
from TDD to BDD or, in other words, move from testing for the purpose of
verifying the code to checking the behaviour correctness.
It's a not a slight difference, but rather a huge leap: when we switch the
point of view, we also need to switch the language, stepping away from
computer programming and get our feet in the business language, the
language spoken by those who don't develop software.
Hence the natural language approach, hence the localization support and
the file format, hence the HTML reports: it must be readable and accessible
to people who don't have much of computer science in their DNA.
When we introduce pre-processor macros (#define and #include) we are
bringing this back into our programmer's lingo: sure, we can teach to our
business partners and product owners what #define and #include are and they
surely already understand tables, but is this what we should be doing?
Teaching them our geeky vocabulary?
I believe Gherkin and Cucumber aim at inverting this approach, letting the
business express their intentions using their own vocabulary, a vocabulary
that is finally shared between the parties.
Given I've signed up
I can log in
But only after I've confirmed my email address
Rather than
assertNotNull(username)
assertNotNull(password)
assertTrue(emailConfirmed)
assertEquals(username, storedUsername)
assertEquals(hash(password), storedPassword)
True, the above example is comparing potatoes and apples, I'm only trying
to express how distinct I see the world of testing from the world of
requirement specifications.

Post by k***@gmail.com
Take a look at my Deliver Agile Session (you need to login as an agile
alliance member) https://lnkd.in/enCkUVf

​Sorry, I'm not a member of such alliance, can't access it, but this
article on my blog
<https://rlogiacco.wordpress.com/2016/01/18/cucumber-is-not-a-testing-framework/>
is freely accessible.
​

Post by k***@gmail.com
There are two advantages:of using Gherkin
1.) The test is independent of the implementation. It specifies the
behavior of a unit.
2.) The test is readable by all members of the triad (customer,
developer, tester).

1) the triad shares the same ubiquitous language
2) the specification is described in terms of what is needed, not on how
it has to be implemented (this is a very good match with Agile practices,
where you don't think on how things are going to be implemented beforehand,
but rather decide it when you start implementing)
3) The requirements are live and maintainable by all members of the triad
As I'm a plain user of Cucumber and not an agile guru or something, I
to me, tests are far away from being the driver for Cucumber adoption.
Apologies for the length of my reply, I didn't realize it was so long
winded until I re-read it.
Thanks for the time,
Roberto

Post by k***@gmail.com
Ken

Post by Roberto Lo Giacco

Post by k***@gmail.com
Roberto,
Thanks for your reply. We have different approaches to what a feature
file represents and how it is used. If a feature file does not contain
any data, then there is no need for this preprocessor, as you illustrated.
The more data one places in a feature file, then the possibility of values
that represent one domain term can be duplicated. Having #defines for
those terms can make for easier maintenance. In addition, giving names
to values helps create ubiquitous terms for understanding for the entire
team (e.g. MAXIMUM_VALUE).
I've found that having specific values in a scenario really helps in
discussion between the business and development. Using tables to contain
these values reduces the number of step definitions that need to be
created.

Background
Given the system is set up for with
| param | value |
| maximum | 200 |
| minimum | 50 |
| min length | 6 |
When the user inputs a value above the maximum allowed value
Then an error is shown
You should now question yourself: is what is written above a functional
requirement or a test? If your answer is the former within your context,
than you are ok. If it's the latter than why bother use Gherkin?

Post by k***@gmail.com
As far as CSV files, see my response to Halfordian Golfer.

My take on that is if I need a CSV to describe a business rule then that
business rule doesn't require Gherkin. I would also question myself why I
call "business rule" a CSV file and if I'm misinterpreting the concept of
business rule if I am thinking as a developer, trying to squeeze business
rules in a tabular format rather than trying to describe the business rule
for what it is... Does a table communicate better than natural language?
We, as software developers, are used to communicating in ways our business
partners do not understand, but if we don't treat Gherkin as a tool for
bridging communication between those two parties, why should we bother?
Regards,
Roberto

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[Roberto Lo Giacco]

Post by k***@gmail.com
https://drive.google.com/open?id=1WpumtdiG8ZlB6ER4Ihi4OiyLLZMTD9LY

​Thanks a million for sharing Ken.
Sorry, but I once again have to disagree: using Cucumber for unit testing
is a certain path toward failure... I say that for personal experience.

The developers will hate you because ​you are forcing them to write and
maintain doubled files (one for the feature, one for the stepdef)
The QAs will hate you because they will have to maintain a lot of files
(that explains your #include and #define to me now)
The Project Manager will hate you because you are spending a lot more
effort in testing
The Product Owner will hate you because you will be forcing him to read and
validate tons of files he doesn't really care of (or he will just nod at
you while you go through all of them)

Did you really manage to have "los tres amigos" work on those together?
Sorry buddy, I can't believe that...
Trust me, you'll do yourself a favour if you don't use Cucumber for unit
testing: it is truly not meant for that.

Another certain path toward failure is trying to generalize stepdefs:
that's another error I've made and paid on my own skin.... Don't try to
reduce the number of stepdefs so to have "only one stepdef to click a
button": you'll end up having very complex and costly to maintain stepdefs.
But that's another story, may be worth another blog post
<https://rlogiacco.wordpress.com/2014/01/08/generalization-pitfalls/> :-D
Please note that post has been there since January 2014...

Roberto

Post by k***@gmail.com
Ken

[k***@gmail.com]

Roberto,

As I mentioned, we differ on perspectives.

Here are an article on writing tests for business rules using an ATDD/BDD
framework:

http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf

Here's another article:

https://www.agilealliance.org/glossary/acceptance

My approach is that if business rules are important, then having business
readable tests for those rules is also important. Using
developer-centric tools like JUnit does not make those tests business
readable.

Now our views are shaped by our context and experience. We have different
contexts and experiences. So it's no surprise we have different views
that are equally valid.

Ken

Post by Roberto Lo Giacco

Post by k***@gmail.com
https://drive.google.com/open?id=1WpumtdiG8ZlB6ER4Ihi4OiyLLZMTD9LY

​Thanks a million for sharing Ken.
Sorry, but I once again have to disagree: using Cucumber for unit testing
is a certain path toward failure... I say that for personal experience.
The developers will hate you because ​you are forcing them to write and
maintain doubled files (one for the feature, one for the stepdef)
The QAs will hate you because they will have to maintain a lot of files
(that explains your #include and #define to me now)
The Project Manager will hate you because you are spending a lot more
effort in testing
The Product Owner will hate you because you will be forcing him to read
and validate tons of files he doesn't really care of (or he will just nod
at you while you go through all of them)
Did you really manage to have "los tres amigos" work on those together?
Sorry buddy, I can't believe that...
Trust me, you'll do yourself a favour if you don't use Cucumber for unit
testing: it is truly not meant for that.
that's another error I've made and paid on my own skin.... Don't try to
reduce the number of stepdefs so to have "only one stepdef to click a
button": you'll end up having very complex and costly to maintain stepdefs.
But that's another story, may be worth another blog post
<https://rlogiacco.wordpress.com/2014/01/08/generalization-pitfalls/> :-D
Please note that post has been there since January 2014...
Roberto

Post by k***@gmail.com
Ken

[Roberto Lo Giacco]

Post by k***@gmail.com
Roberto,
As I mentioned, we differ on perspectives.

Yup, and allow me to stress I'm not saying mine is more correct than yours:
I'm debating with you with the purpose of clarity and communication, not
trying to force you abandon Cucumber ;)

Post by k***@gmail.com
Here are an article on writing tests for business rules using an ATDD/BDD
http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf

Do we at least agree there are huge differences between TDD, ATDD and BDD?
I mean, do we agree they are very different approaches? Because I'm
starting to have the impression you consider all tests as acceptance
tests...

Post by k***@gmail.com
https://www.agilealliance.org/glossary/acceptance

Well, I believe I had already a decent understanding of an acceptance test:
why did you feel I needed that link?

Post by k***@gmail.com
My approach is that if business rules are important, then having business
readable tests for those rules is also important. Using
developer-centric tools like JUnit does not make those tests business
readable.

I agree 100% with the above statement, but I perceive those #define and
#include as bringing "developer-centric tools" inside what is meant not to
be developer centric, so making the feature file less "business readable".

Post by k***@gmail.com
Now our views are shaped by our context and experience. We have
different contexts and experiences. So it's no surprise we have
different views that are equally valid.

Sure, I hope the opposite has never come across.

Please Ken, have a read at https://cucumber.io/posting-rules, in particular
to the item number 3

[Eric Kessler]

Post by Roberto Lo Giacco

Post by k***@gmail.com
https://drive.google.com/open?id=1WpumtdiG8ZlB6ER4Ihi4OiyLLZMTD9LY

​Thanks a million for sharing Ken.
Sorry, but I once again have to disagree: using Cucumber for unit testing
is a certain path toward failure... I say that for personal experience.

And from personal experience as well, I'm going to have to disagree with
you on that, Roberto. There are times when writing unit tests in a business
readable format (e.g. Gherkin) is totally appropriate. They aren't as
common as non-unit business readable test but, none the less, they exist.
It turned out quite well.

On a related note: http://claysnow.co.uk/the-testing-iceberg/


Enjoy,
Eric

Post by Roberto Lo Giacco
The developers will hate you because ​you are forcing them to write and
maintain doubled files (one for the feature, one for the stepdef)
The QAs will hate you because they will have to maintain a lot of files
(that explains your #include and #define to me now)
The Project Manager will hate you because you are spending a lot more
effort in testing
The Product Owner will hate you because you will be forcing him to read
and validate tons of files he doesn't really care of (or he will just nod
at you while you go through all of them)
Did you really manage to have "los tres amigos" work on those together?
Sorry buddy, I can't believe that...
Trust me, you'll do yourself a favour if you don't use Cucumber for unit
testing: it is truly not meant for that.
that's another error I've made and paid on my own skin.... Don't try to
reduce the number of stepdefs so to have "only one stepdef to click a
button": you'll end up having very complex and costly to maintain stepdefs.
But that's another story, may be worth another blog post
<https://rlogiacco.wordpress.com/2014/01/08/generalization-pitfalls/> :-D
Please note that post has been there since January 2014...
Roberto

Post by k***@gmail.com
Ken

[Massimo Manca]

My 5 cents: unit tests are not in the business/customer domain but in the
developer domain so there is no good reason to describe them using Gherkin
that is on the business/customer domain. The natural use of Gherkin should
be facilitate the process from eliciting requirements to executable
requirements so from requirements to acceptance tests that are on the
business/customer domain.

Post by Eric Kessler

Post by Roberto Lo Giacco

Post by k***@gmail.com
https://drive.google.com/open?id=1WpumtdiG8ZlB6ER4Ihi4OiyLLZMTD9LY

​Thanks a million for sharing Ken.
Sorry, but I once again have to disagree: using Cucumber for unit testing
is a certain path toward failure... I say that for personal experience.

And from personal experience as well, I'm going to have to disagree with
you on that, Roberto. There are times when writing unit tests in a business
readable format (e.g. Gherkin) is totally appropriate. They aren't as
common as non-unit business readable test but, none the less, they exist.
It turned out quite well.
On a related note: http://claysnow.co.uk/the-testing-iceberg/
Enjoy,
Eric

Post by Roberto Lo Giacco
The developers will hate you because ​you are forcing them to write and
maintain doubled files (one for the feature, one for the stepdef)
The QAs will hate you because they will have to maintain a lot of files
(that explains your #include and #define to me now)
The Project Manager will hate you because you are spending a lot more
effort in testing
The Product Owner will hate you because you will be forcing him to read
and validate tons of files he doesn't really care of (or he will just nod
at you while you go through all of them)
Did you really manage to have "los tres amigos" work on those together?
Sorry buddy, I can't believe that...
Trust me, you'll do yourself a favour if you don't use Cucumber for unit
testing: it is truly not meant for that.
that's another error I've made and paid on my own skin.... Don't try to
reduce the number of stepdefs so to have "only one stepdef to click a
button": you'll end up having very complex and costly to maintain stepdefs.
But that's another story, may be worth another blog post
<https://rlogiacco.wordpress.com/2014/01/08/generalization-pitfalls/>
:-D Please note that post has been there since January 2014...
Roberto

Post by k***@gmail.com
Ken
--

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.

[Roberto Lo Giacco]

This post might be inappropriate. Click to display it.

[Tim Walker]

Quick question while I am thinking on this.

Is there anything besides data in rows and columns in those csv files? That
is, anything "spreadsheety" (functions, charts, etc)? Or is this so POs can
edit that data more easily? Would an IDE that had better table support
solve your problem too?

Thanks,

Tim

Post by k***@gmail.com
Here's a pre-processor for Cucumber An explanation of its purpose is
https://github.com/atdd-bdd/preprocessor/blob/master/Cucumber%20Preprocessor%20Introduction.pdf
It uses #define and #include directives to transform feature files in one
directory into processed files in another directory. It stands separate
from Cucumber and is executed prior in the build to running cucumber.
I'm trying it out as an experiment. One feature is the ability to
include csv files as tables. Someone had mentioned that a few years ago
in a separate thread.
https://github.com/atdd-bdd/preprocessor/
https://github.com/atdd-bdd/preprocessor/blob/master/CucumberPreprocessorExplanation.pdf
Ken
--
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.

[k***@gmail.com]

Tim,

My thought behind the CSV files is that anyone can manipulate a spreadsheet
to create variations of a business rule or data and then save it as a CSV
file. If there were an IDE that supported tables and some Excel
functions, that be basically have the same effect. If it not, then there
probably be a separate cut-and-paste operation from Excel to the IDE.

Ken

Post by Tim Walker
Quick question while I am thinking on this.
Is there anything besides data in rows and columns in those csv files?
That is, anything "spreadsheety" (functions, charts, etc)? Or is this so
POs can edit that data more easily? Would an IDE that had better table
support solve your problem too?
Thanks,
Tim

Post by k***@gmail.com
Here's a pre-processor for Cucumber An explanation of its purpose is
https://github.com/atdd-bdd/preprocessor/blob/master/Cucumber%20Preprocessor%20Introduction.pdf
It uses #define and #include directives to transform feature files in one
directory into processed files in another directory. It stands separate
from Cucumber and is executed prior in the build to running cucumber.
I'm trying it out as an experiment. One feature is the ability to
include csv files as tables. Someone had mentioned that a few years ago
in a separate thread.
https://github.com/atdd-bdd/preprocessor/
https://github.com/atdd-bdd/preprocessor/blob/master/CucumberPreprocessorExplanation.pdf
Ken
--
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.

[k***@gmail.com]

Let me re-focus this discussion around the pre-processor, not about other
issues.

I thank you for your suggestions:

1.) Different syntax for include files

e.g. <filetoinclude.csv> or something similar

instead of

#include filetoinclude.csv

2.) Different style for #defines,
e.g. MaximumAllowedValue

instead of

MAXIMUM_ALLOWED_VALUE

3.) Different format for #defines.

e.g.
#definevalues (or something similar)
| MaximumAllowedValue | 200 |
| MinimumAllowedValue | 100 |

instead of

#define MaximumAllowedValue 200
#define MinimumAllowedValue 100

Have I captured the suggestions correctly or have I missed something?

Thanks.

Ken

Post by k***@gmail.com
Here's a pre-processor for Cucumber An explanation of its purpose is
https://github.com/atdd-bdd/preprocessor/blob/master/Cucumber%20Preprocessor%20Introduction.pdf
It uses #define and #include directives to transform feature files in one
directory into processed files in another directory. It stands separate
from Cucumber and is executed prior in the build to running cucumber.
I'm trying it out as an experiment. One feature is the ability to
include csv files as tables. Someone had mentioned that a few years ago
in a separate thread.
https://github.com/atdd-bdd/preprocessor/
https://github.com/atdd-bdd/preprocessor/blob/master/CucumberPreprocessorExplanation.pdf
Ken

[Massimo Manca]

Mmmmm.... you can refocus to the preprocessor and use it as you want but
seems to me and others that is not in the spirit of Cucumber. I know that
the syntax of Gherkin may be nice also to describe tests and unit tests
but... I am quite surprise if you need Gherkin to describe/implement unit
tests, in this case there is something to improve in your development
process. On the other side using Gherkin to describe acceptance tests you
should be able to realize what you want using Cucumber as is eventually
extending it using the wire protocol. I really do not see any help coming
from a preprocessor.

Post by k***@gmail.com
Let me re-focus this discussion around the pre-processor, not about other
issues.
1.) Different syntax for include files
e.g. <filetoinclude.csv> or something similar
instead of
#include filetoinclude.csv
2.) Different style for #defines,
e.g. MaximumAllowedValue
instead of
MAXIMUM_ALLOWED_VALUE
3.) Different format for #defines.
e.g.
#definevalues (or something similar)
| MaximumAllowedValue | 200 |
| MinimumAllowedValue | 100 |
instead of
#define MaximumAllowedValue 200
#define MinimumAllowedValue 100
Have I captured the suggestions correctly or have I missed something?
Thanks.
Ken

Post by k***@gmail.com
Here's a pre-processor for Cucumber An explanation of its purpose is
https://github.com/atdd-bdd/preprocessor/blob/master/Cucumber%20Preprocessor%20Introduction.pdf
It uses #define and #include directives to transform feature files in one
directory into processed files in another directory. It stands separate
from Cucumber and is executed prior in the build to running cucumber.
I'm trying it out as an experiment. One feature is the ability to
include csv files as tables. Someone had mentioned that a few years ago
in a separate thread.
https://github.com/atdd-bdd/preprocessor/
https://github.com/atdd-bdd/preprocessor/blob/master/CucumberPreprocessorExplanation.pdf
Ken

--
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.

[Justin]

On Jun 20, 2018 8:57 PM, "Massimo Manca" <***@gmail.com> wrote:

Mmmmm.... you can refocus to the preprocessor and use it as you want but
seems to me and others that is not in the spirit of Cucumber. I know that
the syntax of Gherkin may be nice also to describe tests and unit tests
but... I am quite surprise if you need Gherkin to describe/implement unit
tests, in this case there is something to improve in your development
process. On the other side using Gherkin to describe acceptance tests you
should be able to realize what you want using Cucumber as is eventually
extending it using the wire protocol. I really do not see any help coming
from a preprocessor.

Post by k***@gmail.com
Let me re-focus this discussion around the pre-processor, not about other
issues.
1.) Different syntax for include files
e.g. <filetoinclude.csv> or something similar
instead of
#include filetoinclude.csv
2.) Different style for #defines,
e.g. MaximumAllowedValue
instead of
MAXIMUM_ALLOWED_VALUE
3.) Different format for #defines.
e.g.
#definevalues (or something similar)
| MaximumAllowedValue | 200 |
| MinimumAllowedValue | 100 |
instead of
#define MaximumAllowedValue 200
#define MinimumAllowedValue 100
Have I captured the suggestions correctly or have I missed something?
Thanks.
Ken

Post by k***@gmail.com
Here's a pre-processor for Cucumber An explanation of its purpose is
https://github.com/atdd-bdd/preprocessor/blob/master/Cucumber%20Preprocessor%20Introduction.pdf
It uses #define and #include directives to transform feature files in one
directory into processed files in another directory. It stands separate
from Cucumber and is executed prior in the build to running cucumber.
I'm trying it out as an experiment. One feature is the ability to
include csv files as tables. Someone had mentioned that a few years ago
in a separate thread.
https://github.com/atdd-bdd/preprocessor/
https://github.com/atdd-bdd/preprocessor/blob/master/CucumberPreprocessorExplanation.pdf
Ken

--
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.

[k***@gmail.com]

I'm not sure how the wire protocol would match the preprocessor
constructs. Could you give me an example of using the wire protocol that
matches the example:

#defines (or Define if a Gherkin keyword)
| SomeOne| "Bill" |
| SomeOneElse | "Jane" |
| ValidMessage | "Hi" |
| DistanceInRange | 100 |
| MaximumDelay | 2 |

Scenario: Shout Out
Given that SomeOne and SomeOneElse are in DistanceInRange
When SomeOne shouts a ValidMessage
Then SomeOneElse sees ValidMessage before MaximumDelay

Post by Massimo Manca
Mmmmm.... you can refocus to the preprocessor and use it as you want but
seems to me and others that is not in the spirit of Cucumber. I know that
the syntax of Gherkin may be nice also to describe tests and unit tests
but... I am quite surprise if you need Gherkin to describe/implement unit
tests, in this case there is something to improve in your development
process. On the other side using Gherkin to describe acceptance tests you
should be able to realize what you want using Cucumber as is eventually
extending it using the wire protocol. I really do not see any help coming
from a preprocessor.

Post by k***@gmail.com
Let me re-focus this discussion around the pre-processor, not about other
issues.
1.) Different syntax for include files
e.g. <filetoinclude.csv> or something similar
instead of
#include filetoinclude.csv
2.) Different style for #defines,
e.g. MaximumAllowedValue
instead of
MAXIMUM_ALLOWED_VALUE
3.) Different format for #defines.
e.g.
#definevalues (or something similar)
| MaximumAllowedValue | 200 |
| MinimumAllowedValue | 100 |
instead of
#define MaximumAllowedValue 200
#define MinimumAllowedValue 100
Have I captured the suggestions correctly or have I missed something?
Thanks.
Ken

Post by k***@gmail.com
Here's a pre-processor for Cucumber An explanation of its purpose is
https://github.com/atdd-bdd/preprocessor/blob/master/Cucumber%20Preprocessor%20Introduction.pdf
It uses #define and #include directives to transform feature files in
one directory into processed files in another directory. It stands
separate from Cucumber and is executed prior in the build to running
cucumber. I'm trying it out as an experiment. One feature is the
ability to include csv files as tables. Someone had mentioned that a few
years ago in a separate thread.
https://github.com/atdd-bdd/preprocessor/
https://github.com/atdd-bdd/preprocessor/blob/master/CucumberPreprocessorExplanation.pdf
Ken

--
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
For more options, visit https://groups.google.com/d/optout.

[Matt Wynne]

Post by k***@gmail.com
I'm not sure how the wire protocol would match the preprocessor
constructs. Could you give me an example of using the wire protocol that
#defines (or Define if a Gherkin keyword)
| SomeOne| "Bill" |
| SomeOneElse | "Jane" |
| ValidMessage | "Hi" |
| DistanceInRange | 100 |
| MaximumDelay | 2 |
Scenario: Shout Out
Given that SomeOne and SomeOneElse are in DistanceInRange
When SomeOne shouts a ValidMessage
Then SomeOneElse sees ValidMessage before MaximumDelay

The wire protocol looks for steps with a given text and asks the thing at
the other end whether they can match them.

So if the new Define keyword was a global background, each scenario would
effectively be prefixed with a step like:

Given these domain terms:
| SomeOne | "Bill" |
| SomeOneElse | "Jane" |
| ValidMessage | "Hi" |
| DistanceInRange | 100 |
| MaximumDelay | 2 |

It would then be up to the user to implement the glue code on the end of
the wire to set these values somewhere, and use them in the other steps.

I don't *think* parameter types (as discussed in the other thread) work
over the wire protocol, but I might be wrong.

Can you get a bit more concrete and explain what you want to do using the
wire protocol?

Post by k***@gmail.com
Mmmmm.... you can refocus to the preprocessor and use it as you want but

Post by Massimo Manca
seems to me and others that is not in the spirit of Cucumber. I know that
the syntax of Gherkin may be nice also to describe tests and unit tests
but... I am quite surprise if you need Gherkin to describe/implement unit
tests, in this case there is something to improve in your development
process. On the other side using Gherkin to describe acceptance tests you
should be able to realize what you want using Cucumber as is eventually
extending it using the wire protocol. I really do not see any help coming
from a preprocessor.
Let me re-focus this discussion around the pre-processor, not about other

Post by k***@gmail.com
issues.
1.) Different syntax for include files
e.g. <filetoinclude.csv> or something similar
instead of
#include filetoinclude.csv
2.) Different style for #defines,
e.g. MaximumAllowedValue
instead of
MAXIMUM_ALLOWED_VALUE
3.) Different format for #defines.
e.g.
#definevalues (or something similar)
| MaximumAllowedValue | 200 |
| MinimumAllowedValue | 100 |
instead of
#define MaximumAllowedValue 200
#define MinimumAllowedValue 100
Have I captured the suggestions correctly or have I missed something?
Thanks.
Ken

Post by k***@gmail.com
Here's a pre-processor for Cucumber An explanation of its purpose is
https://github.com/atdd-bdd/preprocessor/blob/master/Cucumber%20Preprocessor%20Introduction.pdf
It uses #define and #include directives to transform feature files in
one directory into processed files in another directory. It stands
separate from Cucumber and is executed prior in the build to running
cucumber. I'm trying it out as an experiment. One feature is the
ability to include csv files as tables. Someone had mentioned that a few
years ago in a separate thread.
https://github.com/atdd-bdd/preprocessor/
https://github.com/atdd-bdd/preprocessor/blob/master/CucumberPreprocessorExplanation.pdf
Ken

--
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

Post by k***@gmail.com
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
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 a topic in the
Google Groups "Cukes" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/cukes/F0AQ0DpVoZU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

--
Inspiring meaningful, effective collaboration in every software delivery
organisation.





The Cucumber logo is the intellectual property of
Cucumber Ltd, a limited company registered in Scotland, number 456793.



Registered address: Cucumber Ltd, The Melting Pot, 5 Rose Street, Edinburgh
EH2 2PR, Scotland, United Kingdom.
CONFIDENTIALITY NOTICE: The information
in this e-mail is confidential and privileged; it is intended for use
solely by the individual or entity named as the recipient hereof.
Disclosure, copying, distribution, or use of the contents of this e-mail by
persons other than the intended recipient is strictly prohibited and may
violate applicable laws. If you have received this e-mail in error, please
delete the original message and notify us by email immediately. Thank you.
Cucumber Ltd.

[Roberto Lo Giacco]

Post by k***@gmail.com
Let me re-focus this discussion around the pre-processor, not about other
issues.

​Apologies if I was the cause of such diversion​

Post by k***@gmail.com
3.) Different format for #defines.
e.g.
#definevalues (or something similar)
| MaximumAllowedValue | 200 |
| MinimumAllowedValue | 100 |

​That is NOT what I was suggesting​