<div dir="ltr"><br><div><br></div><div>The Page Object design pattern divides browser tests into three areas:  the controller, where the test is created (this is a description of the test):  the steps of the test, which are actions taken by the test (the steps are verbs, actions, navigation from one place to another and checking on status; and the page definitions, which are the nouns against which the steps/actions/verbs are working.  </div>
<div><br></div><div>In our implementation of the Page Object pattern: </div><div><br></div><div>* the Cucumber feature files are the story of the tests</div><div>* the steps.rb files are the verbs and actions</div><div>* the page.rb files are the nouns and the pages</div>
<div><br></div><div>If you know anything about Design Patterns, you may know that they are discovered, not invented. Among people who do browser testing, the Page Object design pattern is generally accepted to be the best known solution for creating  browser tests that are robust, readable, maintainable, and that will scale to large numbers of tests. </div>
<div><br></div><div>In practice, that boils down to some rules that we need to follow, and one of those rules is:  *no element identifiers in steps files*.  Page elements like div and span that have identifiers of e.g. class: and css: need to be managed in the page.rb files and *only* in the page.rb files. </div>
<div><br></div><div>Do not put page element identifiers into the steps of the test.  This makes the tests difficult to read, difficult to scale, and very difficult to maintain.</div><div><br></div><div>Adhere to the Page Object design pattern:  keep your page element identifiers in the /support/pages/*page.rb files ONLY, and NOT in the /step_definitions/*steps.rb files. <br>
</div><div><br></div><div><br></div></div>