Protractor - Protractor 風格指南
本章，我們將詳細學習 Protractor 的風格指南。
簡介
該風格指南由兩位軟體工程師建立：ING 的前端工程師 **Carmen Popoviciu** 和 Google 的軟體工程師 **Andres Dominguez**。因此，此風格指南也稱為 Carmen Popoviciu 和 Google 的 Protractor 風格指南。
此風格指南可分為以下五個要點：
- 通用規則
- 專案結構
- 定位策略
- 頁面物件
- 測試套件
通用規則
以下是使用 Protractor 進行測試時必須注意的一些通用規則：
不要對已經進行單元測試的內容進行端到端測試
這是 Carmen 和 Andres 給出的第一個通用規則。他們建議我們不要對已經進行單元測試的程式碼執行 e2e 測試。其主要原因是單元測試比 e2e 測試快得多。另一個原因是，為了節省時間，我們必須避免重複測試（不要同時進行單元測試和 e2e 測試）。
只使用一個配置檔案
另一個重要的建議是，我們必須只使用一個配置檔案。不要為每個測試環境建立配置檔案。您可以使用 **grunt-protractor-coverage** 來設定不同的環境。
避免在測試中使用邏輯
我們必須避免在測試用例中使用 IF 語句或 FOR 迴圈，因為如果這樣做，測試可能會在沒有進行任何測試的情況下透過，或者執行速度非常慢。
使測試在檔案級別獨立
啟用共享時，Protractor 可以並行執行測試。然後，這些檔案將在不同的瀏覽器中按可用情況執行。Carmen 和 Andres 建議至少在檔案級別使測試獨立，因為 Protractor 執行它們的順序是不確定的，而且單獨執行測試非常容易。
專案結構
關於 Protractor 風格指南的另一個重要要點是專案的結構。以下是關於專案結構的建議：
以合理的結構分組 e2e 測試
Carmen 和 Andres 建議我們必須以對專案結構有意義的結構來分組我們的 e2e 測試。此建議背後的原因是查詢檔案會變得容易，並且資料夾結構更易於閱讀。此步驟還將 e2e 測試與單元測試分開。他們建議應避免以下型別的結構：
|-- project-folder
|-- app
|-- css
|-- img
|-- partials
home.html
profile.html
contacts.html
|-- js
|-- controllers
|-- directives
|-- services
app.js
...
index.html
|-- test
|-- unit
|-- e2e
home-page.js
home-spec.js
profile-page.js
profile-spec.js
contacts-page.js
contacts-spec.js
另一方面，他們推薦以下型別的結構：
|-- project-folder
|-- app
|-- css
|-- img
|-- partials
home.html
profile.html
contacts.html
|-- js
|-- controllers
|-- directives
|-- services
app.js
...
index.html
|-- test
|-- unit
|-- e2e
|-- page-objects
home-page.js
profile-page.js
contacts-page.js
home-spec.js
profile-spec.js
contacts-spec.js
定位策略
以下是使用 Protractor 進行測試時必須注意的一些定位策略：
永遠不要使用 XPATH
這是 Protractor 風格指南中推薦的第一個定位策略。其背後的原因是 XPath 需要大量的維護，因為標記很容易發生變化。此外，XPath 表示式速度最慢，並且很難除錯。
始終優先使用 Protractor 特定的定位器，例如 by.model 和 by.binding
Protractor 特定的定位器（例如 by.model 和 by.binding）簡短、具體且易於閱讀。藉助它們，編寫定位器也變得非常容易。
示例
檢視
<ul class = "red">
<li>{{color.name}}</li>
<li>{{color.shade}}</li>
<li>{{color.code}}</li>
</ul>
<div class = "details">
<div class = "personal">
<input ng-model = "person.name">
</div>
</div>
對於以上程式碼，建議避免以下內容：
var nameElement = element.all(by.css('.red li')).get(0);
var personName = element(by.css('.details .personal input'));
另一方面，建議使用以下內容：
var nameElement = element.all(by.css('.red li')).get(0);
var personName = element(by.css('.details .personal input'));
var nameElement = element(by.binding('color.name'));
var personName = element(by.model('person.name'));
當沒有可用的 Protractor 定位器時，建議優先使用 by.id 和 by.css。
始終避免對頻繁更改的文字使用文字定位器
我們必須避免使用基於文字的定位器，例如 by.linkText、by.buttonText 和 by.cssContainingText，因為按鈕、連結和標籤的文字會隨著時間的推移而頻繁更改。
頁面物件
如前所述，頁面物件封裝了關於應用程式頁面上元素的資訊，因此幫助我們編寫更簡潔的測試用例。頁面物件的一個非常有用的優點是它們可以在多個測試中重複使用，如果我們的應用程式模板發生了更改，我們只需要更新頁面物件即可。以下是使用 Protractor 進行測試時必須注意的一些頁面物件建議：
要與被測頁面互動，請使用頁面物件
建議使用頁面物件與被測頁面互動，因為它們可以封裝關於被測頁面上元素的資訊，並且也可以重複使用。
始終為每個檔案宣告一個頁面物件
我們應該在它自己的檔案中定義每個頁面物件，因為它可以保持程式碼簡潔，並且查詢內容變得容易。
在頁面物件檔案的末尾始終使用單個 module.exports
建議每個頁面物件都應該宣告一個類，以便我們只需要匯出一個類。例如，應避免以下物件檔案的用法：
var UserProfilePage = function() {};
var UserSettingsPage = function() {};
module.exports = UserPropertiesPage;
module.exports = UserSettingsPage;
但另一方面，建議使用以下內容：
/** @constructor */
var UserPropertiesPage = function() {};
module.exports = UserPropertiesPage;
在頂部宣告所有必需的模組
我們應該在頁面物件的頂部宣告所有必需的模組，因為它使模組依賴關係清晰易於查詢。
在測試套件的開頭例項化所有頁面物件
建議在測試套件的開頭例項化所有頁面物件，因為這將使依賴關係與測試程式碼分開，並使依賴關係可用於套件的所有規範。
不要在頁面物件中使用 expect()
我們不應該在頁面物件中使用 expect()，即我們不應該在頁面物件中進行任何斷言，因為所有斷言都必須在測試用例中完成。
另一個原因是，測試的閱讀者應該能夠僅透過閱讀測試用例來理解應用程式的行為。