javascript - Should Protractor Page Objects expose ElementFinder -
there discussion in our team if should forbid exposing "elementfinder" , "elementarrayfinder" in our page objects.
the main reason following quote simon stewart. page objects done right - selenium conference 2014 (page.7)
if have webdriver apis in test methods... you're doing wrong.
seleniumhq/selenium/pageobjects https://github.com/seleniumhq/selenium/wiki/pageobjects
the approach correct transition functions returns page object or if multiple selections happening on 1 page can return page , chain these calls.
but when doing simple there lot of boilerplate write test element exist , have text.
creating mimic functions of "elementfinder" not make sense me. of time faster , more readable expose element , use build-in functions of "elementfinder" ".gettext()". think better make element private , expose "getelementtext()" function?
what best practice forbid expose "elementfinder" , "elementarrayfinder" in page objects?
we use cucumber tests divided between
- features
- step definitions
- helpers
- page files
all logic , asserts in step definitions , helpers. step definitions invoke page methods when screen value needed. page methods return pojos. details finding elements encapsulated in page files. reasons obvious; when (not if) page html changes have make fix in 1 place. once break encapsulation have start of maintenance nightmare.
a pattern use create helper class e.g. officeinfo, contain, say, td's in tr table of offices. page method return
list<officeinfo> i.e. 1 list element each tr. office information decoupled details of how information displayed on page. if new td's added update class officeinfo, update page method , insert new step definition without impacting other places officeinfo (but not new td) used.
Comments
Post a Comment