How we can store the test data Header of any gherkin Scenario in a Separate Prop file or Textfile

[Nishant Rajpal]

Hi,

I want to Know how I can store the test data Header of any gherkin Scenario in a Seperate Properties file or Textfile so that anytime my header get changed in my Application So i don't have to make changes in my cucumber file.

Test data Header Example is Given Below.

    

In Above Example

How I can handle Test data header Like Lineup and Model Type becoz they are dynamic and they keep changing Like Lineup will Become LINEUP and Model type to Model.These test data header are being used in my code so i cant ignore them.

Thanks

Nicks

[Eric Kessler]

On Tuesday, February 6, 2018 at 5:00:02 PM UTC-5, Nishant Rajpal wrote:

Hi,

I want to Know how I can store the test data Header of any gherkin Scenario in a Seperate Properties file or Textfile so that anytime my header get changed in my Application So i don't have to make changes in my cucumber file.

Having to so regularly change headers that maintaining it must become programmatic is very suspicious. Why do they need to change?

 

Test data Header Example is Given Below.

    

In Above Example

How I can handle Test data header Like Lineup and Model Type becoz they are dynamic and they keep changing Like Lineup will Become LINEUP and Model type to Model.These test data header are being used in my code so i cant ignore them.

'Lineup' and 'LINEUP' don't seem meaningfully different and 'Model type' to 'Model' still sounds like the same idea. If the application concept hasn't changed, then why does the documentation have to change?

 

Thanks

Nicks

Eric K 

[Andrew Premdas]

Consider not putting any data in your Gherkin that determines HOW something is done. For example you could write

When "I visit '/login' and login"

and capture the path in a param and then use that to login. However if HOW you login changes, lets say we use `/signin` instead you will have to change your scenario.

However if you write your scenario so it only tells you WHAT you are doing as in

When "I login"

and keep the information about how you do things in the step definitions or better yet helper methods that the step definitions use, then you scenarios can remain unchanged.

When "I login" do

  login user: @i

end

module LoginStepHelper

  def login(user:

     visit login_path

      ...

   end

end

World LoginStepHelper

Once you push the HOW down into helper methods you can easily be DRY and use all the functionality a programming language provides to solve this problem.

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

--

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

Andrew Premdas

blog.andrew.premdas.org