Is there a way to avoid duplicate Cucumber scenarios with different backgrounds?
up vote
1
down vote
favorite
We're starting to use cucumber (Java) and really liking it but Cucumber seems to completely fail at a very important case:
Basically I have a scenario that runs for a given logged in user, I need to literally run all the same tests with a different type of logged in user.
Then after that I need to run most of the exact same scenarios with a user logged in with a different role (multiple roles with overlapping authority)
This would be clean and trivial with a Background outline functionality, but that seems to have been denied years ago ( https://github.com/cucumber-attic/gherkin/issues/56)
I know this has been asked before but I keep turning up very old threads (some 6 years old!) with no answer other than "duplicate all your scenarios".
Duplicating hundreds of Scenarios is a failure on every front, it makes the test base unmanageable (a change in one scenario needs to propagate to multiple duplicates) . It fails in the core communication goal of cucumber as we get a huge bloat of feature files making it harder to know what the app is doing and what we're testing.
in the 6 years since the first complaints is there any reasonable way to manage this?
at this point I'm tempted to remove the background and move it into each scenario and use scenario outlines, it's ugly and the tests no longer read as cleanly but at least I don't need to duplicate scenarios.
java testing background cucumber
add a comment |
up vote
1
down vote
favorite
We're starting to use cucumber (Java) and really liking it but Cucumber seems to completely fail at a very important case:
Basically I have a scenario that runs for a given logged in user, I need to literally run all the same tests with a different type of logged in user.
Then after that I need to run most of the exact same scenarios with a user logged in with a different role (multiple roles with overlapping authority)
This would be clean and trivial with a Background outline functionality, but that seems to have been denied years ago ( https://github.com/cucumber-attic/gherkin/issues/56)
I know this has been asked before but I keep turning up very old threads (some 6 years old!) with no answer other than "duplicate all your scenarios".
Duplicating hundreds of Scenarios is a failure on every front, it makes the test base unmanageable (a change in one scenario needs to propagate to multiple duplicates) . It fails in the core communication goal of cucumber as we get a huge bloat of feature files making it harder to know what the app is doing and what we're testing.
in the 6 years since the first complaints is there any reasonable way to manage this?
at this point I'm tempted to remove the background and move it into each scenario and use scenario outlines, it's ugly and the tests no longer read as cleanly but at least I don't need to duplicate scenarios.
java testing background cucumber
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
We're starting to use cucumber (Java) and really liking it but Cucumber seems to completely fail at a very important case:
Basically I have a scenario that runs for a given logged in user, I need to literally run all the same tests with a different type of logged in user.
Then after that I need to run most of the exact same scenarios with a user logged in with a different role (multiple roles with overlapping authority)
This would be clean and trivial with a Background outline functionality, but that seems to have been denied years ago ( https://github.com/cucumber-attic/gherkin/issues/56)
I know this has been asked before but I keep turning up very old threads (some 6 years old!) with no answer other than "duplicate all your scenarios".
Duplicating hundreds of Scenarios is a failure on every front, it makes the test base unmanageable (a change in one scenario needs to propagate to multiple duplicates) . It fails in the core communication goal of cucumber as we get a huge bloat of feature files making it harder to know what the app is doing and what we're testing.
in the 6 years since the first complaints is there any reasonable way to manage this?
at this point I'm tempted to remove the background and move it into each scenario and use scenario outlines, it's ugly and the tests no longer read as cleanly but at least I don't need to duplicate scenarios.
java testing background cucumber
We're starting to use cucumber (Java) and really liking it but Cucumber seems to completely fail at a very important case:
Basically I have a scenario that runs for a given logged in user, I need to literally run all the same tests with a different type of logged in user.
Then after that I need to run most of the exact same scenarios with a user logged in with a different role (multiple roles with overlapping authority)
This would be clean and trivial with a Background outline functionality, but that seems to have been denied years ago ( https://github.com/cucumber-attic/gherkin/issues/56)
I know this has been asked before but I keep turning up very old threads (some 6 years old!) with no answer other than "duplicate all your scenarios".
Duplicating hundreds of Scenarios is a failure on every front, it makes the test base unmanageable (a change in one scenario needs to propagate to multiple duplicates) . It fails in the core communication goal of cucumber as we get a huge bloat of feature files making it harder to know what the app is doing and what we're testing.
in the 6 years since the first complaints is there any reasonable way to manage this?
at this point I'm tempted to remove the background and move it into each scenario and use scenario outlines, it's ugly and the tests no longer read as cleanly but at least I don't need to duplicate scenarios.
java testing background cucumber
java testing background cucumber
asked Nov 9 at 14:22
probablyAdog
61
61
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
Then after that I need to run most of the exact same scenarios with a user logged in with a different role (multiple roles with overlapping authority)
You want to test an authority but are instead testing roles. It seems to me that this is causing most of your problems. As roles are usually configured you may be able to leverage this system.
Given a customer service rep with the authority to grant refunds
And a customer reports a problems with the PX-11 Widget
When customer service resolves the problem by granting a refund
Then problem ticket is closed
And a refund request is lodged with finance
In the given step you create a new role for the customer service rep that can grant refunds.
If you have concerns that roles may affect each other in strange ways you should try to solve and test that at a lower level. It shouldn't be a concern that comes back in your acceptance tests.
If you are however unable to do so you may want to consider any of the three options below. It will keeps the gherkin readable at the cost of some added test complexity. But this complexity is indicative for a problematic system.
Creating multiple customer service reps with the requested authority in addition to the other authorities you are concerned about. Then in each follow up step you make all reps do the specific action.
For each test in addition to requested authority picking one or more authorities at random.
Pick a role with the required authority at random.
sorry, i don;t think you're getting the problem. basically i have 100 tests like this Background: Given we're logged into the application as an administrator Scenarios 1-100.. do stuff. IN one case i need Background: log in as a manager Scenarios 1-70 do stuff, (exact same scenarios steps) With background outline this would be easy, I can just use the same scenario with a different background. this seems impossible so i have to copy my scenario which creates lots of duplicate code which is not a tenable solution to testing. 80% duplicate test code is terrible
– probablyAdog
14 hours ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
Then after that I need to run most of the exact same scenarios with a user logged in with a different role (multiple roles with overlapping authority)
You want to test an authority but are instead testing roles. It seems to me that this is causing most of your problems. As roles are usually configured you may be able to leverage this system.
Given a customer service rep with the authority to grant refunds
And a customer reports a problems with the PX-11 Widget
When customer service resolves the problem by granting a refund
Then problem ticket is closed
And a refund request is lodged with finance
In the given step you create a new role for the customer service rep that can grant refunds.
If you have concerns that roles may affect each other in strange ways you should try to solve and test that at a lower level. It shouldn't be a concern that comes back in your acceptance tests.
If you are however unable to do so you may want to consider any of the three options below. It will keeps the gherkin readable at the cost of some added test complexity. But this complexity is indicative for a problematic system.
Creating multiple customer service reps with the requested authority in addition to the other authorities you are concerned about. Then in each follow up step you make all reps do the specific action.
For each test in addition to requested authority picking one or more authorities at random.
Pick a role with the required authority at random.
sorry, i don;t think you're getting the problem. basically i have 100 tests like this Background: Given we're logged into the application as an administrator Scenarios 1-100.. do stuff. IN one case i need Background: log in as a manager Scenarios 1-70 do stuff, (exact same scenarios steps) With background outline this would be easy, I can just use the same scenario with a different background. this seems impossible so i have to copy my scenario which creates lots of duplicate code which is not a tenable solution to testing. 80% duplicate test code is terrible
– probablyAdog
14 hours ago
add a comment |
up vote
1
down vote
Then after that I need to run most of the exact same scenarios with a user logged in with a different role (multiple roles with overlapping authority)
You want to test an authority but are instead testing roles. It seems to me that this is causing most of your problems. As roles are usually configured you may be able to leverage this system.
Given a customer service rep with the authority to grant refunds
And a customer reports a problems with the PX-11 Widget
When customer service resolves the problem by granting a refund
Then problem ticket is closed
And a refund request is lodged with finance
In the given step you create a new role for the customer service rep that can grant refunds.
If you have concerns that roles may affect each other in strange ways you should try to solve and test that at a lower level. It shouldn't be a concern that comes back in your acceptance tests.
If you are however unable to do so you may want to consider any of the three options below. It will keeps the gherkin readable at the cost of some added test complexity. But this complexity is indicative for a problematic system.
Creating multiple customer service reps with the requested authority in addition to the other authorities you are concerned about. Then in each follow up step you make all reps do the specific action.
For each test in addition to requested authority picking one or more authorities at random.
Pick a role with the required authority at random.
sorry, i don;t think you're getting the problem. basically i have 100 tests like this Background: Given we're logged into the application as an administrator Scenarios 1-100.. do stuff. IN one case i need Background: log in as a manager Scenarios 1-70 do stuff, (exact same scenarios steps) With background outline this would be easy, I can just use the same scenario with a different background. this seems impossible so i have to copy my scenario which creates lots of duplicate code which is not a tenable solution to testing. 80% duplicate test code is terrible
– probablyAdog
14 hours ago
add a comment |
up vote
1
down vote
up vote
1
down vote
Then after that I need to run most of the exact same scenarios with a user logged in with a different role (multiple roles with overlapping authority)
You want to test an authority but are instead testing roles. It seems to me that this is causing most of your problems. As roles are usually configured you may be able to leverage this system.
Given a customer service rep with the authority to grant refunds
And a customer reports a problems with the PX-11 Widget
When customer service resolves the problem by granting a refund
Then problem ticket is closed
And a refund request is lodged with finance
In the given step you create a new role for the customer service rep that can grant refunds.
If you have concerns that roles may affect each other in strange ways you should try to solve and test that at a lower level. It shouldn't be a concern that comes back in your acceptance tests.
If you are however unable to do so you may want to consider any of the three options below. It will keeps the gherkin readable at the cost of some added test complexity. But this complexity is indicative for a problematic system.
Creating multiple customer service reps with the requested authority in addition to the other authorities you are concerned about. Then in each follow up step you make all reps do the specific action.
For each test in addition to requested authority picking one or more authorities at random.
Pick a role with the required authority at random.
Then after that I need to run most of the exact same scenarios with a user logged in with a different role (multiple roles with overlapping authority)
You want to test an authority but are instead testing roles. It seems to me that this is causing most of your problems. As roles are usually configured you may be able to leverage this system.
Given a customer service rep with the authority to grant refunds
And a customer reports a problems with the PX-11 Widget
When customer service resolves the problem by granting a refund
Then problem ticket is closed
And a refund request is lodged with finance
In the given step you create a new role for the customer service rep that can grant refunds.
If you have concerns that roles may affect each other in strange ways you should try to solve and test that at a lower level. It shouldn't be a concern that comes back in your acceptance tests.
If you are however unable to do so you may want to consider any of the three options below. It will keeps the gherkin readable at the cost of some added test complexity. But this complexity is indicative for a problematic system.
Creating multiple customer service reps with the requested authority in addition to the other authorities you are concerned about. Then in each follow up step you make all reps do the specific action.
For each test in addition to requested authority picking one or more authorities at random.
Pick a role with the required authority at random.
answered Nov 10 at 10:31
mpkorstanje
1,7271729
1,7271729
sorry, i don;t think you're getting the problem. basically i have 100 tests like this Background: Given we're logged into the application as an administrator Scenarios 1-100.. do stuff. IN one case i need Background: log in as a manager Scenarios 1-70 do stuff, (exact same scenarios steps) With background outline this would be easy, I can just use the same scenario with a different background. this seems impossible so i have to copy my scenario which creates lots of duplicate code which is not a tenable solution to testing. 80% duplicate test code is terrible
– probablyAdog
14 hours ago
add a comment |
sorry, i don;t think you're getting the problem. basically i have 100 tests like this Background: Given we're logged into the application as an administrator Scenarios 1-100.. do stuff. IN one case i need Background: log in as a manager Scenarios 1-70 do stuff, (exact same scenarios steps) With background outline this would be easy, I can just use the same scenario with a different background. this seems impossible so i have to copy my scenario which creates lots of duplicate code which is not a tenable solution to testing. 80% duplicate test code is terrible
– probablyAdog
14 hours ago
sorry, i don;t think you're getting the problem. basically i have 100 tests like this Background: Given we're logged into the application as an administrator Scenarios 1-100.. do stuff. IN one case i need Background: log in as a manager Scenarios 1-70 do stuff, (exact same scenarios steps) With background outline this would be easy, I can just use the same scenario with a different background. this seems impossible so i have to copy my scenario which creates lots of duplicate code which is not a tenable solution to testing. 80% duplicate test code is terrible
– probablyAdog
14 hours ago
sorry, i don;t think you're getting the problem. basically i have 100 tests like this Background: Given we're logged into the application as an administrator Scenarios 1-100.. do stuff. IN one case i need Background: log in as a manager Scenarios 1-70 do stuff, (exact same scenarios steps) With background outline this would be easy, I can just use the same scenario with a different background. this seems impossible so i have to copy my scenario which creates lots of duplicate code which is not a tenable solution to testing. 80% duplicate test code is terrible
– probablyAdog
14 hours ago
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53227506%2fis-there-a-way-to-avoid-duplicate-cucumber-scenarios-with-different-backgrounds%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password