我遇到了標準頁面對象設計是一維的情況。這些頁面非常大,並且包含許多(大部分是唯一的)頁面部分。一維頁面對象結構
頁對象的現有語料庫是這樣的:
this.pageHeaderLogin = $$('div.header > a.login');
this.pageHeaderSignUp = $$('div.header > a.signup');
this.pageHeaderContact = $$('div.header > a.contact');
this.pageIntroSectionTitle = $$('div.intro > span.title');
this.pageIntroSectionText = $$('div.intro > span.description');
等,具有多達50-100元素,this
所有直接子。
在我看來,更好的結構不是單向的,而是與網頁本身的結構相似。所以我寧願做一個頁面對象,如:
this.pageHeader.login = $$('div.header > a.login');
this.pageHeader.signUp = $$('div.header > a.signup');
...
this.pageIntroSection.title = $$('div.intro > span.title');
等等。
不幸的是,我被告知這太複雜了。我想提出一個論點,認爲它不僅不復雜,而且實際上更加有組織,但是頁面對象的所有示例都太小而不能說明超出一維結構的任何內容。
有人可以指點我可以用作參考的非一維頁面對象的好例子來展示此設計的優點嗎?
我會認爲自定義require()函數比這個模型更難理解。 頁面對象的一些示例將「組件對象」稱爲選項。它發生在我身上,我可以輕鬆地做一個homepageHeaderPageObject和一個homepageIntroPageObject和一個homepageFeaturesPageObject等等。但是,這需要更多的東西和更多的對象雜耍。而不是home.intro.text和home.header.login,我必須有homeintro.text和homeheader.login。你能否詳細說明爲什麼公寓更好? –
@KeithTyler我有一種感覺,要麼你誤會了我的觀點,要麼我沒有足夠清楚地解釋清楚,對不起,如果是這樣的話。我實際上支持在一定程度上嵌套複雜頁面對象的想法。通過所提出的方法,您可以在測試中實際使用嵌套頁面對象中的字段,而無需額外的要求,例如請參閱示例測試中的「page.subPage.someotherfield」。 'requirePO'只是一個幫助工具,可以使測試中的要求更具可讀性,並且有一種方法可以從項目中的指定位置導入頁面對象。謝謝! – alecxe