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

Popular posts from this blog

sql server - Cannot query correctly (MSSQL - PHP - JSON) -

php - trouble displaying mysqli database results in correct order -

C++ Linked List -