[Cucumber] Eliminating duplicated scenarios.

[Gheeno San Pascual III]

I am trying to eliminate duplicated scenarios.

What my end goal is - feedback. Is this the right way to do it? Do you consider this as code duplication? How would you simplify this feature file without compromising Parallel execution?

Setup :

1. The TestRunners has parallel mode enabled, 3 FailSafe test runners exists per Environment.

2. All 3 Environments are being targetted and tested at the same time.

3. All 3 Environments might have different user login and PageObjects

Goals :

1. Have ClueCumber reports still be meaningful where you can differentiate the 3 environments.

2. Retain parallel execution capability.

Example : 

@smoke1
Scenario Outline: Login into page [ENV1]
  Given User navigates to [ENV1] login page
  And User enters valid username : <username> and password: <password>
  When User clicks on login button
  Then ENV1 landing can be seen.
  Examples:
    | username |  password |
    | 000000000    | 0000000 |

@smoke2
Scenario Outline: Login into page [ENV2]
  Given User navigates to [ENV2] login page
  And User enters valid username : <username> and password: <password>
  When User clicks on login button
  Then ENV2 landing can be seen.
  Examples:
    | username |  password |
    | 000000001    | 0000000 |


@smoke3
Scenario Outline: Login into page [ENV3]
  Given User navigates to [ENV3] login page
  And User enters valid username : <username> and password: <password>
  When User clicks on login button
  Then ENV3 landing can be seen.
  Examples:
    | username |  password |
    | 000000003    | 0000000 |

[Andrew Premdas]

Your scenarios are not duplicates, they are similar. To reduce the cost of the similarity make the scenarios as simple as possible.

So with your example the only difference is the environment you login into so your scenarios could be

Scenario: Login into env1

  Given I am an env 1 user

  When I login

  Then I should see my landing page

Scenario: Login into env1

  Given I am an env 2 user

  When I login

  Then I should see my landing page

...

Note how my scenarios are equivalent but much simpler than your examples, and only the Given is different.

By taking this approach and using helper methods to do the work you can have a much reduced codebase to do this work.

module LoginStepHelper

  def create_user(env: )

     ...

  end

  def login(user: )

     visit user.homepage

     fill_in_login_details(user: user)

     submit_form

  end

  def fill_in_login_details

     fill_in user.email

     ...

  end

 

  def should_see_landing_page

     expect ...

  end

end

World LoginStepHelper

Given 'I am an env 1 user' do

  @i = create_user(env: 1)

end

Given 'I am an env 2 user' do

  @i = create_user(env: 2)

end

When 'I login' do

  visit @i.login_page

  login(user: @i)

end

Then ...

...

and thats pretty much all you need. Note: the following

- no scenario outlines necessary

- no params for step defs

- no hard config of password/user ids in feature

- use of global @i variable to store the test user

- test user know their login page, password email, name etc

- the only thing we've specified is the login page (1,2 or 3)

Of course there is a bit more infrastructure to set up depending on how you configure your environments etc.. But the point holds. If your scenarios and step definitions are very simple and you delegate HOW things are done to helper methods, then step definition duplication and scenario duplication become almost none issues (apart from runtime cost).

All of the above code is ruby, I'm pretty sure you can translate this to other languages.

You have to do a bit of tricky stuff behind the scenes to get the test-user to work

Hope that helps

All best

--
Posting rules: https://cucumber.io/support/posting-rules
---
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cukes/0dcccf16-a241-4e07-94bf-d6a54b7b2979%40googlegroups.com.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org

[George Dinwiddie]

I would take a similar approach to Andrew, but get rid of the user
interactions in the scenarios, pushing this down to the step definitions
and test code that they call.

Scenario: smoketest env1
When a user logs into env1
Then the system displays env1 landing page

In this example, "env1" is a parameter to the step definition. The step
definition uses this value to look up a user for that environment, the
login page for that environment, and how to detect the landing page for
that environment.

The advantage of this scenario is that it describes the desired behavior
of the system, rather than describing the user's behavior.

- George

> Then ENV2 landingcan be seen.

> Examples:
> | username | password |
> | 000000001 | 0000000|
>
>
>
> @smoke3
> Scenario Outline: Login into page [ENV3]
> Given User navigates to [ENV3] login page
> And User enters valid username :<username> and password:<password>
> When User clicks on login button
> Then ENV3 landing can be seen.
> Examples:
> | username | password |
> | 000000003 | 0000000|
>
> --
> Posting rules: https://cucumber.io/support/posting-rules
> ---
> 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+un...@googlegroups.com

> <mailto:cukes+un...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/cukes/0dcccf16-a241-4e07-94bf-d6a54b7b2979%40googlegroups.com

> <https://groups.google.com/d/msgid/cukes/0dcccf16-a241-4e07-94bf-d6a54b7b2979%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>
>
> --
> ------------------------
> Andrew Premdas
> blog.andrew.premdas.org <http://blog.andrew.premdas.org>

>
> --
> Posting rules: https://cucumber.io/support/posting-rules
> ---
> 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+un...@googlegroups.com

> <mailto:cukes+un...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/cukes/CAMxjd8MyZcniseG5dwy0zh9jr1jPXQBy5FHrOeLKOKNURQpdTw%40mail.gmail.com
> <https://groups.google.com/d/msgid/cukes/CAMxjd8MyZcniseG5dwy0zh9jr1jPXQBy5FHrOeLKOKNURQpdTw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

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

[Gheeno San Pascual III]

Thank you so much for the feedback gentlemen. Applying the changes now. 

I appreciate the help.

To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cukes/8ab18ed2-80ec-4ff9-43b6-a74b31179e28%40iDIAcomputing.com.

--

Thank you,

Gino