[Cucumber] Dynamic glues

[bsz0206]

Hi,

Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"

When I am testing site A
And I log in as user "a", "b"

When I am testing site B
And I log in as user "a", "b"

So there are two similar step definitions and glue should change as per the
previous step.

Is there any way this can be done?

[aslak hellesoy]

Post by bsz0206
Hi,
Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"
When I am testing site A
And I log in as user "a", "b"
When I am testing site B
And I log in as user "a", "b"
So there are two similar step definitions and glue should change as per
the previous step.
Is there any way this can be done?

Sure:

@When("I log in as user \"(.*)\", \"(.*)\"")
public void login(String user, String pass) {
authenticator.login(user, pass); // authenticator is declared as
Authenticator - an interface
}

In your first step you'll assign the authenticator field with
AuthenticatorA or AuthenticatorB - both are classes that implement your
Authenticator interface.

Aslak

Post by bsz0206
--
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.

[bsz0206]

That works but this will force the developer to fork all step definitions
for different scenarios. Assume they are different developers writing step
providers for each platform. Then if the person who integrates the work
could add one step for setting up the environment "When I am testing site
A", then he could load the appropriate glues based on the first step.

Post by aslak hellesoy

Post by bsz0206
Hi,
Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"
When I am testing site A
And I log in as user "a", "b"
When I am testing site B
And I log in as user "a", "b"
So there are two similar step definitions and glue should change as per
the previous step.
Is there any way this can be done?

@When("I log in as user \"(.*)\", \"(.*)\"")
public void login(String user, String pass) {
authenticator.login(user, pass); // authenticator is declared as
Authenticator - an interface
}
In your first step you'll assign the authenticator field with
AuthenticatorA or AuthenticatorB - both are classes that implement your
Authenticator interface.
Aslak

Post by bsz0206
--
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.

[aslak hellesoy]

Post by bsz0206
That works but this will force the developer to fork all step definitions
for different scenarios. Assume they are different developers writing step
providers for each platform. Then if the person who integrates the work
could add one step for setting up the environment "When I am testing site
A", then he could load the appropriate glues based on the first step.

In Cucumber, all step definitions are global. There is no built-in way to
provide different implementations for the same sentence. This is a very
conscious design decision.

The concept of "Ubiquitous Language" from DDD is also a very central
concept in BDD. We encourage the same words/terms to be used in both domain
language (what the business stakeholders speak) and in the code. We eschew
ambiguity and overloading a term with several meanings because this leads
to misunderstandings and bugs.

By making the step definitions global we prevent overloading the meaning of
sentences. It forces you to come up with a ubiquitous language.

Cucumber is a tool to support BDD. From what I can tell you and your team
is not doing BDD. When you use a tool for something else than what it was
intended for you'll run into the sort of problems you're describing here.

So what's BDD? It's stakeholders, developers and testers having
conversations about examples, then developers using those examples to do
TDD. Here are some links to get you started:

http://dannorth.net/introducing-bdd/
https://cukes.info/blog/2015/03/27/aslaks-view-of-bdd
https://cukes.info/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool

Aslak

Post by bsz0206

Post by aslak hellesoy

Post by bsz0206
Hi,
Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"
When I am testing site A
And I log in as user "a", "b"
When I am testing site B
And I log in as user "a", "b"
So there are two similar step definitions and glue should change as per
the previous step.
Is there any way this can be done?

@When("I log in as user \"(.*)\", \"(.*)\"")
public void login(String user, String pass) {
authenticator.login(user, pass); // authenticator is declared as
Authenticator - an interface
}
In your first step you'll assign the authenticator field with
AuthenticatorA or AuthenticatorB - both are classes that implement your
Authenticator interface.
Aslak

Post by bsz0206
--
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
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.

[bsz0206]

Great articles. Thanks for them. I almost agree on most points you made.

However this dynamic glue changing (or options in general) is still needed.
Currently the way cukes works is almost complete design time however
sometimes you need to be able to change based on the run time information.
For example,

- you may like to run more tests only if some tests passed or failed so you
need to change the feature files list

- Also for glues, in my case, I have different HW/SW platforms with same
business rules. So the steps are the same with conflicting names because
they do the same thing for iPad, Android or Windows. Our Gherkin writer
need to create scenarios with multiple applications being tested at the
same time. For example user 1 goes to the Windows application and opens a
record and at the same time another user goes to the iPad doing the same. I
need to have this feature, so that I can swap glues based on the user and
platform. Otherwise we need to prefix all step with the platform name. Iike
the gherkin be like this:

When "user1" is on "Windows"
and goes to to file, open and opens file "x"
and "user2" is on "iPad"
and goes to to file, open and opens file "x"

and many other examples.Currently I have two options:
- Prefix all steps with platform name:
- create another glue to wrap the other glues and do dependency injection.

Both of them are big hassles.

Post by bsz0206
Hi,
Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"
When I am testing site A
And I log in as user "a", "b"
When I am testing site B
And I log in as user "a", "b"
So there are two similar step definitions and glue should change as per
the previous step.
Is there any way this can be done?

[Andrew Premdas]

Post by bsz0206
Great articles. Thanks for them. I almost agree on most points you made.
However this dynamic glue changing (or options in general) is still
needed. Currently the way cukes works is almost complete design time
however sometimes you need to be able to change based on the run time
information. For example,
- you may like to run more tests only if some tests passed or failed so
you need to change the feature files list
- Also for glues, in my case, I have different HW/SW platforms with same
business rules. So the steps are the same with conflicting names because
they do the same thing for iPad, Android or Windows. Our Gherkin writer
need to create scenarios with multiple applications being tested at the
same time. For example user 1 goes to the Windows application and opens a
record and at the same time another user goes to the iPad doing the same. I
need to have this feature, so that I can swap glues based on the user and
platform. Otherwise we need to prefix all step with the platform name. Iike
When "user1" is on "Windows"
and goes to to file, open and opens file "x"
and "user2" is on "iPad"
and goes to to file, open and opens file "x"
- create another glue to wrap the other glues and do dependency injection.
Both of them are big hassles

You can use an environment variable to deal with that sort of problem.
However if you are writing scenarios where two different platforms are
being used at the same time, e.g. exploring the interaction between someone
using a tablet and a desktop application then you should put this in the
feature.

Given Fred is using his tablet
And Bill is using his desktop
When Fred gives Bill a foo
Then Bill should see the foo

Now you could run this with multiple combinations of tablet and desktop
using environment variables

e.g.

DESKTOP=WIndows TABLET=ipad cucumber ...
DESKTOP=osx TABLET=s4 cucumber ...

and write step definitions that use the environment variables to choose HOW
to do things

e.g.

Given 'Fred is using his tablet' do
use_tablet tablet: env.TABLET, user: Fred
end

module TabletUser
def use_tablet attrs
case attrs[:tablet]
when S4
use_s4
.....

end
end

You really do not need to do any programming in feature files. They are
best used for expressing WHAT is being done and WHY it has value, rather
than trying to document HOW things are done.

Post by bsz0206
Hi,
Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"
When I am testing site A
And I log in as user "a", "b"
When I am testing site B
And I log in as user "a", "b"
So there are two similar step definitions and glue should change as per
the previous step.
Is there any way this can be done?

--

Post by bsz0206
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.

--
------------------------
Andrew Premdas
blog.andrew.premdas.org

[Behrad Sadoughian]

My Gherkin is completely the way you have done it.

I am using Cucember-JVM. How can I set environment like that in Java?

Post by Andrew Premdas

Post by bsz0206
Great articles. Thanks for them. I almost agree on most points you made.
However this dynamic glue changing (or options in general) is still
needed. Currently the way cukes works is almost complete design time
however sometimes you need to be able to change based on the run time
information. For example,
- you may like to run more tests only if some tests passed or failed so
you need to change the feature files list
- Also for glues, in my case, I have different HW/SW platforms with same
business rules. So the steps are the same with conflicting names because
they do the same thing for iPad, Android or Windows. Our Gherkin writer
need to create scenarios with multiple applications being tested at the
same time. For example user 1 goes to the Windows application and opens a
record and at the same time another user goes to the iPad doing the same. I
need to have this feature, so that I can swap glues based on the user and
platform. Otherwise we need to prefix all step with the platform name. Iike
When "user1" is on "Windows"
and goes to to file, open and opens file "x"
and "user2" is on "iPad"
and goes to to file, open and opens file "x"
- create another glue to wrap the other glues and do dependency injection.
Both of them are big hassles

You can use an environment variable to deal with that sort of problem.
However if you are writing scenarios where two different platforms are
being used at the same time, e.g. exploring the interaction between someone
using a tablet and a desktop application then you should put this in the
feature.
Given Fred is using his tablet
And Bill is using his desktop
When Fred gives Bill a foo
Then Bill should see the foo
Now you could run this with multiple combinations of tablet and desktop
using environment variables
e.g.
DESKTOP=WIndows TABLET=ipad cucumber ...
DESKTOP=osx TABLET=s4 cucumber ...
and write step definitions that use the environment variables to choose
HOW to do things
e.g.
Given 'Fred is using his tablet' do
use_tablet tablet: env.TABLET, user: Fred
end
module TabletUser
def use_tablet attrs
case attrs[:tablet]
when S4
use_s4
.....
end
end
You really do not need to do any programming in feature files. They are
best used for expressing WHAT is being done and WHY it has value, rather
than trying to document HOW things are done.

Post by bsz0206
Hi,
Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"
When I am testing site A
And I log in as user "a", "b"
When I am testing site B
And I log in as user "a", "b"
So there are two similar step definitions and glue should change as per
the previous step.
Is there any way this can be done?

--

Post by bsz0206
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.

--
------------------------
Andrew Premdas
blog.andrew.premdas.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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[Andrew Premdas]

Post by Behrad Sadoughian
My Gherkin is completely the way you have done it.
I am using Cucember-JVM. How can I set environment like that in Java

Perhaps
https://docs.oracle.com/javase/tutorial/essential/environment/env.html will
help. I stopped using java many years ago, so am a bit out of touch :)

Post by Behrad Sadoughian

Post by Andrew Premdas

Post by bsz0206
Great articles. Thanks for them. I almost agree on most points you made.
However this dynamic glue changing (or options in general) is still
needed. Currently the way cukes works is almost complete design time
however sometimes you need to be able to change based on the run time
information. For example,
- you may like to run more tests only if some tests passed or failed so
you need to change the feature files list
- Also for glues, in my case, I have different HW/SW platforms with same
business rules. So the steps are the same with conflicting names because
they do the same thing for iPad, Android or Windows. Our Gherkin writer
need to create scenarios with multiple applications being tested at the
same time. For example user 1 goes to the Windows application and opens a
record and at the same time another user goes to the iPad doing the same. I
need to have this feature, so that I can swap glues based on the user and
platform. Otherwise we need to prefix all step with the platform name. Iike
When "user1" is on "Windows"
and goes to to file, open and opens file "x"
and "user2" is on "iPad"
and goes to to file, open and opens file "x"
- create another glue to wrap the other glues and do dependency injection.
Both of them are big hassles

You can use an environment variable to deal with that sort of problem.
However if you are writing scenarios where two different platforms are
being used at the same time, e.g. exploring the interaction between someone
using a tablet and a desktop application then you should put this in the
feature.
Given Fred is using his tablet
And Bill is using his desktop
When Fred gives Bill a foo
Then Bill should see the foo
Now you could run this with multiple combinations of tablet and desktop
using environment variables
e.g.
DESKTOP=WIndows TABLET=ipad cucumber ...
DESKTOP=osx TABLET=s4 cucumber ...
and write step definitions that use the environment variables to choose
HOW to do things
e.g.
Given 'Fred is using his tablet' do
use_tablet tablet: env.TABLET, user: Fred
end
module TabletUser
def use_tablet attrs
case attrs[:tablet]
when S4
use_s4
.....
end
end
You really do not need to do any programming in feature files. They are
best used for expressing WHAT is being done and WHY it has value, rather
than trying to document HOW things are done.

Post by bsz0206
Hi,
Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"
When I am testing site A
And I log in as user "a", "b"
When I am testing site B
And I log in as user "a", "b"
So there are two similar step definitions and glue should change as per
the previous step.
Is there any way this can be done?

--

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

--
------------------------
Andrew Premdas
blog.andrew.premdas.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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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.

--
------------------------
Andrew Premdas
blog.andrew.premdas.org

[Behrad Sadoughian]

This is just an environment variable. How can it select the right glue when
testing different application platforms?

Post by Andrew Premdas

Post by Behrad Sadoughian
My Gherkin is completely the way you have done it.
I am using Cucember-JVM. How can I set environment like that in Java

Perhaps
https://docs.oracle.com/javase/tutorial/essential/environment/env.html
will help. I stopped using java many years ago, so am a bit out of touch :)

Post by Behrad Sadoughian

Post by Andrew Premdas

Post by bsz0206
Great articles. Thanks for them. I almost agree on most points you made.
However this dynamic glue changing (or options in general) is still
needed. Currently the way cukes works is almost complete design time
however sometimes you need to be able to change based on the run time
information. For example,
- you may like to run more tests only if some tests passed or failed so
you need to change the feature files list
- Also for glues, in my case, I have different HW/SW platforms with
same business rules. So the steps are the same with conflicting names
because they do the same thing for iPad, Android or Windows. Our Gherkin
writer need to create scenarios with multiple applications being tested at
the same time. For example user 1 goes to the Windows application and opens
a record and at the same time another user goes to the iPad doing the same.
I need to have this feature, so that I can swap glues based on the user and
platform. Otherwise we need to prefix all step with the platform name. Iike
When "user1" is on "Windows"
and goes to to file, open and opens file "x"
and "user2" is on "iPad"
and goes to to file, open and opens file "x"
- create another glue to wrap the other glues and do dependency injection.
Both of them are big hassles

You can use an environment variable to deal with that sort of problem.
However if you are writing scenarios where two different platforms are
being used at the same time, e.g. exploring the interaction between someone
using a tablet and a desktop application then you should put this in the
feature.
Given Fred is using his tablet
And Bill is using his desktop
When Fred gives Bill a foo
Then Bill should see the foo
Now you could run this with multiple combinations of tablet and desktop
using environment variables
e.g.
DESKTOP=WIndows TABLET=ipad cucumber ...
DESKTOP=osx TABLET=s4 cucumber ...
and write step definitions that use the environment variables to choose
HOW to do things
e.g.
Given 'Fred is using his tablet' do
use_tablet tablet: env.TABLET, user: Fred
end
module TabletUser
def use_tablet attrs
case attrs[:tablet]
when S4
use_s4
.....
end
end
You really do not need to do any programming in feature files. They are
best used for expressing WHAT is being done and WHY it has value, rather
than trying to document HOW things are done.

Post by bsz0206
Hi,
Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"
When I am testing site A
And I log in as user "a", "b"
When I am testing site B
And I log in as user "a", "b"
So there are two similar step definitions and glue should change as per
the previous step.
Is there any way this can be done?

--

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

--
------------------------
Andrew Premdas
blog.andrew.premdas.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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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.

--
------------------------
Andrew Premdas
blog.andrew.premdas.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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[Andrew Premdas]

Post by Behrad Sadoughian
This is just an environment variable. How can it select the right glue
when testing different application platforms?

Have the 'glue' interrogate the environment to determine what choice to
make. In general with Cucumber, don't do programming in features, either do
it above them (running cucumber via scripts with different options) or
below them (in the step definitions, or better yet in code below the step
defintions).

Post by Behrad Sadoughian

Post by Andrew Premdas

Post by Behrad Sadoughian
My Gherkin is completely the way you have done it.
I am using Cucember-JVM. How can I set environment like that in Java

Perhaps
https://docs.oracle.com/javase/tutorial/essential/environment/env.html
will help. I stopped using java many years ago, so am a bit out of touch :)

Post by Behrad Sadoughian

Post by Andrew Premdas

Post by bsz0206
Great articles. Thanks for them. I almost agree on most points you made.
However this dynamic glue changing (or options in general) is still
needed. Currently the way cukes works is almost complete design time
however sometimes you need to be able to change based on the run time
information. For example,
- you may like to run more tests only if some tests passed or failed
so you need to change the feature files list
- Also for glues, in my case, I have different HW/SW platforms with
same business rules. So the steps are the same with conflicting names
because they do the same thing for iPad, Android or Windows. Our Gherkin
writer need to create scenarios with multiple applications being tested at
the same time. For example user 1 goes to the Windows application and opens
a record and at the same time another user goes to the iPad doing the same.
I need to have this feature, so that I can swap glues based on the user and
platform. Otherwise we need to prefix all step with the platform name. Iike
When "user1" is on "Windows"
and goes to to file, open and opens file "x"
and "user2" is on "iPad"
and goes to to file, open and opens file "x"
- create another glue to wrap the other glues and do dependency injection.
Both of them are big hassles

You can use an environment variable to deal with that sort of problem.
However if you are writing scenarios where two different platforms are
being used at the same time, e.g. exploring the interaction between someone
using a tablet and a desktop application then you should put this in the
feature.
Given Fred is using his tablet
And Bill is using his desktop
When Fred gives Bill a foo
Then Bill should see the foo
Now you could run this with multiple combinations of tablet and desktop
using environment variables
e.g.
DESKTOP=WIndows TABLET=ipad cucumber ...
DESKTOP=osx TABLET=s4 cucumber ...
and write step definitions that use the environment variables to choose
HOW to do things
e.g.
Given 'Fred is using his tablet' do
use_tablet tablet: env.TABLET, user: Fred
end
module TabletUser
def use_tablet attrs
case attrs[:tablet]
when S4
use_s4
.....
end
end
You really do not need to do any programming in feature files. They are
best used for expressing WHAT is being done and WHY it has value, rather
than trying to document HOW things are done.

Post by bsz0206
Hi,
Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"
When I am testing site A
And I log in as user "a", "b"
When I am testing site B
And I log in as user "a", "b"
So there are two similar step definitions and glue should change as
per the previous step.
Is there any way this can be done?

--

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

--
------------------------
Andrew Premdas
blog.andrew.premdas.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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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
For more options, visit https://groups.google.com/d/optout.

--
------------------------
Andrew Premdas
blog.andrew.premdas.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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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.

--
------------------------
Andrew Premdas
blog.andrew.premdas.org

[Roberto Lo Giacco]

Post by bsz0206
Great articles. Thanks for them. I almost agree on most points you made.
However this dynamic glue changing (or options in general) is still
needed. Currently the way cukes works is almost complete design time
however sometimes you need to be able to change based on the run time
information. For example,
- you may like to run more tests only if some tests passed or failed so
you need to change the feature files list

If this aims at reducing testing time then you can use tags to mark the
core tests and execute a more extended set of tests in case any core test
fail...

Post by bsz0206
- Also for glues, in my case, I have different HW/SW platforms with same
business rules. So the steps are the same with conflicting names because
they do the same thing for iPad, Android or Windows. Our Gherkin writer
need to create scenarios with multiple applications being tested at the
same time. For example user 1 goes to the Windows application and opens a
record and at the same time another user goes to the iPad doing the same. I
need to have this feature, so that I can swap glues based on the user and
platform. Otherwise we need to prefix all step with the platform name. Iike

The glue code can be set at execution time, like through the Maven plugin
configuration. So, if you put your platform code into different packages
plus, may be, an additional generic code package, you can obtain the
separation you are mentioning:

foo.bar.app.stepdefs.common
foo.bar.app.stepdefs.android
foo.bar.app.stepdefs.ios
foo.bar.app.stepdefs.windows
foo.bar.app.stepdefs.linux
foo.bar.app.stepdefs.macos

Post by bsz0206
When "user1" is on "Windows"
and goes to to file, open and opens file "x"
and "user2" is on "iPad"
and goes to to file, open and opens file "x"
- create another glue to wrap the other glues and do dependency injection.
Both of them are big hassles.

I agree, but you don't need it.

Separate the glue code, remove the platform from your steps and eventually
move it to tags to determine which platforms is bound to a test. This way
you enormously reduce the quantity of scenarios you have and your
stakeholders are no more forced to read the same scenario 5 times to
understand what your application does. If they want to know which feature
is available for which platform they can inspect the scenario tags.

I hope this makes sense to your context...

Tags are a powerful tool, but they are often underestimated or
misunderstood ;)

[Behrad Sadoughian]

Thanks for answering.

But assume a scenario which too version of the software are talking to each
other. It cannot be executed in different tags or different runs. It needs
to switch the glue between the steps -OR- you have to create dependency
injection but that needs you to wrap all the steps. The following is
completely business oriented:

When "John" is using his Android with version 4.2.1 of software installed
And he logs in
And he sends a chat "Lorem Ipsum" to "John"
When "John" is using his Android with version 7.8.2 of software installed
when he logs in
Then he should receive "Lorem Ipsum" from "John"

Post by Roberto Lo Giacco

Post by bsz0206
Great articles. Thanks for them. I almost agree on most points you made.
However this dynamic glue changing (or options in general) is still
needed. Currently the way cukes works is almost complete design time
however sometimes you need to be able to change based on the run time
information. For example,
- you may like to run more tests only if some tests passed or failed so
you need to change the feature files list

If this aims at reducing testing time then you can use tags to mark the
core tests and execute a more extended set of tests in case any core test
fail...

Post by bsz0206
- Also for glues, in my case, I have different HW/SW platforms with same
business rules. So the steps are the same with conflicting names because
they do the same thing for iPad, Android or Windows. Our Gherkin writer
need to create scenarios with multiple applications being tested at the
same time. For example user 1 goes to the Windows application and opens a
record and at the same time another user goes to the iPad doing the same. I
need to have this feature, so that I can swap glues based on the user and
platform. Otherwise we need to prefix all step with the platform name. Iike

The glue code can be set at execution time, like through the Maven plugin
configuration. So, if you put your platform code into different packages
plus, may be, an additional generic code package, you can obtain the
foo.bar.app.stepdefs.common
foo.bar.app.stepdefs.android
foo.bar.app.stepdefs.ios
foo.bar.app.stepdefs.windows
foo.bar.app.stepdefs.linux
foo.bar.app.stepdefs.macos

Post by bsz0206
When "user1" is on "Windows"
and goes to to file, open and opens file "x"
and "user2" is on "iPad"
and goes to to file, open and opens file "x"
- create another glue to wrap the other glues and do dependency injection.
Both of them are big hassles.

I agree, but you don't need it.
Separate the glue code, remove the platform from your steps and eventually
move it to tags to determine which platforms is bound to a test. This way
you enormously reduce the quantity of scenarios you have and your
stakeholders are no more forced to read the same scenario 5 times to
understand what your application does. If they want to know which feature
is available for which platform they can inspect the scenario tags.
I hope this makes sense to your context...
Tags are a powerful tool, but they are often underestimated or
misunderstood ;)
--
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/-CAXBS5otWs/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]

On Mon, Apr 13, 2015 at 11:41 AM, Behrad Sadoughian <

Post by Behrad Sadoughian
Thanks for answering.
But assume a scenario which too version of the software are talking to
each other. It cannot be executed in different tags or different runs. It
needs to switch the glue between the steps -OR- you have to create
dependency injection but that needs you to wrap all the steps. The
When "John" is using his Android with version 4.2.1 of software installed
And he logs in
And he sends a chat "Lorem Ipsum" to "John"
When "John" is using his Android with version 7.8.2 of software installed
when he logs in
Then he should receive "Lorem Ipsum" from "John"

Sure you can, but you have to differentiate your stepdefs as, even if they
are the same software, they play two different roles:

@client-android
@agent-android
When client "John" is using his tablet
And he logs in
And he sends a chat "Lorem Ipsum" to "John"
When agent "John" is using his tablet
And he logs in
Then he should receive "Lorem Ipsum" from "John"

With environment variables:
android.client.version=4.2.1
android.agent.version=7.8.2

I believe your mistake is you are focusing on HOW rather than on WHAT.

You are focused on the implementation rather than on the specification... I
believe what it matters is the language: you don't seem to use a business
language in your feature files, but a technical language...

Android, version.... does that really matter to the chat user? I believe
the language you should use is "sender, receiver, friends, contacts"...

If you focus on business language than the distinction will be
straightforward and your stakeholders will be able to read your feature
files. If you don't, then you are writing JUnit tests with an additional
level of indirection you, and you only, will be able to read...

That's my humble opinion.

[bsz0206]

I don't think that is possible. Let go back to your own example:

Given Fred is using his tablet
And Bill is using his desktop
When Fred gives Bill a foo
Then Bill should see the foo

Let me know how this is technically possible in JVM.

Post by bsz0206
Hi,
Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"
When I am testing site A
And I log in as user "a", "b"
When I am testing site B
And I log in as user "a", "b"
So there are two similar step definitions and glue should change as per
the previous step.
Is there any way this can be done?

[Behrad Sadoughian]

It doesn't work because glues conflict:

Given "Fred" is using his tablet
when he logs in
and "John is using his Android"
when he logs in

This is a simplified situation. The point is that we have many similar
steps because there are the same application for different platforms (4).
We could prefix all steps with something but that's not good. We could use
dependency injection etc. but glues have been developed by different teams
and that would be a huge effort.

The best thing is adding a feature to cuke-jvm to be able to dynamically
change the glue package path.

Below is rubyish pseudocode with a bit of java thrown in (system.getenv).
I'm sure there is nothing in java stopping a step definition from getting
an environment variable and make a method call based on its value.
Given "Fred is using his tablet" do
case system.getenv 'TABLET"
when 'IPAD"
use_ipad( user: 'Fred' )
when 'ANDROID"
use_andriod( user: 'Fred'
default
...
end
end

Post by Andrew Premdas
Given Fred is using his tablet
And Bill is using his desktop
When Fred gives Bill a foo
Then Bill should see the foo
Let me know how this is technically possible in JVM.

Post by bsz0206
Hi,
Sometimes you need to change your glues based dynamically based on the
previous steps. Assume you have an step like this: "I log in"
When I am testing site A
And I log in as user "a", "b"
When I am testing site B
And I log in as user "a", "b"
So there are two similar step definitions and glue should change as per
the previous step.
Is there any way this can be done?

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

--
------------------------
Andrew Premdas
blog.andrew.premdas.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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[George Dinwiddie]

Behrad,

Post by Behrad Sadoughian
Given "Fred" is using his tablet
when he logs in
and "John is using his Android"
when he logs in
This is a simplified situation. The point is that we have many similar
steps because there are the same application for different platforms
(4). We could prefix all steps with something but that's not good. We
could use dependency injection etc. but glues have been developed by
different teams and that would be a huge effort.
The best thing is adding a feature to cuke-jvm to be able to dynamically
change the glue package path.

Do I understand you correctly? You've got kind of a mess of step
definitions and glue code developed by different teams, and rather than
clean up your mess, you want a feature added to cucumber-jvm to support
having such a mess?

How long do you think that would be sufficient?

If you don't want to clean up the mess, why don't you just sort things
out into separate suites (perhaps just using tags), and make multiple
runs with your different glue-logic paths?

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

[Behrad Sadoughian]

I think this is a very common situation and needed by many people. It is
not a mess up. There are many scenarios that you need such features and if
you think a bit you will explore more.

One more:

When "John" is using his Android with version 4.2.1 of software installed
And he logs in
And he sends a chat "Lorem Ipsum" to "John"
When "John" is using his Android with version 7.8.2 of software installed
when he logs in
Then he should receive "Lorem Ipsum" from "John"

Is this mess up? No it is not. My other example was not a mess up too. It
was just simplified to understand. What people tend to do here, it to take
examples very literal and assume other people are stupid.
People who bring examples have to make them simple because otherwise I
should write 100 lines and you should read 100 lines, and I have to reveal
things I am not allowed to.

Should I expect the next question be: "Lorem Ipsum" is not proper words and
should not be sent in chats!?

Post by George Dinwiddie
Behrad,

Post by Behrad Sadoughian
Given "Fred" is using his tablet
when he logs in
and "John is using his Android"
when he logs in
This is a simplified situation. The point is that we have many similar
steps because there are the same application for different platforms
(4). We could prefix all steps with something but that's not good. We
could use dependency injection etc. but glues have been developed by
different teams and that would be a huge effort.
The best thing is adding a feature to cuke-jvm to be able to dynamically
change the glue package path.

Do I understand you correctly? You've got kind of a mess of step
definitions and glue code developed by different teams, and rather than
clean up your mess, you want a feature added to cucumber-jvm to support
having such a mess?
How long do you think that would be sufficient?
If you don't want to clean up the mess, why don't you just sort things out
into separate suites (perhaps just using tags), and make multiple runs with
your different glue-logic paths?
- George
--
----------------------------------------------------------------------
* 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/-CAXBS5otWs/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 Behrad Sadoughian
I think this is a very common situation and needed by many people. It is
not a mess up. There are many scenarios that you need such features and if
you think a bit you will explore more.
When "John" is using his Android with version 4.2.1 of software installed
And he logs in
And he sends a chat "Lorem Ipsum" to "John"
When "John" is using his Android with version 7.8.2 of software installed
when he logs in
Then he should receive "Lorem Ipsum" from "John"

First option is to have only one feature without the version mentioned (as
this is most probably not business related)


When "John" is using his Android
When he logs in
Then he should receive "Lorem Ipsum" from "John"


And run your features twice: one with an environment variable
android.version=7.8.2 and one with android.version=4.2.1
This way you do not have to write each and every scenario twice (or may be
more).
In case there are features/scenarios not applicable to certain environments
you can use tags to mark those, like if the above one is not applicable to
versions below 5

@version-5+
Scenario: user logs in

When "John" is using his Android
When he logs in
Then he should receive "Lorem Ipsum" from "John"


I would go a little bit further on this and remove the platform as well:

@android-4+
@ios-6+
Scenario: user logs in

When "John" is using his tablet
When he logs in
Then he should receive "Lorem Ipsum" from "John"


Do you notice how you have removed the technical implementation details
from the scenario? That is exactly the point for Cucumber, having feature
files readable by your stakeholders...

So, instead of dynamically switching the environment, would multiple
execution with different environment information fit your needs?

Is this mess up? No it is not. My other example was not a mess up too. It

Post by Behrad Sadoughian
was just simplified to understand. What people tend to do here, it to take
examples very literal and assume other people are stupid.
People who bring examples have to make them simple because otherwise I
should write 100 lines and you should read 100 lines, and I have to reveal
things I am not allowed to.
Should I expect the next question be: "Lorem Ipsum" is not proper words
and should not be sent in chats!?

I do appreciate the sarcasm, but I suggest to spend a little bit more time
trying to understand the advices you are getting: using Cucumber the right
way it's not easy and it's full of pitfalls ;)

Regards,
Roberto

[Behrad Sadoughian]

When you are testing the compatibility between different applications you
cannot simply start over.

It is not just two steps. They are going to do many steps, handshakes,
communication etc. like that.

Post by Roberto Lo Giacco

Post by Behrad Sadoughian
I think this is a very common situation and needed by many people. It is
not a mess up. There are many scenarios that you need such features and if
you think a bit you will explore more.
When "John" is using his Android with version 4.2.1 of software installed
And he logs in
And he sends a chat "Lorem Ipsum" to "John"
When "John" is using his Android with version 7.8.2 of software installed
when he logs in
Then he should receive "Lorem Ipsum" from "John"

First option is to have only one feature without the version mentioned (as
this is most probably not business related)
When "John" is using his Android
When he logs in
Then he should receive "Lorem Ipsum" from "John"
And run your features twice: one with an environment variable
android.version=7.8.2 and one with android.version=4.2.1
This way you do not have to write each and every scenario twice (or may be
more).
In case there are features/scenarios not applicable to certain
environments you can use tags to mark those, like if the above one is not
applicable to versions below 5
@version-5+
Scenario: user logs in
When "John" is using his Android
When he logs in
Then he should receive "Lorem Ipsum" from "John"
@android-4+
@ios-6+
Scenario: user logs in
When "John" is using his tablet
When he logs in
Then he should receive "Lorem Ipsum" from "John"
Do you notice how you have removed the technical implementation details
from the scenario? That is exactly the point for Cucumber, having feature
files readable by your stakeholders...
So, instead of dynamically switching the environment, would multiple
execution with different environment information fit your needs?
Is this mess up? No it is not. My other example was not a mess up too. It

Post by Behrad Sadoughian
was just simplified to understand. What people tend to do here, it to take
examples very literal and assume other people are stupid.
People who bring examples have to make them simple because otherwise I
should write 100 lines and you should read 100 lines, and I have to reveal
things I am not allowed to.
Should I expect the next question be: "Lorem Ipsum" is not proper words
and should not be sent in chats!?

I do appreciate the sarcasm, but I suggest to spend a little bit more time
trying to understand the advices you are getting: using Cucumber the right
way it's not easy and it's full of pitfalls ;)
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/-CAXBS5otWs/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]

On Mon, Apr 13, 2015 at 11:11 AM, Behrad Sadoughian <

Post by Behrad Sadoughian
When you are testing the compatibility between different applications you
cannot simply start over.
It is not just two steps. They are going to do many steps, handshakes,
communication etc. like that.
Ok, so you want to have two different environments to coexist?

Like some steps occur on a device and some others occur on another device?

Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"

If the above is a decent representation of your context then my suggestions
still apply (tags to determine applicable versions and platforms)

@tablet-android
@tablet-ios
@desktop-windows
Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"

You can still switch the glue code for the different tablets implementation
and desktop implementations, but you have to define two different sets of
glue code for the "Tablet" and the "Desktop" steps because, as pointed by
Aslak, they do represent two different concepts in your context.

Let's abstract for a second by the fact they are two similar device and
take the following in consideration:

Scenario: data update
Given the user is logged in
When the user edits his personal profile data as
| firstname | Roberto |
| lastname | Lo Giacco |
Then the database contents are
| firstname | Roberto |
| lastname | Lo Giacco |

It's a very stupid test, still it does have two different "environments",
one being the application and the other the database. The test is verifying
the two environments communicate as expected, like in your case.
Would it make sense to have one step which maps to the two stepdefs,
switching the environment from the application to the database
implementation? I don't think so.... even if they are using the same data
and data format.

Could I apply the concept you are trying to achieve with the dynamic glue
code? Sure I can:

Scenario: data update
Given the user is logged in
When the user personal profile "on the app" are
| firstname | Roberto |
| lastname | Lo Giacco |
Then the user personal profile "on the database" are
| firstname | Roberto |
| lastname | Lo Giacco |

Would it make sense? Not to me and I believe to you neither.

In other words, we all advice you to avoid the glue code switch thing and
we believe the path you are pursuing is leading you in a pit full of
spikes: you are free to go ahead down your route, but don't ask us to
follow you ;-)

If you have two systems interacting and you want to test their interaction
than you need to describe them separately and have separate steps and
stepdefs. Even if the two systems are two tablets:

Scenario: data update
Given the user is logged in a tablet
And one of his friends is logged in a tablet
When the user shares his position
Then his friend receives a notification

Then to test the different implementations you switch the environment
configuration: two androids, two ios, etc...

They are two systems interacting.

Now, if you believe I didn't still get your context, I suggest you share an
appropriate down scaled version of one of your real feature files, because
all your reasoning is a "feature smell" to me :-D

Regards,
Roberto

[Behrad Sadoughian]

Thanks for your long description. Yes, there are ways to do it:
1) Making steps definitions globally unique (it is not possible in many
cases and you will see below just one of the examples):
2) kind of injecting the glue to mimic a dynamic glue (but needs you to
override everything)
3) dynamic glues

This is just one of the examples of why you need it:

*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*


*How can you do this with @tags etc? Not possible. *
*Can you do this with #1 and #2? **Yes, but a lot of efforts is needed.*

Post by Roberto Lo Giacco
On Mon, Apr 13, 2015 at 11:11 AM, Behrad Sadoughian <

Post by Behrad Sadoughian
When you are testing the compatibility between different applications you
cannot simply start over.
It is not just two steps. They are going to do many steps, handshakes,
communication etc. like that.
Ok, so you want to have two different environments to coexist?

Like some steps occur on a device and some others occur on another device?
Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"
If the above is a decent representation of your context then my
suggestions still apply (tags to determine applicable versions and
platforms)
@tablet-android
@tablet-ios
@desktop-windows
Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"
You can still switch the glue code for the different tablets
implementation and desktop implementations, but you have to define two
different sets of glue code for the "Tablet" and the "Desktop" steps
because, as pointed by Aslak, they do represent two different concepts in
your context.
Let's abstract for a second by the fact they are two similar device and
Scenario: data update
Given the user is logged in
When the user edits his personal profile data as
| firstname | Roberto |
| lastname | Lo Giacco |
Then the database contents are
| firstname | Roberto |
| lastname | Lo Giacco |
It's a very stupid test, still it does have two different "environments",
one being the application and the other the database. The test is verifying
the two environments communicate as expected, like in your case.
Would it make sense to have one step which maps to the two stepdefs,
switching the environment from the application to the database
implementation? I don't think so.... even if they are using the same data
and data format.
Could I apply the concept you are trying to achieve with the dynamic glue
Scenario: data update
Given the user is logged in
When the user personal profile "on the app" are
| firstname | Roberto |
| lastname | Lo Giacco |
Then the user personal profile "on the database" are
| firstname | Roberto |
| lastname | Lo Giacco |
Would it make sense? Not to me and I believe to you neither.
In other words, we all advice you to avoid the glue code switch thing and
we believe the path you are pursuing is leading you in a pit full of
spikes: you are free to go ahead down your route, but don't ask us to
follow you ;-)
If you have two systems interacting and you want to test their interaction
than you need to describe them separately and have separate steps and
Scenario: data update
Given the user is logged in a tablet
And one of his friends is logged in a tablet
When the user shares his position
Then his friend receives a notification
Then to test the different implementations you switch the environment
configuration: two androids, two ios, etc...
They are two systems interacting.
Now, if you believe I didn't still get your context, I suggest you share
an appropriate down scaled version of one of your real feature files,
because all your reasoning is a "feature smell" to me :-D
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/-CAXBS5otWs/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]

On Mon, Apr 13, 2015 at 6:30 PM, Behrad Sadoughian <

Post by Behrad Sadoughian
1) Making steps definitions globally unique (it is not possible in many
2) kind of injecting the glue to mimic a dynamic glue (but needs you to
override everything)
3) dynamic glues
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*

I believe I already answered this question which is not in using tags, but
in describing the system role rather than it's implementation:


*Scenario: both android*

*When "John" is using his android client*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his android agent*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*


This example reports the client and agent (I'm not sure this is the correct
terminology in your business context) both being android, my preference
though would be to be platform agnostic, like in the following:


*Scenario: *

*When "John" is using his client*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his agent*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*


With client.platform=android and agent.platform=android and gluecode
included being:

foo.bar.app.client.android

foo.bar.app.agent.android

If I want to test client as windows and agent as android

foo.bar.app.client.windows

foo.bar.app.agent.android


I would use tags only to exclude/include certain tests in case some are not
applicable to some contexts.

The way you were describing your test in case you have the client as
windows and android and the agent as windows and android would have been:

*Scenario: both android*
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*

*Scenario: android client*
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Windows with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*

*Scenario: windows client*
*When "John" is using his Windows with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*

*Scenario: both windows*
*When "John" is using his Windows with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Windows with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*


And this doesn't take in account the proliferation due to versions mixing!
Can you imagine the number of tests you will end up with? I would never
read those tests: after the first four I would say: "Ok, tell me what this
application does, I'm not going to read this".

It could be acceptable for me if you go for:

*Scenario Outline: simple message*
*When "John" is using his <client> with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his <agent> with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*

*Examples:*

*| client | agent |*

*| Windows | Windows |*

*| Android | Android |*

*| Windows | Android |*

*| Android | Windows |*


And even in this condition I would consider the table a cluttering element
which doesn't add much to the specification. Especially if I will end up
having that table on each and every scenario.

Please, think about the following sentence: feature files do not describe
tests, but system features where each scenario represents a usage context
for that feature.

If your feature files describe tests than you are wasting time and money
because tests can be written much easier using testing frameworks. The
executability of the feature files is a plus and its binding with test code
is a common practice, not a constraint. Nobody prevents you to use the
stepdefs to take application screenshots rather than executing asserts.

Actually an idea just came to my mind.... :->

*Can you do this with #1 and #2? **Yes, but a lot of efforts is needed.*

Post by Behrad Sadoughian

Post by Roberto Lo Giacco
On Mon, Apr 13, 2015 at 11:11 AM, Behrad Sadoughian <

Post by Behrad Sadoughian
When you are testing the compatibility between different applications
you cannot simply start over.
It is not just two steps. They are going to do many steps, handshakes,
communication etc. like that.
Ok, so you want to have two different environments to coexist?

Like some steps occur on a device and some others occur on another device?
Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"
If the above is a decent representation of your context then my
suggestions still apply (tags to determine applicable versions and
platforms)
@tablet-android
@tablet-ios
@desktop-windows
Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"
You can still switch the glue code for the different tablets
implementation and desktop implementations, but you have to define two
different sets of glue code for the "Tablet" and the "Desktop" steps
because, as pointed by Aslak, they do represent two different concepts in
your context.
Let's abstract for a second by the fact they are two similar device and
Scenario: data update
Given the user is logged in
When the user edits his personal profile data as
| firstname | Roberto |
| lastname | Lo Giacco |
Then the database contents are
| firstname | Roberto |
| lastname | Lo Giacco |
It's a very stupid test, still it does have two different "environments",
one being the application and the other the database. The test is verifying
the two environments communicate as expected, like in your case.
Would it make sense to have one step which maps to the two stepdefs,
switching the environment from the application to the database
implementation? I don't think so.... even if they are using the same data
and data format.
Could I apply the concept you are trying to achieve with the dynamic glue
Scenario: data update
Given the user is logged in
When the user personal profile "on the app" are
| firstname | Roberto |
| lastname | Lo Giacco |
Then the user personal profile "on the database" are
| firstname | Roberto |
| lastname | Lo Giacco |
Would it make sense? Not to me and I believe to you neither.
In other words, we all advice you to avoid the glue code switch thing and
we believe the path you are pursuing is leading you in a pit full of
spikes: you are free to go ahead down your route, but don't ask us to
follow you ;-)
If you have two systems interacting and you want to test their
interaction than you need to describe them separately and have separate
Scenario: data update
Given the user is logged in a tablet
And one of his friends is logged in a tablet
When the user shares his position
Then his friend receives a notification
Then to test the different implementations you switch the environment
configuration: two androids, two ios, etc...
They are two systems interacting.
Now, if you believe I didn't still get your context, I suggest you share
an appropriate down scaled version of one of your real feature files,
because all your reasoning is a "feature smell" to me :-D
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[Behrad Sadoughian]

Thanks. Again, you described the way to write a good gherkin but please
tell me how you can technically implemented what you said with the #4 th
option that I am not aware of. I said I know #1 and #2 are possible but
they are not cost effective so I asked for #3.

If there is a $4 option, doable in Java, that I am not aware of, please
help me understand it.

The way I understand yours, tells me that you client.platform=android is
actually my Injecting solution (#2).

Can you please elaborate more?

Post by Roberto Lo Giacco
On Mon, Apr 13, 2015 at 6:30 PM, Behrad Sadoughian <

Post by Behrad Sadoughian
1) Making steps definitions globally unique (it is not possible in many
2) kind of injecting the glue to mimic a dynamic glue (but needs you to
override everything)
3) dynamic glues
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*

I believe I already answered this question which is not in using tags, but
*Scenario: both android*
*When "John" is using his android client*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his android agent*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
This example reports the client and agent (I'm not sure this is the
correct terminology in your business context) both being android, my
*Scenario: *
*When "John" is using his client*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his agent*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
With client.platform=android and agent.platform=android and gluecode
foo.bar.app.client.android
foo.bar.app.agent.android
If I want to test client as windows and agent as android
foo.bar.app.client.windows
foo.bar.app.agent.android
I would use tags only to exclude/include certain tests in case some are
not applicable to some contexts.
The way you were describing your test in case you have the client as
*Scenario: both android*
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Scenario: android client*
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Windows with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Scenario: windows client*
*When "John" is using his Windows with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Scenario: both windows*
*When "John" is using his Windows with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Windows with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
And this doesn't take in account the proliferation due to versions mixing!
Can you imagine the number of tests you will end up with? I would never
read those tests: after the first four I would say: "Ok, tell me what this
application does, I'm not going to read this".
*Scenario Outline: simple message*
*When "John" is using his <client> with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his <agent> with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Examples:*
*| client | agent |*
*| Windows | Windows |*
*| Android | Android |*
*| Windows | Android |*
*| Android | Windows |*
And even in this condition I would consider the table a cluttering element
which doesn't add much to the specification. Especially if I will end up
having that table on each and every scenario.
Please, think about the following sentence: feature files do not describe
tests, but system features where each scenario represents a usage context
for that feature.
If your feature files describe tests than you are wasting time and money
because tests can be written much easier using testing frameworks. The
executability of the feature files is a plus and its binding with test code
is a common practice, not a constraint. Nobody prevents you to use the
stepdefs to take application screenshots rather than executing asserts.
Actually an idea just came to my mind.... :->
*Can you do this with #1 and #2? **Yes, but a lot of efforts is needed.*

Post by Behrad Sadoughian

Post by Roberto Lo Giacco
On Mon, Apr 13, 2015 at 11:11 AM, Behrad Sadoughian <

Post by Behrad Sadoughian
When you are testing the compatibility between different applications
you cannot simply start over.
It is not just two steps. They are going to do many steps, handshakes,
communication etc. like that.
Ok, so you want to have two different environments to coexist?

Like some steps occur on a device and some others occur on another device?
Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"
If the above is a decent representation of your context then my
suggestions still apply (tags to determine applicable versions and
platforms)
@tablet-android
@tablet-ios
@desktop-windows
Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"
You can still switch the glue code for the different tablets
implementation and desktop implementations, but you have to define two
different sets of glue code for the "Tablet" and the "Desktop" steps
because, as pointed by Aslak, they do represent two different concepts in
your context.
Let's abstract for a second by the fact they are two similar device and
Scenario: data update
Given the user is logged in
When the user edits his personal profile data as
| firstname | Roberto |
| lastname | Lo Giacco |
Then the database contents are
| firstname | Roberto |
| lastname | Lo Giacco |
It's a very stupid test, still it does have two different
"environments", one being the application and the other the database. The
test is verifying the two environments communicate as expected, like in
your case.
Would it make sense to have one step which maps to the two stepdefs,
switching the environment from the application to the database
implementation? I don't think so.... even if they are using the same data
and data format.
Could I apply the concept you are trying to achieve with the dynamic
Scenario: data update
Given the user is logged in
When the user personal profile "on the app" are
| firstname | Roberto |
| lastname | Lo Giacco |
Then the user personal profile "on the database" are
| firstname | Roberto |
| lastname | Lo Giacco |
Would it make sense? Not to me and I believe to you neither.
In other words, we all advice you to avoid the glue code switch thing
and we believe the path you are pursuing is leading you in a pit full of
spikes: you are free to go ahead down your route, but don't ask us to
follow you ;-)
If you have two systems interacting and you want to test their
interaction than you need to describe them separately and have separate
Scenario: data update
Given the user is logged in a tablet
And one of his friends is logged in a tablet
When the user shares his position
Then his friend receives a notification
Then to test the different implementations you switch the environment
configuration: two androids, two ios, etc...
They are two systems interacting.
Now, if you believe I didn't still get your context, I suggest you share
an appropriate down scaled version of one of your real feature files,
because all your reasoning is a "feature smell" to me :-D
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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/-CAXBS5otWs/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]

On Mon, Apr 13, 2015 at 7:48 PM, Behrad Sadoughian <

Post by Behrad Sadoughian
Thanks. Again, you described the way to write a good gherkin but please
tell me how you can technically implemented what you said with the #4 th
option that I am not aware of. I said I know #1 and #2 are possible but
they are not cost effective so I asked for #3.

But Cucumber *is* about Gherkin... Anyway, if you don't want to accept #1
restriction I don't believe Gherkin (and so Cucumber) is the tool for you.
I believe I've given you a few examples and rationales about changing your
feature files to work around #1 by not needing #3. We do it everyday. You
say #1 and #2 are not cost effective, but my advice is #3 will be even less
cost effective: if you want to reduce cost and you don't need readable
feature files why are you using Cucumber?

Post by Behrad Sadoughian
If there is a $4 option, doable in Java, that I am not aware of, please
help me understand it.
The way I understand yours, tells me that you client.platform=android is
actually my Injecting solution (#2).
Can you please elaborate more?

That's not that complex as the Java entry point is capable of reading the
CucumberOptions
<http://cucumber.github.io/api/cucumber/jvm/javadoc/cucumber/api/CucumberOptions.html>
from
the command line, which means you can start cucumber-jvm with --glue and
provide path entries or, if you use Maven, use the <cucumber.options>
configuration element to provide the same info.
My suggestion was to build the glue parameter value using some other system
property, so having a core set always included plus the specific
implementations.
Believe me, this is already an exotic configuration, but I've already been
there and I know this might be required, but not on everyday project.

I'm not aware of any #4 which doesn't go even more exotic and I'm not going
to point you at that direction: not because I'm cool and you aren't, but
because I believe it will not play in your favor and you will eventually
blame me for letting you go down that route.


BTW, have you ever read the posting rules (
http://cukes.info/posting-rules.html)?

Roberto

Post by Behrad Sadoughian

Post by Roberto Lo Giacco
On Mon, Apr 13, 2015 at 6:30 PM, Behrad Sadoughian <

Post by Behrad Sadoughian
1) Making steps definitions globally unique (it is not possible in many
2) kind of injecting the glue to mimic a dynamic glue (but needs you to
override everything)
3) dynamic glues
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*

I believe I already answered this question which is not in using tags,
*Scenario: both android*
*When "John" is using his android client*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his android agent*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
This example reports the client and agent (I'm not sure this is the
correct terminology in your business context) both being android, my
*Scenario: *
*When "John" is using his client*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his agent*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
With client.platform=android and agent.platform=android and gluecode
foo.bar.app.client.android
foo.bar.app.agent.android
If I want to test client as windows and agent as android
foo.bar.app.client.windows
foo.bar.app.agent.android
I would use tags only to exclude/include certain tests in case some are
not applicable to some contexts.
The way you were describing your test in case you have the client as
*Scenario: both android*
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Scenario: android client*
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Windows with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Scenario: windows client*
*When "John" is using his Windows with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Scenario: both windows*
*When "John" is using his Windows with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Windows with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
And this doesn't take in account the proliferation due to versions
mixing! Can you imagine the number of tests you will end up with? I would
never read those tests: after the first four I would say: "Ok, tell me what
this application does, I'm not going to read this".
*Scenario Outline: simple message*
*When "John" is using his <client> with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his <agent> with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Examples:*
*| client | agent |*
*| Windows | Windows |*
*| Android | Android |*
*| Windows | Android |*
*| Android | Windows |*
And even in this condition I would consider the table a cluttering
element which doesn't add much to the specification. Especially if I will
end up having that table on each and every scenario.
Please, think about the following sentence: feature files do not describe
tests, but system features where each scenario represents a usage context
for that feature.
If your feature files describe tests than you are wasting time and money
because tests can be written much easier using testing frameworks. The
executability of the feature files is a plus and its binding with test code
is a common practice, not a constraint. Nobody prevents you to use the
stepdefs to take application screenshots rather than executing asserts.
Actually an idea just came to my mind.... :->
*Can you do this with #1 and #2? **Yes, but a lot of efforts is needed.*

Post by Behrad Sadoughian

Post by Roberto Lo Giacco
On Mon, Apr 13, 2015 at 11:11 AM, Behrad Sadoughian <

Post by Behrad Sadoughian
When you are testing the compatibility between different applications
you cannot simply start over.
It is not just two steps. They are going to do many steps, handshakes,
communication etc. like that.
Ok, so you want to have two different environments to coexist?

Like some steps occur on a device and some others occur on another device?
Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"
If the above is a decent representation of your context then my
suggestions still apply (tags to determine applicable versions and
platforms)
@tablet-android
@tablet-ios
@desktop-windows
Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"
You can still switch the glue code for the different tablets
implementation and desktop implementations, but you have to define two
different sets of glue code for the "Tablet" and the "Desktop" steps
because, as pointed by Aslak, they do represent two different concepts in
your context.
Let's abstract for a second by the fact they are two similar device and
Scenario: data update
Given the user is logged in
When the user edits his personal profile data as
| firstname | Roberto |
| lastname | Lo Giacco |
Then the database contents are
| firstname | Roberto |
| lastname | Lo Giacco |
It's a very stupid test, still it does have two different
"environments", one being the application and the other the database. The
test is verifying the two environments communicate as expected, like in
your case.
Would it make sense to have one step which maps to the two stepdefs,
switching the environment from the application to the database
implementation? I don't think so.... even if they are using the same data
and data format.
Could I apply the concept you are trying to achieve with the dynamic
Scenario: data update
Given the user is logged in
When the user personal profile "on the app" are
| firstname | Roberto |
| lastname | Lo Giacco |
Then the user personal profile "on the database" are
| firstname | Roberto |
| lastname | Lo Giacco |
Would it make sense? Not to me and I believe to you neither.
In other words, we all advice you to avoid the glue code switch thing
and we believe the path you are pursuing is leading you in a pit full of
spikes: you are free to go ahead down your route, but don't ask us to
follow you ;-)
If you have two systems interacting and you want to test their
interaction than you need to describe them separately and have separate
Scenario: data update
Given the user is logged in a tablet
And one of his friends is logged in a tablet
When the user shares his position
Then his friend receives a notification
Then to test the different implementations you switch the environment
configuration: two androids, two ios, etc...
They are two systems interacting.
Now, if you believe I didn't still get your context, I suggest you
share an appropriate down scaled version of one of your real feature files,
because all your reasoning is a "feature smell" to me :-D
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[Behrad Sadoughian]

Thanks. You are actually very cool! I appreciate your help very much.

Post by Roberto Lo Giacco
On Mon, Apr 13, 2015 at 7:48 PM, Behrad Sadoughian <

Post by Behrad Sadoughian
Thanks. Again, you described the way to write a good gherkin but please
tell me how you can technically implemented what you said with the #4 th
option that I am not aware of. I said I know #1 and #2 are possible but
they are not cost effective so I asked for #3.

But Cucumber *is* about Gherkin... Anyway, if you don't want to accept #1
restriction I don't believe Gherkin (and so Cucumber) is the tool for you.
I believe I've given you a few examples and rationales about changing your
feature files to work around #1 by not needing #3. We do it everyday. You
say #1 and #2 are not cost effective, but my advice is #3 will be even less
cost effective: if you want to reduce cost and you don't need readable
feature files why are you using Cucumber?

Post by Behrad Sadoughian
If there is a $4 option, doable in Java, that I am not aware of, please
help me understand it.
The way I understand yours, tells me that you client.platform=android is
actually my Injecting solution (#2).
Can you please elaborate more?

That's not that complex as the Java entry point is capable of reading the
CucumberOptions
<http://cucumber.github.io/api/cucumber/jvm/javadoc/cucumber/api/CucumberOptions.html> from
the command line, which means you can start cucumber-jvm with --glue and
provide path entries or, if you use Maven, use the <cucumber.options>
configuration element to provide the same info.
My suggestion was to build the glue parameter value using some other
system property, so having a core set always included plus the specific
implementations.
Believe me, this is already an exotic configuration, but I've already been
there and I know this might be required, but not on everyday project.
I'm not aware of any #4 which doesn't go even more exotic and I'm not
going to point you at that direction: not because I'm cool and you aren't,
but because I believe it will not play in your favor and you will
eventually blame me for letting you go down that route.
BTW, have you ever read the posting rules (
http://cukes.info/posting-rules.html)?
Roberto

Post by Behrad Sadoughian

Post by Roberto Lo Giacco
On Mon, Apr 13, 2015 at 6:30 PM, Behrad Sadoughian <

Post by Behrad Sadoughian
1) Making steps definitions globally unique (it is not possible in many
2) kind of injecting the glue to mimic a dynamic glue (but needs you to
override everything)
3) dynamic glues
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*

I believe I already answered this question which is not in using tags,
*Scenario: both android*
*When "John" is using his android client*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his android agent*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
This example reports the client and agent (I'm not sure this is the
correct terminology in your business context) both being android, my
*Scenario: *
*When "John" is using his client*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his agent*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
With client.platform=android and agent.platform=android and gluecode
foo.bar.app.client.android
foo.bar.app.agent.android
If I want to test client as windows and agent as android
foo.bar.app.client.windows
foo.bar.app.agent.android
I would use tags only to exclude/include certain tests in case some are
not applicable to some contexts.
The way you were describing your test in case you have the client as
*Scenario: both android*
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Scenario: android client*
*When "John" is using his Android with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Windows with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Scenario: windows client*
*When "John" is using his Windows with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Android with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Scenario: both windows*
*When "John" is using his Windows with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his Windows with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
And this doesn't take in account the proliferation due to versions
mixing! Can you imagine the number of tests you will end up with? I would
never read those tests: after the first four I would say: "Ok, tell me what
this application does, I'm not going to read this".
*Scenario Outline: simple message*
*When "John" is using his <client> with version 4.2.1 of software installed*
*And he logs in*
*And he sends a chat "Lorem Ipsum" to "John"*
*When "John" is using his <agent> with version 7.8.2 of software installed*
*when he logs in*
*Then he should receive "Lorem Ipsum" from "John"*
*Examples:*
*| client | agent |*
*| Windows | Windows |*
*| Android | Android |*
*| Windows | Android |*
*| Android | Windows |*
And even in this condition I would consider the table a cluttering
element which doesn't add much to the specification. Especially if I will
end up having that table on each and every scenario.
Please, think about the following sentence: feature files do not
describe tests, but system features where each scenario represents a usage
context for that feature.
If your feature files describe tests than you are wasting time and money
because tests can be written much easier using testing frameworks. The
executability of the feature files is a plus and its binding with test code
is a common practice, not a constraint. Nobody prevents you to use the
stepdefs to take application screenshots rather than executing asserts.
Actually an idea just came to my mind.... :->
*Can you do this with #1 and #2? **Yes, but a lot of efforts is needed.*

Post by Behrad Sadoughian

Post by Roberto Lo Giacco
On Mon, Apr 13, 2015 at 11:11 AM, Behrad Sadoughian <

Post by Behrad Sadoughian
When you are testing the compatibility between different applications
you cannot simply start over.
It is not just two steps. They are going to do many steps,
handshakes, communication etc. like that.
Ok, so you want to have two different environments to coexist?

Like some steps occur on a device and some others occur on another device?
Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"
If the above is a decent representation of your context then my
suggestions still apply (tags to determine applicable versions and
platforms)
@tablet-android
@tablet-ios
@desktop-windows
Scenario: tablet and desktop
Given the user is logged onto his tablet
And the user is logged onto his desktop app
When the user types "A" on his tablet
Then the desktop app shows "A"
You can still switch the glue code for the different tablets
implementation and desktop implementations, but you have to define two
different sets of glue code for the "Tablet" and the "Desktop" steps
because, as pointed by Aslak, they do represent two different concepts in
your context.
Let's abstract for a second by the fact they are two similar device
Scenario: data update
Given the user is logged in
When the user edits his personal profile data as
| firstname | Roberto |
| lastname | Lo Giacco |
Then the database contents are
| firstname | Roberto |
| lastname | Lo Giacco |
It's a very stupid test, still it does have two different
"environments", one being the application and the other the database. The
test is verifying the two environments communicate as expected, like in
your case.
Would it make sense to have one step which maps to the two stepdefs,
switching the environment from the application to the database
implementation? I don't think so.... even if they are using the same data
and data format.
Could I apply the concept you are trying to achieve with the dynamic
Scenario: data update
Given the user is logged in
When the user personal profile "on the app" are
| firstname | Roberto |
| lastname | Lo Giacco |
Then the user personal profile "on the database" are
| firstname | Roberto |
| lastname | Lo Giacco |
Would it make sense? Not to me and I believe to you neither.
In other words, we all advice you to avoid the glue code switch thing
and we believe the path you are pursuing is leading you in a pit full of
spikes: you are free to go ahead down your route, but don't ask us to
follow you ;-)
If you have two systems interacting and you want to test their
interaction than you need to describe them separately and have separate
Scenario: data update
Given the user is logged in a tablet
And one of his friends is logged in a tablet
When the user shares his position
Then his friend receives a notification
Then to test the different implementations you switch the environment
configuration: two androids, two ios, etc...
They are two systems interacting.
Now, if you believe I didn't still get your context, I suggest you
share an appropriate down scaled version of one of your real feature files,
because all your reasoning is a "feature smell" to me :-D
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
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/-CAXBS5otWs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
For more options, visit https://groups.google.com/d/optout.

[George Dinwiddie]

Behrad,

Post by Behrad Sadoughian
I think this is a very common situation and needed by many people. It is
not a mess up. There are many scenarios that you need such features and
if you think a bit you will explore more.

Can you name an example of another person who needs this?

Post by Behrad Sadoughian
When "John" is using his Android with version 4.2.1 of software installed
And he logs in
And he sends a chat "Lorem Ipsum" to "John"
When "John" is using his Android with version 7.8.2 of software installed
when he logs in
Then he should receive "Lorem Ipsum" from "John"

Where is the issue here, from your point of view?

I would suggest not using "John" for both participants. Also, I would
avoid pronouns such as "he" when there are multiple actors in a
scenario. It's easier to keep track if their names are explicitly specified.

Nor would I generally suggest "And he logs in" as an explicit step. I
would assume that in most steps, and only explicitly state when someone
is NOT logged in. Perhaps in this case you're trying to illustrate an
asynchronous nature to the communication, where the second John is
notified after logging in. If that's the case, there might be a way to
illustrate that more explicitly.

Post by Behrad Sadoughian
Is this mess up? No it is not. My other example was not a mess up too.
It was just simplified to understand. What people tend to do here, it to
take examples very literal and assume other people are stupid.

I'm not assuming anyone is stupid. I am, however, suspecting that your
step definitions are more imperative than declarative. And I'm
suspecting that you're using the step definitions as a programming
language rather than extracting the programming part into a helper library.

Post by Behrad Sadoughian
People who bring examples have to make them simple because otherwise I
should write 100 lines and you should read 100 lines, and I have to
reveal things I am not allowed to.

Oh, dear. If your scenarios are 100 lines long, you have bigger problems
than I suspected.

Post by Behrad Sadoughian
Should I expect the next question be: "Lorem Ipsum" is not proper words
and should not be sent in chats!?

There are a number of people on this list trying to help you. I'm not
sure you're taking their advice to heart. Instead, it seems you're fixed
on the solution of changing the design of Cucumber rather than using it
as it's designed. Of course, if it's really "the best thing" for you,
you can fork it and implement that. I suspect it's only "the best thing"
if someone else does the work.

I realize that some of the communication issues are due to language, but
also your simplified scenarios do not communicate your issue well. Nor
are you being specific about what is the problem. I think there are
solutions, but so far, it's hard for me to tell exactly what you're
trying to do.

You say that "glues conflict" but you're only showing steps. The step
definitions should call other code that performs the actual interaction
with the system.

For example, a step definition for 'When "John" is using his Android
with version 4.2.1 of software installed' and 'When "John" is using his
Android with version 7.8.2 of software installed' should remember the
platform and version associated with a user name. Then when the same
person (hence the desire to use different names, and avoid pronouns)
performs an action, the step definition can call code appropriate for
that platform and version. I think I would model the platform and
version as a class. An instance of that class can be associated with
John, and when John performs an action, the method corresponding to that
action can be called on that instance.

Do remember that Cucumber is primarily a collaboration tool, and
secondarily a testing tool. Also remember that you will get more help
with inquiry than confrontation.

- George

Post by Behrad Sadoughian
On Sat, Apr 11, 2015 at 6:26 PM, George Dinwiddie
Behrad,
Given "Fred" is using his tablet
when he logs in
and "John is using his Android"
when he logs in
This is a simplified situation. The point is that we have many similar
steps because there are the same application for different platforms
(4). We could prefix all steps with something but that's not good. We
could use dependency injection etc. but glues have been developed by
different teams and that would be a huge effort.
The best thing is adding a feature to cuke-jvm to be able to dynamically
change the glue package path.
Do I understand you correctly? You've got kind of a mess of step
definitions and glue code developed by different teams, and rather
than clean up your mess, you want a feature added to cucumber-jvm to
support having such a mess?
How long do you think that would be sufficient?
If you don't want to clean up the mess, why don't you just sort
things out into separate suites (perhaps just using tags), and make
multiple runs with your different glue-logic paths?
- George

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

[Behrad Sadoughian]

Thanks. I really appreciate everybody's help here and I am sorry if what I
said caused anybody think otherwise.

I am gradually reaching the point that I am in the wrong group. My question
is more about Cucumber-JVM implementation while anybody who is kind enough
to help starts to find the methodological issues of the gherkins I bring
here as examples. These are not my real gherkins. Just examples and I just
noticed I wrongly used "John" twice. It should be another user name as you
stated.

The points I like to add here:

I) If gherkin is a originally and collaboration tool not a test case
writing language really doesn't matter. When 99% (my figure) of people are
using it for tests, it is a testing tool (De Facto).

II) I wish people helped me to understand how my scenario can be
implemented. Forget the gherkin. One of my issues is like this:


I am testing the collaboration of different versions and presentation of
the same software. (iOS, Android, WebSite, ChromeApp, Windows). They do the
same thing and different users may use them at the same time. So for
example I need to be sure Windows-5.6.2.1 client can work with
Android-4.1.2.3. Like many other software, it needs concurrency, real time
collaboration etc scenarios.

I know how to write the gherkin. My gherkins are not 100 lines!!! I know
how to even implement this using dependency injection - or - adding a
suffix to all step definitions. That's what I am doing now. I found it
strange that the Cuke-JVM is trying to enforce and push a way of
development and came here to ask if there is any solution.

Post by George Dinwiddie
Behrad,

Post by Behrad Sadoughian
I think this is a very common situation and needed by many people. It is
not a mess up. There are many scenarios that you need such features and
if you think a bit you will explore more.

Can you name an example of another person who needs this?

*I know two different teams (other than my company)*

Post by George Dinwiddie

Post by Behrad Sadoughian
When "John" is using his Android with version 4.2.1 of software installed
And he logs in
And he sends a chat "Lorem Ipsum" to "John"
When "John" is using his Android with version 7.8.2 of software installed
when he logs in
Then he should receive "Lorem Ipsum" from "John"

Where is the issue here, from your point of view?

*How can the same "when he logs in" step call version 7.8.2 of the glue
and the other one the 4.2.1? I wanted the previous step "When John..."
dynamically change the glues as a solution.*

Post by George Dinwiddie
I would suggest not using "John" for both participants. Also, I would
avoid pronouns such as "he" when there are multiple actors in a scenario.
It's easier to keep track if their names are explicitly specified.

*No, I didn't. This was an example.*

Nor would I generally suggest "And he logs in" as an explicit step. I

Post by George Dinwiddie
would assume that in most steps, and only explicitly state when someone is
NOT logged in. Perhaps in this case you're trying to illustrate an
asynchronous nature to the communication, where the second John is notified
after logging in. If that's the case, there might be a way to illustrate
that more explicitly.

*This is an example. The actual login steps are different.*

Post by George Dinwiddie

Post by Behrad Sadoughian
Is this mess up? No it is not. My other example was not a mess up too.
It was just simplified to understand. What people tend to do here, it to
take examples very literal and assume other people are stupid.

I'm not assuming anyone is stupid. I am, however, suspecting that your
step definitions are more imperative than declarative. And I'm suspecting
that you're using the step definitions as a programming language rather
than extracting the programming part into a helper library.

*We write gherkins first and then add the support by programming. So it is
not like that. Please refer also to the points I and II above. *

Post by George Dinwiddie
People who bring examples have to make them simple because otherwise I

Post by Behrad Sadoughian
should write 100 lines and you should read 100 lines, and I have to
reveal things I am not allowed to.

Oh, dear. If your scenarios are 100 lines long, you have bigger problems
than I suspected.

*That was an example!!! I wanted to say that that it would make the email
longer than you can read.*

Post by George Dinwiddie

Post by Behrad Sadoughian
Should I expect the next question be: "Lorem Ipsum" is not proper words
and should not be sent in chats!?

There are a number of people on this list trying to help you. I'm not sure
you're taking their advice to heart. Instead, it seems you're fixed on the
solution of changing the design of Cucumber rather than using it as it's
designed. Of course, if it's really "the best thing" for you, you can fork
it and implement that. I suspect it's only "the best thing" if someone else
does the work.

*I know but I feel people but we should differentiate between help and mind
reading. I am now forking in places but I think it is not the best
approach. *
*The same reason, caused Java Packages and C# name spaces be added was the
same reason I need this feature.*

Post by George Dinwiddie
I realize that some of the communication issues are due to language, but
also your simplified scenarios do not communicate your issue well. Nor are
you being specific about what is the problem. I think there are solutions,
but so far, it's hard for me to tell exactly what you're trying to do.

*I think they do if you read them and look at them non-literally. Maybe I
am wrong.*

Post by George Dinwiddie
You say that "glues conflict" but you're only showing steps. The step
definitions should call other code that performs the actual interaction
with the system.

*If steps definitions need to be unique, while your glue steps are not
unique, a glue conflict can happen.*

Post by George Dinwiddie
For example, a step definition for 'When "John" is using his Android with
version 4.2.1 of software installed' and 'When "John" is using his Android
with version 7.8.2 of software installed' should remember the platform and
version associated with a user name. Then when the same person (hence the
desire to use different names, and avoid pronouns) performs an action, the
step definition can call code appropriate for that platform and version. I
think I would model the platform and version as a class. An instance of
that class can be associated with John, and when John performs an action,
the method corresponding to that action can be called on that instance.

*This is the same forking solution that I am implementing. But when 99%
your steps are similar it is not easy to maintain forked generic glues with
dependency injection.*

Post by George Dinwiddie
Do remember that Cucumber is primarily a collaboration tool, and
secondarily a testing tool. Also remember that you will get more help with
inquiry than confrontation.

*I don't remember that and I don't think it is important at all. There are
many things in this world that their primary purpose was different. I would
definitely say:*

*- Gherkin/Cucumber is a test writing language*

*Unless you give me some statistics that shows more than 20% of people are
using it for some other purpose.*

Post by George Dinwiddie
- George

Post by Behrad Sadoughian
On Sat, Apr 11, 2015 at 6:26 PM, George Dinwiddie
Behrad,
Given "Fred" is using his tablet
when he logs in
and "John is using his Android"
when he logs in
This is a simplified situation. The point is that we have many similar
steps because there are the same application for different platforms
(4). We could prefix all steps with something but that's not good. We
could use dependency injection etc. but glues have been developed by
different teams and that would be a huge effort.
The best thing is adding a feature to cuke-jvm to be able to dynamically
change the glue package path.
Do I understand you correctly? You've got kind of a mess of step
definitions and glue code developed by different teams, and rather
than clean up your mess, you want a feature added to cucumber-jvm to
support having such a mess?
How long do you think that would be sufficient?
If you don't want to clean up the mess, why don't you just sort
things out into separate suites (perhaps just using tags), and make
multiple runs with your different glue-logic paths?
- George

--
----------------------------------------------------------------------
* 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/-CAXBS5otWs/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]

On Tue, Apr 14, 2015 at 1:17 AM, Behrad Sadoughian <

Post by Behrad Sadoughian
Thanks. I really appreciate everybody's help here and I am sorry if what I
said caused anybody think otherwise.

Well, I've provided plenty of examples and justifications and you keep
ignoring them... I'm not going to keep my peace of mind with you.

Post by Behrad Sadoughian
I am gradually reaching the point that I am in the wrong group. My
question is more about Cucumber-JVM implementation while anybody who is
kind enough to help starts to find the methodological issues of the
gherkins I bring here as examples. These are not my real gherkins. Just
examples and I just noticed I wrongly used "John" twice. It should be
another user name as you stated.
I) If gherkin is a originally and collaboration tool not a test case
writing language really doesn't matter. When 99% (my figure) of people are
using it for tests, it is a testing tool (De Facto).

I'm really sorry if you believe so, if I want a testing tool I use JUnit
and if you are looking for a testing tool please use a testing tool. Do you
really want to convince us the tool we use for years is not what we think
just because it appears to you it is not? Gherkin is not "originally" a
collaboration tool, it just is. I've already had this conversation with a
team of developers in India working remotely for my company and they were
doing the exact same mistakes I see in your feature files: after rejecting
their sprint artifacts for the third time they started to listen as they
were not getting payed.

II) I wish people helped me to understand how my scenario can be
We cannot, as you are asking to the cucumber-jvm list which is, guess,
about cucumber, which is a gherkin parser with some integration support.
Most of the people over here do not even use Java as their stepdefs
language.

Post by Behrad Sadoughian
I am testing the collaboration of different versions and presentation of
the same software. (iOS, Android, WebSite, ChromeApp, Windows). They do the
same thing and different users may use them at the same time. So for
example I need to be sure Windows-5.6.2.1 client can work with
Android-4.1.2.3. Like many other software, it needs concurrency, real time
collaboration etc scenarios.
I know how to write the gherkin. My gherkins are not 100 lines!!! I know
how to even implement this using dependency injection - or - adding a
suffix to all step definitions. That's what I am doing now. I found it
strange that the Cuke-JVM is trying to enforce and push a way of
development and came here to ask if there is any solution.

I don't believe you know how to write gherkin and you should reconsider
your ability to do it because it appears very clear you are not writing
gherkin, you are writing integration tests using gherkin as a meta
language, whic is not!

Post by Behrad Sadoughian

Post by George Dinwiddie
Behrad,

Post by Behrad Sadoughian
I think this is a very common situation and needed by many people. It is
not a mess up. There are many scenarios that you need such features and
if you think a bit you will explore more.

Can you name an example of another person who needs this?

*I know two different teams (other than my company)*

Good to know: why don't you join up and fork the project as suggested? You
definitely have the capacity to do it.

Post by Behrad Sadoughian

Post by George Dinwiddie

Post by Behrad Sadoughian
When "John" is using his Android with version 4.2.1 of software installed
And he logs in
And he sends a chat "Lorem Ipsum" to "John"
When "John" is using his Android with version 7.8.2 of software installed
when he logs in
Then he should receive "Lorem Ipsum" from "John"

Where is the issue here, from your point of view?

*How can the same "when he logs in" step call version 7.8.2 of the glue
and the other one the 4.2.1? I wanted the previous step "When John..."
dynamically change the glues as a solution.*

Oh man! Because they are the exact same piece of text which means they are
the exact same piece of code. What you are looking for is not cucumber, we
do not want a step definition to change the glue code of another step
definition, by design.

Post by Behrad Sadoughian

Post by George Dinwiddie
I would suggest not using "John" for both participants. Also, I would
avoid pronouns such as "he" when there are multiple actors in a scenario.
It's easier to keep track if their names are explicitly specified.

*No, I didn't. This was an example.*

A poor example, but you are still not getting the concept behind the
advice: you are not defining the scenario actors appropriately, which is
causing problems in your stepdefs.

Post by Behrad Sadoughian
Nor would I generally suggest "And he logs in" as an explicit step. I

Post by George Dinwiddie
would assume that in most steps, and only explicitly state when someone is
NOT logged in. Perhaps in this case you're trying to illustrate an
asynchronous nature to the communication, where the second John is notified
after logging in. If that's the case, there might be a way to illustrate
that more explicitly.

*This is an example. The actual login steps are different.*

Another poor example and another try to ignore an advice: it's not about
the login process, it's about the fact you mentioned the login as a step.

Post by Behrad Sadoughian

Post by George Dinwiddie

Post by Behrad Sadoughian
Is this mess up? No it is not. My other example was not a mess up too.
It was just simplified to understand. What people tend to do here, it to
take examples very literal and assume other people are stupid.

I'm not assuming anyone is stupid. I am, however, suspecting that your
step definitions are more imperative than declarative. And I'm suspecting
that you're using the step definitions as a programming language rather
than extracting the programming part into a helper library.

*We write gherkins first and then add the support by programming. So it is
not like that. Please refer also to the points I and II above. *

Do you even read our advice? This is not about what you write first, it's
about how you write your scenarios: imperative means you are writing your
scenarios as if they were a programming language (Java, ObjectiveC, C++, C,
whatever imperative programming language you might know) while the purpose
of gherkin is to provide a declarative language to describe your system
characteristics.
Please, read carefully what we write then read it again and, in case you
doubt you have understood, read it a third time.

Post by Behrad Sadoughian

Post by George Dinwiddie
People who bring examples have to make them simple because otherwise I

Post by Behrad Sadoughian
should write 100 lines and you should read 100 lines, and I have to
reveal things I am not allowed to.

Oh, dear. If your scenarios are 100 lines long, you have bigger problems
than I suspected.

*That was an example!!! I wanted to say that that it would make the email
longer than you can read.*

Post by George Dinwiddie

Post by Behrad Sadoughian
Should I expect the next question be: "Lorem Ipsum" is not proper words
and should not be sent in chats!?

There are a number of people on this list trying to help you. I'm not
sure you're taking their advice to heart. Instead, it seems you're fixed on
the solution of changing the design of Cucumber rather than using it as
it's designed. Of course, if it's really "the best thing" for you, you can
fork it and implement that. I suspect it's only "the best thing" if someone
else does the work.

*I know but I feel people but we should differentiate between help and
mind reading. I am now forking in places but I think it is not the best
approach. *
*The same reason, caused Java Packages and C# name spaces be added was the
same reason I need this feature.*

Gherkin is not a programming language, nor is Cucumber-JVM. We are not
trying to mind read you, we are simply telling you you are misusing the
tool and spending our time to tell you how you can achieve a similar result
using the tool appropriately. Your only answer seems to be: "I don't care
what you say about this tool: I am right, you are wrong, help me achieve my
goal".

Post by Behrad Sadoughian

Post by George Dinwiddie
I realize that some of the communication issues are due to language, but
also your simplified scenarios do not communicate your issue well. Nor are
you being specific about what is the problem. I think there are solutions,
but so far, it's hard for me to tell exactly what you're trying to do.

*I think they do if you read them and look at them non-literally. Maybe I
am wrong.*

You are. On all the line.

Post by Behrad Sadoughian
You say that "glues conflict" but you're only showing steps. The step

Post by George Dinwiddie
definitions should call other code that performs the actual interaction
with the system.

*If steps definitions need to be unique, while your glue steps are not
unique, a glue conflict can happen.*

And it's reported as an error.

Post by Behrad Sadoughian

Post by George Dinwiddie
For example, a step definition for 'When "John" is using his Android with
version 4.2.1 of software installed' and 'When "John" is using his Android
with version 7.8.2 of software installed' should remember the platform and
version associated with a user name. Then when the same person (hence the
desire to use different names, and avoid pronouns) performs an action, the
step definition can call code appropriate for that platform and version. I
think I would model the platform and version as a class. An instance of
that class can be associated with John, and when John performs an action,
the method corresponding to that action can be called on that instance.

*This is the same forking solution that I am implementing. But when 99%
your steps are similar it is not easy to maintain forked generic glues with
dependency injection.*

Post by George Dinwiddie
Do remember that Cucumber is primarily a collaboration tool, and
secondarily a testing tool. Also remember that you will get more help with
inquiry than confrontation.

*I don't remember that and I don't think it is important at all. There are
many things in this world that their primary purpose was different. I would
definitely say:*
*- Gherkin/Cucumber is a test writing language*
*Unless you give me some statistics that shows more than 20% of people are
using it for some other purpose.*

Really? This list has to justify with you about the tool usage? You gotta
be kidding me!
The fact you or your one hundred friends use badly this tool doesn't mean
"it was intended" for something but you found the right way to use it, it
just means you and your one hundred friends are all wrong ;-)

BTW, In the last 4 years I've been working in 3 different companies, with
about 9 scrum teams, probably about 80 developers and one of the most
experienced and talented QA engineer I know (the one who showed me Gherkin
and Cucumber) and us all (including me) were all considering Cucumber a
testing tool: we were inexperienced and we didn't understand the tool
really.
After 3 weeks and some guidance we understood how much wrong we were and
felt really stupid.

If you are still there thinking this is a testing tool you haven't had
enough guidance: read more, think higher, write less code.

[George Dinwiddie]

Behrad,

Post by Behrad Sadoughian
Thanks. I really appreciate everybody's help here and I am sorry if what
I said caused anybody think otherwise.
I am gradually reaching the point that I am in the wrong group. My
question is more about Cucumber-JVM implementation while anybody who is
kind enough to help starts to find the methodological issues of the
gherkins I bring here as examples. These are not my real gherkins. Just
examples and I just noticed I wrongly used "John" twice. It should be
another user name as you stated.

I understand that, but it makes it hard to understand your real issues.

Post by Behrad Sadoughian
I) If gherkin is a originally and collaboration tool not a test case
writing language really doesn't matter. When 99% (my figure) of people
are using it for tests, it is a testing tool (De Facto).

No, that's not true. See
https://cukes.info/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool
And thinking of cucumber as a testing tool is a contributor to your
problems.

Post by Behrad Sadoughian
II) I wish people helped me to understand how my scenario can be

Listen to me. The gherkin is important, and relates to your problem as
far as I can tell.

Post by Behrad Sadoughian
I am testing the collaboration of different versions and presentation of
the same software. (iOS, Android, WebSite, ChromeApp, Windows). They do
the same thing and different users may use them at the same time. So for
example I need to be sure Windows-5.6.2.1 client can work with
Android-4.1.2.3. Like many other software, it needs concurrency, real
time collaboration etc scenarios.
I know how to write the gherkin. My gherkins are not 100 lines!!! I know
how to even implement this using dependency injection - or - adding a
suffix to all step definitions. That's what I am doing now. I found it
strange that the Cuke-JVM is trying to enforce and push a way of
development and came here to ask if there is any solution.

Your examples are showing a rudimentary understanding of how to write
gherkin, but you could do much better than that. How you write the
scenarios turns out to be quite important.

Post by Behrad Sadoughian
On Mon, Apr 13, 2015 at 3:12 PM, George Dinwiddie
Behrad,
I think this is a very common situation and needed by many people. It is
not a mess up. There are many scenarios that you need such features and
if you think a bit you will explore more.
Can you name an example of another person who needs this?
*I know two different teams (other than my company)*

OK, I know hundreds who do not. Perhaps I can help you and those two
teams solve your problems without a rewrite of Cucumber.

Post by Behrad Sadoughian
When "John" is using his Android with version 4.2.1 of software installed
And he logs in
And he sends a chat "Lorem Ipsum" to "John"
When "John" is using his Android with version 7.8.2 of software installed
when he logs in
Then he should receive "Lorem Ipsum" from "John"
Where is the issue here, from your point of view?
*How can the same "when he logs in" step call version 7.8.2 of the glue
and the other one the 4.2.1? I wanted the previous step "When John..."
dynamically change the glues as a solution.*

You don't want to switch on the choice of step definition. I explained
that below.

Post by Behrad Sadoughian
*
*
I would suggest not using "John" for both participants. Also, I
would avoid pronouns such as "he" when there are multiple actors in
a scenario. It's easier to keep track if their names are explicitly
specified.
*No, I didn't. This was an example.*
*
*
Nor would I generally suggest "And he logs in" as an explicit step.
I would assume that in most steps, and only explicitly state when
someone is NOT logged in. Perhaps in this case you're trying to
illustrate an asynchronous nature to the communication, where the
second John is notified after logging in. If that's the case, there
might be a way to illustrate that more explicitly.
*This is an example. The actual login steps are different.*

I'm suggesting that logging in is an incidental detail to the scenario.
Putting incidental steps into the scenario treats it as a programming
language rather than as a feature description.

Post by Behrad Sadoughian
Is this mess up? No it is not. My other example was not a mess up too.
It was just simplified to understand. What people tend to do here, it to
take examples very literal and assume other people are stupid.
I'm not assuming anyone is stupid. I am, however, suspecting that
your step definitions are more imperative than declarative. And I'm
suspecting that you're using the step definitions as a programming
language rather than extracting the programming part into a helper library.
*We write gherkins first and then add the support by programming. So it
is not like that. Please refer also to the points I and II above. *

If you do that, why do you end up with the same steps intending to mean
different things? Perhaps you're not collaborating enough, or not with
the right people.

Post by Behrad Sadoughian
People who bring examples have to make them simple because otherwise I
should write 100 lines and you should read 100 lines, and I have to
reveal things I am not allowed to.
Oh, dear. If your scenarios are 100 lines long, you have bigger
problems than I suspected.
*That was an example!!! I wanted to say that that it would make the
email longer than you can read.*

That might be better than shorter than is understandable. BDD is all
about having discussions so that everybody understands. Trying to
shortcut the process is not more efficient if it leads to misunderstanding.

You're right, though, that long emails can be poor vehicles for code. I
suggest creating a small GitHub project that shows your approach--one
that compiles and runs (even if it demonstrates an error). Put some care
into it, though, to make it representative of your real situation.

Post by Behrad Sadoughian
Should I expect the next question be: "Lorem Ipsum" is not proper words
and should not be sent in chats!?
There are a number of people on this list trying to help you. I'm
not sure you're taking their advice to heart. Instead, it seems
you're fixed on the solution of changing the design of Cucumber
rather than using it as it's designed. Of course, if it's really
"the best thing" for you, you can fork it and implement that. I
suspect it's only "the best thing" if someone else does the work.
*I know but I feel people but we should differentiate between help and
mind reading. I am now forking in places but I think it is not the best
approach. *
*The same reason, caused Java Packages and C# name spaces be added was
the same reason I need this feature.*

Cucumber is not a programming language. It's a collaboration tool.

Post by Behrad Sadoughian
I realize that some of the communication issues are due to language,
but also your simplified scenarios do not communicate your issue
well. Nor are you being specific about what is the problem. I think
there are solutions, but so far, it's hard for me to tell exactly
what you're trying to do.
*I think they do if you read them and look at them non-literally. Maybe
I am wrong.*

I cannot read your mind. If you cannot come up with representative
examples, I will misunderstand. People communicate better when they use
examples. That's the reason that Cucumber exists.

Post by Behrad Sadoughian
*
*
You say that "glues conflict" but you're only showing steps. The
step definitions should call other code that performs the actual
interaction with the system.
*If steps definitions need to be unique, while your glue steps are not
unique, a glue conflict can happen.*

I do not understand what you mean by that. What is a "glue conflict?"

Post by Behrad Sadoughian
For example, a step definition for 'When "John" is using his Android
with version 4.2.1 of software installed' and 'When "John" is using
his Android with version 7.8.2 of software installed' should
remember the platform and version associated with a user name. Then
when the same person (hence the desire to use different names, and
avoid pronouns) performs an action, the step definition can call
code appropriate for that platform and version. I think I would
model the platform and version as a class. An instance of that class
can be associated with John, and when John performs an action, the
method corresponding to that action can be called on that instance.
*This is the same forking solution that I am implementing. But when 99%
your steps are similar it is not easy to maintain forked generic glues
with dependency injection.*

I would not use dependency injection. I would use plain old java code.

Post by Behrad Sadoughian
Do remember that Cucumber is primarily a collaboration tool, and
secondarily a testing tool. Also remember that you will get more
help with inquiry than confrontation.
*I don't remember that and I don't think it is important at all. There
are many things in this world that their primary purpose was different.
I would definitely say:*
*
*
*- Gherkin/Cucumber is a test writing language*
*Unless you give me some statistics that shows more than 20% of people
are using it for some other purpose.*

You will be disappointed. As a friend once said, "You can use that
screwdriver to paint the wall if you want, but I don't think it will
work very well."

I think that you do not want my help. You already know all the answers,
and discount mine. The funny thing is that you are the one with
difficulties.

Good luck,
George

P.S. You have an odd way of showing appreciation.
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------