Using a single web step across Features and Scenarios

[Jaya Chakravarthi Kuppu]

Hey All,

I had picked up #1811 - creating common methods/removing duplicate steps.

What was found(till now) ?

1) There were multiple steps doing the same action. For eg

•           There were 3 steps which all did the same, which is clicking a link.
•           2 steps which did filling a text box.

2) Steps were placed in files which would make it difficult to find, basically misplaced. For eg

•          Clicking of button which is a common action was placed in a more specific file rather than general file like basic steps or web steps.

3) Now this brings other problem. There too many common files -

•          web_steps, basic_steps and more_web_steps.

4) Various steps implemented for interacting with elements which don't have a unique identifier(id, name, value). For eg

•            There is separate step for click on text inside span, which inturn clicks on xpath.
  
•            Separate step for clicking on xpaths
  

Corresponding Solution/Suggestions

1) Remove all the duplicate and stick to a single step. Its implemented for clicking link and filling text box. Yet to find more.

2) Move common steps to web_steps and move more specific actions to specific files. Few were moved to web_steps.

3) Stick with some convention and name the files appropriately.  For eg basic element interactions can be grouped in a single file and common set of actions/repetitive steps can be moved to another file. Any other common file should be removed.

4) If we start implementing click on span, the list will go on to divs, table and so on. For interacting with items without unique identifiers we can use Xpaths or CSS and have a common step. But this would mean the feature file looking ugly. We can use key value pairs for this if needed.

Need more suggestions/comments on this

- Jaya

[Pranjali Talekar]

Hey all,

             As the framework grows on ,maintaining all these files is really a nightmare. May be introducing a Page-Object Model could help.

            Also introducing a business layer could determine what value we exactly get out of that particular test and help everyone to get on the same track including the newly joined volunteers . 

   Eventually this will help in getting the tests :

                             

    1. In an organised way

    2. Get rid of Redundancy 

    3. Reusability of tests can be done

            

      

--
You received this message because you are subscribed to the Google Groups "rapidftr" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rapidftr+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Regards,

Pranjali Talekar

Quality Analyst,ThoughtWorks  Pune

Mob : +918554983478

[John D. Hume]

I think the usual advice from Cucumber enthusiasts is to avoid web_steps-type steps and prefer custom steps that express user intentions in domain terms. This is supposed to make your features easier to read and maintain, but it means you spend a lot more time creating steps. It also breaks down a bit when an application provides multiple ways of doing the same thing, though that only requires a minor compromise. (Hopefully we don't have that issue in RapidFTR.)

I agree something like Page Object Model could help make the steps and the application easier to read, write, and change.

For historical background, I believe web_steps was generated by Cucumber-Rails with a warning about not modifying it because it could be overwritten in an upgrade, hence more_web_steps.

[Jaya Chakravarthi Kuppu]

Agree with you John. As you pointed out writing steps in proper domain terms would take a lot of effort in terms of time and design. While I would like that to happen, there are things which i stated above that could be acted upon sooner.

For #3 above I have moved all the common tests from basic_steps and more_web_steps to web_steps. I noticed more_web_steps had lot of steps doing assertions. So i moved any assertions from web_steps to more_web_steps and renamed it to assertion_steps.

assertion_steps now has many assertions, moving on we can move few steps to specific step definition file.

@TW devs : please take care of my pull request

- Jaya