Discussion:
[Cucumber] Modular, simple steps or specific, complicated steps
(too old to reply)
c***@gmail.com
2018-01-12 14:15:18 UTC
Permalink
Sorry if anyone has asked a question but I did not see anything similar
when I searched. So I am relatively new to writing cucumber tests, I've
been doing so for about a year. I have worked on two different projects
writing feature files and step definitions. In the first project, I was
told to make the steps as large and inclusive as possible, as to avoid
extra steps. So for example I would have one step that says:

"Given the user is on the add account page"

and that step would involve navigating through 3 pages, selecting a value
from a dropdown, and then verifying that I was on the correct page. Such
steps save unnecessary feature steps, but they are not re-usable. In my
2nd project, there were only developers who were asked to do QA automation
development, and they had a different strategy. They broke every feature
file into steps that were modular and repeatable, but the features would
include many extra steps. So the first scenario I described above would be
broken down into something like

"the user is on the homepage,
the user clicks returning user,
the user selects add account from the user actions dropdown,
the user is on the add account page."

I was wondering what is generally considered the best practice between the
two, or what most QA developers do when writing their features and step
defs.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thomas Sundberg
2018-01-14 11:47:18 UTC
Permalink
Hi!

Your question is very valid.
Sorry if anyone has asked a question but I did not see anything similar when
I searched. So I am relatively new to writing cucumber tests, I've been
doing so for about a year. I have worked on two different projects writing
feature files and step definitions. In the first project, I was told to
make the steps as large and inclusive as possible, as to avoid extra steps.
"Given the user is on the add account page"
This is better abstraction level. But it can be improved.
and that step would involve navigating through 3 pages, selecting a value
from a dropdown, and then verifying that I was on the correct page. Such
steps save unnecessary feature steps, but they are not re-usable. In my 2nd
project, there were only developers who were asked to do QA automation
development, and they had a different strategy. They broke every feature
file into steps that were modular and repeatable, but the features would
include many extra steps. So the first scenario I described above would be
broken down into something like
"the user is on the homepage,
the user clicks returning user,
the user selects add account from the user actions dropdown,
the user is on the add account page."
This is not a good abstraction level and must be improved.
I was wondering what is generally considered the best practice between the
two, or what most QA developers do when writing their features and step
defs.
From my perspective, I don't really like any of your examples. They
are user interface specific. They don't really talk about why
something should happen, they talk about UI details and how something
is done. A change in the sign up flow will force you to rewrite the
steps.

Both cases it seems to be about signing up for a new account. Signing
up is the thing here. Not how it is done. If you would like to use
this step in a scenario where you verify that signing up is possible
to do before a web page is written, the steps above doesn't support
you.

I would probably write something similar to

Given that Ann want to sign up for a new account

In this case, we don't care how Ann does in order to get a new
account. But we know a few things. We have a person, Ann, who has some
properties such as age, e-mail and so forth. These details must not be
shown in the scenario but may be important when creating a new
account.

This step can be used to drive out the model supporting the sign up.
It can also be used to drive Selenium and navigate a web application
that finally will create an account.

Being more abstract, and less UI centric, will simplify maintenance.
It will also allow you to discuss the feature with business persons.
Business persons usually don't care too much about the web
application, they care about the fact that Ann should be able to sign
up.

Given your two examples, the first one is slightly better. But none of
them are very good if you want to discuss the sign up behaviour with
non technical persons.

Sorry if I'm being hard on you. That's not my goal. My goal is to help
you understand that UI stuff should not be part of the steps.

Cheers,
Thomas
--
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.
--
Thomas Sundberg
M. Sc. in Computer Science

Mobile: +46 70 767 33 15
Blog: http://www.thinkcode.se/blog
Twitter: @thomassundberg

Better software through faster feedback
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
c***@gmail.com
2018-01-15 13:20:41 UTC
Permalink
No thank you very much, I don't think you were hard on me at all. I
appreciate your insight; I am still new to QA development and I want to
learn how to do it properly. Your response was very helpful.
Post by Thomas Sundberg
Hi!
Your question is very valid.
Post by c***@gmail.com
Sorry if anyone has asked a question but I did not see anything similar
when
Post by c***@gmail.com
I searched. So I am relatively new to writing cucumber tests, I've been
doing so for about a year. I have worked on two different projects
writing
Post by c***@gmail.com
feature files and step definitions. In the first project, I was told to
make the steps as large and inclusive as possible, as to avoid extra
steps.
Post by c***@gmail.com
"Given the user is on the add account page"
This is better abstraction level. But it can be improved.
Post by c***@gmail.com
and that step would involve navigating through 3 pages, selecting a
value
Post by c***@gmail.com
from a dropdown, and then verifying that I was on the correct page.
Such
Post by c***@gmail.com
steps save unnecessary feature steps, but they are not re-usable. In my
2nd
Post by c***@gmail.com
project, there were only developers who were asked to do QA automation
development, and they had a different strategy. They broke every
feature
Post by c***@gmail.com
file into steps that were modular and repeatable, but the features would
include many extra steps. So the first scenario I described above would
be
Post by c***@gmail.com
broken down into something like
"the user is on the homepage,
the user clicks returning user,
the user selects add account from the user actions dropdown,
the user is on the add account page."
This is not a good abstraction level and must be improved.
Post by c***@gmail.com
I was wondering what is generally considered the best practice between
the
Post by c***@gmail.com
two, or what most QA developers do when writing their features and step
defs.
From my perspective, I don't really like any of your examples. They
are user interface specific. They don't really talk about why
something should happen, they talk about UI details and how something
is done. A change in the sign up flow will force you to rewrite the
steps.
Both cases it seems to be about signing up for a new account. Signing
up is the thing here. Not how it is done. If you would like to use
this step in a scenario where you verify that signing up is possible
to do before a web page is written, the steps above doesn't support
you.
I would probably write something similar to
Given that Ann want to sign up for a new account
In this case, we don't care how Ann does in order to get a new
account. But we know a few things. We have a person, Ann, who has some
properties such as age, e-mail and so forth. These details must not be
shown in the scenario but may be important when creating a new
account.
This step can be used to drive out the model supporting the sign up.
It can also be used to drive Selenium and navigate a web application
that finally will create an account.
Being more abstract, and less UI centric, will simplify maintenance.
It will also allow you to discuss the feature with business persons.
Business persons usually don't care too much about the web
application, they care about the fact that Ann should be able to sign
up.
Given your two examples, the first one is slightly better. But none of
them are very good if you want to discuss the sign up behaviour with
non technical persons.
Sorry if I'm being hard on you. That's not my goal. My goal is to help
you understand that UI stuff should not be part of the steps.
Cheers,
Thomas
Post by c***@gmail.com
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google
Groups
Post by c***@gmail.com
"Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send
an
Post by c***@gmail.com
For more options, visit https://groups.google.com/d/optout.
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15
Blog: http://www.thinkcode.se/blog
Better software through faster feedback
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
c***@gmail.com
2018-01-15 13:28:44 UTC
Permalink
So really if the sign in process is not something I am testing , I probably
do not need to include it in any test. I can just start from a point where
the user is already signed in and include the sign in steps as part of the
before method, or maybe create a generic sign in method in my generic page
object and re-use the steps from there.
Post by Thomas Sundberg
Hi!
Your question is very valid.
Post by c***@gmail.com
Sorry if anyone has asked a question but I did not see anything similar
when
Post by c***@gmail.com
I searched. So I am relatively new to writing cucumber tests, I've been
doing so for about a year. I have worked on two different projects
writing
Post by c***@gmail.com
feature files and step definitions. In the first project, I was told to
make the steps as large and inclusive as possible, as to avoid extra
steps.
Post by c***@gmail.com
"Given the user is on the add account page"
This is better abstraction level. But it can be improved.
Post by c***@gmail.com
and that step would involve navigating through 3 pages, selecting a
value
Post by c***@gmail.com
from a dropdown, and then verifying that I was on the correct page.
Such
Post by c***@gmail.com
steps save unnecessary feature steps, but they are not re-usable. In my
2nd
Post by c***@gmail.com
project, there were only developers who were asked to do QA automation
development, and they had a different strategy. They broke every
feature
Post by c***@gmail.com
file into steps that were modular and repeatable, but the features would
include many extra steps. So the first scenario I described above would
be
Post by c***@gmail.com
broken down into something like
"the user is on the homepage,
the user clicks returning user,
the user selects add account from the user actions dropdown,
the user is on the add account page."
This is not a good abstraction level and must be improved.
Post by c***@gmail.com
I was wondering what is generally considered the best practice between
the
Post by c***@gmail.com
two, or what most QA developers do when writing their features and step
defs.
From my perspective, I don't really like any of your examples. They
are user interface specific. They don't really talk about why
something should happen, they talk about UI details and how something
is done. A change in the sign up flow will force you to rewrite the
steps.
Both cases it seems to be about signing up for a new account. Signing
up is the thing here. Not how it is done. If you would like to use
this step in a scenario where you verify that signing up is possible
to do before a web page is written, the steps above doesn't support
you.
I would probably write something similar to
Given that Ann want to sign up for a new account
In this case, we don't care how Ann does in order to get a new
account. But we know a few things. We have a person, Ann, who has some
properties such as age, e-mail and so forth. These details must not be
shown in the scenario but may be important when creating a new
account.
This step can be used to drive out the model supporting the sign up.
It can also be used to drive Selenium and navigate a web application
that finally will create an account.
Being more abstract, and less UI centric, will simplify maintenance.
It will also allow you to discuss the feature with business persons.
Business persons usually don't care too much about the web
application, they care about the fact that Ann should be able to sign
up.
Given your two examples, the first one is slightly better. But none of
them are very good if you want to discuss the sign up behaviour with
non technical persons.
Sorry if I'm being hard on you. That's not my goal. My goal is to help
you understand that UI stuff should not be part of the steps.
Cheers,
Thomas
Post by c***@gmail.com
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google
Groups
Post by c***@gmail.com
"Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send
an
Post by c***@gmail.com
For more options, visit https://groups.google.com/d/optout.
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15
Blog: http://www.thinkcode.se/blog
Better software through faster feedback
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Koen Prins
2018-01-15 13:31:54 UTC
Permalink
I use hooks for this, there is always some stuff that needs to be done
every time that I want to call out so there is no confusion about what the
test is doing.
https://github.com/cucumber/cucumber/wiki/Hooks

Background is one of my favorites, it saved me a ton of repetition.
Post by c***@gmail.com
So really if the sign in process is not something I am testing , I
probably do not need to include it in any test. I can just start from a
point where the user is already signed in and include the sign in steps as
part of the before method, or maybe create a generic sign in method in my
generic page object and re-use the steps from there.
Post by Thomas Sundberg
Hi!
Your question is very valid.
Post by c***@gmail.com
Sorry if anyone has asked a question but I did not see anything similar
when
Post by c***@gmail.com
I searched. So I am relatively new to writing cucumber tests, I've
been
Post by c***@gmail.com
doing so for about a year. I have worked on two different projects
writing
Post by c***@gmail.com
feature files and step definitions. In the first project, I was told
to
Post by c***@gmail.com
make the steps as large and inclusive as possible, as to avoid extra
steps.
Post by c***@gmail.com
"Given the user is on the add account page"
This is better abstraction level. But it can be improved.
Post by c***@gmail.com
and that step would involve navigating through 3 pages, selecting a
value
Post by c***@gmail.com
from a dropdown, and then verifying that I was on the correct page.
Such
Post by c***@gmail.com
steps save unnecessary feature steps, but they are not re-usable. In
my 2nd
Post by c***@gmail.com
project, there were only developers who were asked to do QA automation
development, and they had a different strategy. They broke every
feature
Post by c***@gmail.com
file into steps that were modular and repeatable, but the features
would
Post by c***@gmail.com
include many extra steps. So the first scenario I described above
would be
Post by c***@gmail.com
broken down into something like
"the user is on the homepage,
the user clicks returning user,
the user selects add account from the user actions dropdown,
the user is on the add account page."
This is not a good abstraction level and must be improved.
Post by c***@gmail.com
I was wondering what is generally considered the best practice between
the
Post by c***@gmail.com
two, or what most QA developers do when writing their features and step
defs.
From my perspective, I don't really like any of your examples. They
are user interface specific. They don't really talk about why
something should happen, they talk about UI details and how something
is done. A change in the sign up flow will force you to rewrite the
steps.
Both cases it seems to be about signing up for a new account. Signing
up is the thing here. Not how it is done. If you would like to use
this step in a scenario where you verify that signing up is possible
to do before a web page is written, the steps above doesn't support
you.
I would probably write something similar to
Given that Ann want to sign up for a new account
In this case, we don't care how Ann does in order to get a new
account. But we know a few things. We have a person, Ann, who has some
properties such as age, e-mail and so forth. These details must not be
shown in the scenario but may be important when creating a new
account.
This step can be used to drive out the model supporting the sign up.
It can also be used to drive Selenium and navigate a web application
that finally will create an account.
Being more abstract, and less UI centric, will simplify maintenance.
It will also allow you to discuss the feature with business persons.
Business persons usually don't care too much about the web
application, they care about the fact that Ann should be able to sign
up.
Given your two examples, the first one is slightly better. But none of
them are very good if you want to discuss the sign up behaviour with
non technical persons.
Sorry if I'm being hard on you. That's not my goal. My goal is to help
you understand that UI stuff should not be part of the steps.
Cheers,
Thomas
Post by c***@gmail.com
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google
Groups
Post by c***@gmail.com
"Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send
an
Post by c***@gmail.com
For more options, visit https://groups.google.com/d/optout.
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15 <+46%2070%20767%2033%2015>
Blog: http://www.thinkcode.se/blog
Better software through faster feedback
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thomas Sundberg
2018-01-15 13:32:18 UTC
Permalink
Post by c***@gmail.com
So really if the sign in process is not something I am testing , I probably
do not need to include it in any test. I can just start from a point where
the user is already signed in and include the sign in steps as part of the
before method, or maybe create a generic sign in method in my generic page
object and re-use the steps from there.
This is an approach I would use. I would create a helper, a page
object or similar, that solves this irrelevant detail for me so I can
focus on the relevant details for this example/test.

It is hard to keep focus so hiding, currently unimportant, things
makes it easier for me.

Good luck!
Thomas
Post by c***@gmail.com
Post by Thomas Sundberg
Hi!
Your question is very valid.
Sorry if anyone has asked a question but I did not see anything similar when
I searched. So I am relatively new to writing cucumber tests, I've been
doing so for about a year. I have worked on two different projects writing
feature files and step definitions. In the first project, I was told to
make the steps as large and inclusive as possible, as to avoid extra steps.
"Given the user is on the add account page"
This is better abstraction level. But it can be improved.
and that step would involve navigating through 3 pages, selecting a value
from a dropdown, and then verifying that I was on the correct page.
Such
steps save unnecessary feature steps, but they are not re-usable. In my 2nd
project, there were only developers who were asked to do QA automation
development, and they had a different strategy. They broke every feature
file into steps that were modular and repeatable, but the features would
include many extra steps. So the first scenario I described above would be
broken down into something like
"the user is on the homepage,
the user clicks returning user,
the user selects add account from the user actions dropdown,
the user is on the add account page."
This is not a good abstraction level and must be improved.
I was wondering what is generally considered the best practice between the
two, or what most QA developers do when writing their features and step
defs.
From my perspective, I don't really like any of your examples. They
are user interface specific. They don't really talk about why
something should happen, they talk about UI details and how something
is done. A change in the sign up flow will force you to rewrite the
steps.
Both cases it seems to be about signing up for a new account. Signing
up is the thing here. Not how it is done. If you would like to use
this step in a scenario where you verify that signing up is possible
to do before a web page is written, the steps above doesn't support
you.
I would probably write something similar to
Given that Ann want to sign up for a new account
In this case, we don't care how Ann does in order to get a new
account. But we know a few things. We have a person, Ann, who has some
properties such as age, e-mail and so forth. These details must not be
shown in the scenario but may be important when creating a new
account.
This step can be used to drive out the model supporting the sign up.
It can also be used to drive Selenium and navigate a web application
that finally will create an account.
Being more abstract, and less UI centric, will simplify maintenance.
It will also allow you to discuss the feature with business persons.
Business persons usually don't care too much about the web
application, they care about the fact that Ann should be able to sign
up.
Given your two examples, the first one is slightly better. But none of
them are very good if you want to discuss the sign up behaviour with
non technical persons.
Sorry if I'm being hard on you. That's not my goal. My goal is to help
you understand that UI stuff should not be part of the steps.
Cheers,
Thomas
--
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.
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15
Blog: http://www.thinkcode.se/blog
Better software through faster feedback
--
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.
--
Thomas Sundberg
M. Sc. in Computer Science

Mobile: +46 70 767 33 15
Blog: http://www.thinkcode.se/blog
Twitter: @thomassundberg

Better software through faster feedback
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
c***@gmail.com
2018-01-15 14:02:54 UTC
Permalink
I'm going to pick your brain a little more if you don't mind. So the
application I am testing right now involves a lot of different pages and
navigation steps. One happy path test case touches on average about 8-12
pages. How should I handle the navigation between pages? From what you
said earlier, I would not mention the pages or navigation at all in my step
definitions, but just the functionality that happens on each page.
Post by Thomas Sundberg
Post by c***@gmail.com
So really if the sign in process is not something I am testing , I
probably
Post by c***@gmail.com
do not need to include it in any test. I can just start from a point
where
Post by c***@gmail.com
the user is already signed in and include the sign in steps as part of
the
Post by c***@gmail.com
before method, or maybe create a generic sign in method in my generic
page
Post by c***@gmail.com
object and re-use the steps from there.
This is an approach I would use. I would create a helper, a page
object or similar, that solves this irrelevant detail for me so I can
focus on the relevant details for this example/test.
It is hard to keep focus so hiding, currently unimportant, things
makes it easier for me.
Good luck!
Thomas
Post by c***@gmail.com
Post by Thomas Sundberg
Hi!
Your question is very valid.
Post by c***@gmail.com
Sorry if anyone has asked a question but I did not see anything
similar
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
when
I searched. So I am relatively new to writing cucumber tests, I've
been
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
doing so for about a year. I have worked on two different projects writing
feature files and step definitions. In the first project, I was told
to
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
make the steps as large and inclusive as possible, as to avoid extra steps.
"Given the user is on the add account page"
This is better abstraction level. But it can be improved.
Post by c***@gmail.com
and that step would involve navigating through 3 pages, selecting a value
from a dropdown, and then verifying that I was on the correct page.
Such
steps save unnecessary feature steps, but they are not re-usable. In
my
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
2nd
project, there were only developers who were asked to do QA
automation
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
development, and they had a different strategy. They broke every feature
file into steps that were modular and repeatable, but the features
would
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
include many extra steps. So the first scenario I described above
would
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
be
broken down into something like
"the user is on the homepage,
the user clicks returning user,
the user selects add account from the user actions dropdown,
the user is on the add account page."
This is not a good abstraction level and must be improved.
Post by c***@gmail.com
I was wondering what is generally considered the best practice
between
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
the
two, or what most QA developers do when writing their features and
step
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
defs.
From my perspective, I don't really like any of your examples. They
are user interface specific. They don't really talk about why
something should happen, they talk about UI details and how something
is done. A change in the sign up flow will force you to rewrite the
steps.
Both cases it seems to be about signing up for a new account. Signing
up is the thing here. Not how it is done. If you would like to use
this step in a scenario where you verify that signing up is possible
to do before a web page is written, the steps above doesn't support
you.
I would probably write something similar to
Given that Ann want to sign up for a new account
In this case, we don't care how Ann does in order to get a new
account. But we know a few things. We have a person, Ann, who has some
properties such as age, e-mail and so forth. These details must not be
shown in the scenario but may be important when creating a new
account.
This step can be used to drive out the model supporting the sign up.
It can also be used to drive Selenium and navigate a web application
that finally will create an account.
Being more abstract, and less UI centric, will simplify maintenance.
It will also allow you to discuss the feature with business persons.
Business persons usually don't care too much about the web
application, they care about the fact that Ann should be able to sign
up.
Given your two examples, the first one is slightly better. But none of
them are very good if you want to discuss the sign up behaviour with
non technical persons.
Sorry if I'm being hard on you. That's not my goal. My goal is to help
you understand that UI stuff should not be part of the steps.
Cheers,
Thomas
Post by c***@gmail.com
--
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
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
an
For more options, visit https://groups.google.com/d/optout.
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15
Blog: http://www.thinkcode.se/blog
Better software through faster feedback
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google
Groups
Post by c***@gmail.com
"Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send
an
Post by c***@gmail.com
For more options, visit https://groups.google.com/d/optout.
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15
Blog: http://www.thinkcode.se/blog
Better software through faster feedback
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andrew Premdas
2018-01-15 22:27:14 UTC
Permalink
Post by c***@gmail.com
I'm going to pick your brain a little more if you don't mind. So the
application I am testing right now involves a lot of different pages and
navigation steps. One happy path test case touches on average about 8-12
pages. How should I handle the navigation between pages? From what you
said earlier, I would not mention the pages or navigation at all in my step
definitions, but just the functionality that happens on each page.
With web applications I find there are three sorts of tests I want to
write. The first is to do something e.g.

view a product
add a product to a basket
register
sign in

These things can be generalized into a single web request to a resource.
When you develop these things you can have a single When that deals with
the user interaction that exercises the behaviour

When I view a product (a GET to product:id)
When I add the product to a basket (a POST of the product id)
When I register (a post of details to the registration resource)
...

After you have implemented a very simple scenario that interacts with the
UI to do this you can then write an equivalent Given e.g.

Given I am registered
Given I am viewing a product
...

and you can optimize Givens to bypass the UI by either

1. Writing stuff directly to the database, e.g. using a factory (not so
good)
2. Calling the service that the UI interaction calls directly with an
appropriate set of params (better)

This takes time, but has big benefits as you will use these Givens, or
their particular helper methods a great deal.

The second sort of test is basically a compound operation of the first type
of tests for example if I am going to the checkout with a basket full of
products I will have to have added lots of products to my basket. What I do
here is combine several of the optimized Givens from the first type of
tests, but I do this by using the helper methods, not calling the steps
directly. This approach allows me to write things like

Given I have several products in my basket
When I go to the checkout
Then I should be asked for my payment details

and to implement Given I have several products in my basket with really
simple code like

Given 'I have several products in my basket' do
several.times do
add_product_to_basket create_product # use existing helper methods to
make this a simple call
end
end

The third set of tests, which are relatively minor if you do BDD and focus
on behavior first) and are about navigating from place to place, and
seeing what is on the page. These tend to churn quite a bit on projects I
work on, as behavior is often moved around as we learn more about our
domain and get feedback about our application. If you wait until you have
the first two sorts of tests you'll find these should be quite easy to
write (though expensive to run) as you have already got the tools to build
all the stuff you need to have something meaningful to navigate around. If
you find these tests really hard to write this may indicate you need more
of the other tests before you continue.

Hope this makes sense and is of some use

All best

Andrew
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
So really if the sign in process is not something I am testing , I
probably
Post by c***@gmail.com
do not need to include it in any test. I can just start from a point
where
Post by c***@gmail.com
the user is already signed in and include the sign in steps as part of
the
Post by c***@gmail.com
before method, or maybe create a generic sign in method in my generic
page
Post by c***@gmail.com
object and re-use the steps from there.
This is an approach I would use. I would create a helper, a page
object or similar, that solves this irrelevant detail for me so I can
focus on the relevant details for this example/test.
It is hard to keep focus so hiding, currently unimportant, things
makes it easier for me.
Good luck!
Thomas
Post by c***@gmail.com
Post by Thomas Sundberg
Hi!
Your question is very valid.
Post by c***@gmail.com
Sorry if anyone has asked a question but I did not see anything
similar
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
when
I searched. So I am relatively new to writing cucumber tests, I've
been
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
doing so for about a year. I have worked on two different projects writing
feature files and step definitions. In the first project, I was
told to
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
make the steps as large and inclusive as possible, as to avoid extra steps.
"Given the user is on the add account page"
This is better abstraction level. But it can be improved.
Post by c***@gmail.com
and that step would involve navigating through 3 pages, selecting a value
from a dropdown, and then verifying that I was on the correct page.
Such
steps save unnecessary feature steps, but they are not re-usable.
In my
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
2nd
project, there were only developers who were asked to do QA
automation
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
development, and they had a different strategy. They broke every feature
file into steps that were modular and repeatable, but the features
would
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
include many extra steps. So the first scenario I described above
would
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
be
broken down into something like
"the user is on the homepage,
the user clicks returning user,
the user selects add account from the user actions dropdown,
the user is on the add account page."
This is not a good abstraction level and must be improved.
Post by c***@gmail.com
I was wondering what is generally considered the best practice
between
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
the
two, or what most QA developers do when writing their features and
step
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
defs.
From my perspective, I don't really like any of your examples. They
are user interface specific. They don't really talk about why
something should happen, they talk about UI details and how something
is done. A change in the sign up flow will force you to rewrite the
steps.
Both cases it seems to be about signing up for a new account. Signing
up is the thing here. Not how it is done. If you would like to use
this step in a scenario where you verify that signing up is possible
to do before a web page is written, the steps above doesn't support
you.
I would probably write something similar to
Given that Ann want to sign up for a new account
In this case, we don't care how Ann does in order to get a new
account. But we know a few things. We have a person, Ann, who has some
properties such as age, e-mail and so forth. These details must not be
shown in the scenario but may be important when creating a new
account.
This step can be used to drive out the model supporting the sign up.
It can also be used to drive Selenium and navigate a web application
that finally will create an account.
Being more abstract, and less UI centric, will simplify maintenance.
It will also allow you to discuss the feature with business persons.
Business persons usually don't care too much about the web
application, they care about the fact that Ann should be able to sign
up.
Given your two examples, the first one is slightly better. But none of
them are very good if you want to discuss the sign up behaviour with
non technical persons.
Sorry if I'm being hard on you. That's not my goal. My goal is to help
you understand that UI stuff should not be part of the steps.
Cheers,
Thomas
Post by c***@gmail.com
--
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
Post by c***@gmail.com
Post by Thomas Sundberg
Post by c***@gmail.com
an
For more options, visit https://groups.google.com/d/optout.
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15
Blog: http://www.thinkcode.se/blog
Better software through faster feedback
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google
Groups
Post by c***@gmail.com
"Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send
an
Post by c***@gmail.com
For more options, visit https://groups.google.com/d/optout.
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15
Blog: http://www.thinkcode.se/blog
Better software through faster feedback
--
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 the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andrew Premdas
2018-01-15 15:36:28 UTC
Permalink
The best approach is to have context specific steps that are simple calls,
even if that call may have to do alot of things. However the steps should
only do what they say they do, Lets use your first example to examine this

Given "the user is on the account page" do
visit account_page_path
end

This step should only do the navigation. I would precede this with
something like

'Given the user is logged in', which I would probably put in a background
and I might implement this as

Given 'the user is logged in' do
sign_in user: create_new_user
end

and the helper method create_new_user would register the user and do
whatever it takes to have a new user and the sign_in helper would visit the
login page and fill in the users name and password.

There are two ideas here that are helpful to deal with all this complexity

1) Delegate doing the work to helper methods that live outside step
definitions
2) Break the work into named simple chunks that we can combine and reuse to
do things.

By taking these two problems out of step definitions and into helper code
you can allow step definitions to simply do their main task which is to
translate a language call ('Given the user is logged in') into a helper
call ( sign_in user: create_new_user ).

Now your problem of managing the complexity of doing lots of things with a
single call is just standard programming and code organization in whatever
programming language you are using

Hope this makes sense

All best

Andrew
Post by c***@gmail.com
Sorry if anyone has asked a question but I did not see anything similar
when I searched. So I am relatively new to writing cucumber tests, I've
been doing so for about a year. I have worked on two different projects
writing feature files and step definitions. In the first project, I was
told to make the steps as large and inclusive as possible, as to avoid
"Given the user is on the add account page"
and that step would involve navigating through 3 pages, selecting a value
from a dropdown, and then verifying that I was on the correct page. Such
steps save unnecessary feature steps, but they are not re-usable. In my
2nd project, there were only developers who were asked to do QA automation
development, and they had a different strategy. They broke every feature
file into steps that were modular and repeatable, but the features would
include many extra steps. So the first scenario I described above would be
broken down into something like
"the user is on the homepage,
the user clicks returning user,
the user selects add account from the user actions dropdown,
the user is on the add account page."
I was wondering what is generally considered the best practice between the
two, or what most QA developers do when writing their features and step
defs.
--
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 the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
c***@gmail.com
2018-01-15 15:42:12 UTC
Permalink
In general, would you consider it bad practice to have steps that can only
be used in place?
Post by Andrew Premdas
The best approach is to have context specific steps that are simple calls,
even if that call may have to do alot of things. However the steps should
only do what they say they do, Lets use your first example to examine this
Given "the user is on the account page" do
visit account_page_path
end
This step should only do the navigation. I would precede this with
something like
'Given the user is logged in', which I would probably put in a background
and I might implement this as
Given 'the user is logged in' do
sign_in user: create_new_user
end
and the helper method create_new_user would register the user and do
whatever it takes to have a new user and the sign_in helper would visit the
login page and fill in the users name and password.
There are two ideas here that are helpful to deal with all this complexity
1) Delegate doing the work to helper methods that live outside step
definitions
2) Break the work into named simple chunks that we can combine and reuse
to do things.
By taking these two problems out of step definitions and into helper code
you can allow step definitions to simply do their main task which is to
translate a language call ('Given the user is logged in') into a helper
call ( sign_in user: create_new_user ).
Now your problem of managing the complexity of doing lots of things with a
single call is just standard programming and code organization in whatever
programming language you are using
Hope this makes sense
All best
Andrew
Post by c***@gmail.com
Sorry if anyone has asked a question but I did not see anything similar
when I searched. So I am relatively new to writing cucumber tests, I've
been doing so for about a year. I have worked on two different projects
writing feature files and step definitions. In the first project, I was
told to make the steps as large and inclusive as possible, as to avoid
"Given the user is on the add account page"
and that step would involve navigating through 3 pages, selecting a value
from a dropdown, and then verifying that I was on the correct page. Such
steps save unnecessary feature steps, but they are not re-usable. In my
2nd project, there were only developers who were asked to do QA automation
development, and they had a different strategy. They broke every feature
file into steps that were modular and repeatable, but the features would
include many extra steps. So the first scenario I described above would be
broken down into something like
"the user is on the homepage,
the user clicks returning user,
the user selects add account from the user actions dropdown,
the user is on the add account page."
I was wondering what is generally considered the best practice between
the two, or what most QA developers do when writing their features and step
defs.
--
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 the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andrew Premdas
2018-01-15 21:57:24 UTC
Permalink
Post by c***@gmail.com
In general, would you consider it bad practice to have steps that can only
be used in place?
Absolutely not. Nor would I consider it bad practice to have several steps
that do exactly the same thing, so long as they make the same call. I'd
strongly recommend

Given 'Joe has signed in" do
sign_in user: @joe
end

When 'Joe signs in" do
sign_in user: @joe
end

and would be quite happy to extend that with

Given 'Frank has signed in" do
sign_in user: @frank
end

although here I would probably start refactoring on the 3rd or fourth
method i.e. if I add @jane and @june.

For me step definitions are only about translating natural language calls
into method calls. Every time they do more than this you eventually end up
in a mess. If they only translate and make calls then you can have several
step definitions that make the same call with very little penalty. It also
means that generally you can keep steps super simple and avoid regex's and
parameters alot of the time.
Post by c***@gmail.com
Post by Andrew Premdas
The best approach is to have context specific steps that are simple
calls, even if that call may have to do alot of things. However the steps
should only do what they say they do, Lets use your first example to
examine this
Given "the user is on the account page" do
visit account_page_path
end
This step should only do the navigation. I would precede this with
something like
'Given the user is logged in', which I would probably put in a background
and I might implement this as
Given 'the user is logged in' do
sign_in user: create_new_user
end
and the helper method create_new_user would register the user and do
whatever it takes to have a new user and the sign_in helper would visit the
login page and fill in the users name and password.
There are two ideas here that are helpful to deal with all this complexity
1) Delegate doing the work to helper methods that live outside step
definitions
2) Break the work into named simple chunks that we can combine and reuse
to do things.
By taking these two problems out of step definitions and into helper code
you can allow step definitions to simply do their main task which is to
translate a language call ('Given the user is logged in') into a helper
call ( sign_in user: create_new_user ).
Now your problem of managing the complexity of doing lots of things with
a single call is just standard programming and code organization in
whatever programming language you are using
Hope this makes sense
All best
Andrew
Post by c***@gmail.com
Sorry if anyone has asked a question but I did not see anything similar
when I searched. So I am relatively new to writing cucumber tests, I've
been doing so for about a year. I have worked on two different projects
writing feature files and step definitions. In the first project, I was
told to make the steps as large and inclusive as possible, as to avoid
"Given the user is on the add account page"
and that step would involve navigating through 3 pages, selecting a
value from a dropdown, and then verifying that I was on the correct page.
Such steps save unnecessary feature steps, but they are not re-usable. In
my 2nd project, there were only developers who were asked to do QA
automation development, and they had a different strategy. They broke
every feature file into steps that were modular and repeatable, but the
features would include many extra steps. So the first scenario I described
above would be broken down into something like
"the user is on the homepage,
the user clicks returning user,
the user selects add account from the user actions dropdown,
the user is on the add account page."
I was wondering what is generally considered the best practice between
the two, or what most QA developers do when writing their features and step
defs.
--
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 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 the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
John Maxwell
2018-01-15 15:42:48 UTC
Permalink
Post by c***@gmail.com
Post by c***@gmail.com
So really if the sign in process is not something I am testing , I
probably do not need to include it in any test. I can just start
from a
Post by c***@gmail.com
point where the user is already signed in and include the sign in
steps as
Post by c***@gmail.com
part of the before method, or maybe create a generic sign in method
in my
Post by c***@gmail.com
generic page object and re-use the steps from there.
There may be value in testing the sign-in process. *Once*, in one test.
Or, if there is non-trivial logic involved (multiple failure conditions,
or perhaps changing the UI based on cookies found, etc.), in a few
tests.

UI tests are not worthless.

But those test should be of the form "when the user exercises the
sign-on page in thus-and-such a manor, they are/are not signed in", and
that's all.

The problem with your initial scenario was including that as part of
(nearly) every other test.

-John

--
John Maxwell KB3VLL ***@jmaxhome.com

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