Thước đo góc - Hướng dẫn kiểu cho thước đo góc
Trong chương này, chúng ta hãy tìm hiểu chi tiết về hướng dẫn kiểu cho thước đo góc.
Giới thiệu
Hướng dẫn kiểu được tạo ra bởi hai kỹ sư phần mềm có tên, Carmen Popoviciu, kỹ sư front-end tại ING và Andres Dominguez, kỹ sư phần mềm tại Google. Do đó, hướng dẫn kiểu này còn được gọi là Carmen Popoviciu và hướng dẫn kiểu của Google cho thước đo góc.
Hướng dẫn phong cách này có thể được chia thành năm điểm chính sau:
- Quy tắc chung
- Cấu trúc dự án
- Các chiến lược định vị
- Đối tượng Trang
- Bộ thử nghiệm
Quy tắc chung
Sau đây là một số quy tắc chung phải được cẩn thận khi sử dụng thước đo góc để kiểm tra -
Không kiểm tra đầu cuối những gì đã được kiểm tra đơn vị
Đây là quy tắc chung đầu tiên được đưa ra bởi Carmen và Andres. Họ đề nghị rằng chúng tôi không được thực hiện kiểm tra e2e trên mã đã được kiểm tra đơn vị. Lý do chính đằng sau nó là các bài kiểm tra đơn vị nhanh hơn nhiều so với các bài kiểm tra e2e. Một lý do khác là chúng ta phải tránh các thử nghiệm trùng lặp (không thực hiện cả thử nghiệm đơn vị và e2e) để tiết kiệm thời gian của chúng tôi.
Chỉ sử dụng một tệp cấu hình
Một điểm quan trọng khác được khuyến nghị là chúng ta phải chỉ sử dụng một tệp cấu hình. Không tạo tệp cấu hình cho từng môi trường bạn đang thử nghiệm. Bạn có thể dùnggrunt-protractor-coverage để thiết lập các môi trường khác nhau.
Tránh sử dụng logic cho bài kiểm tra của bạn
Chúng ta phải tránh sử dụng câu lệnh IF hoặc vòng lặp FOR trong các trường hợp thử nghiệm của mình bởi vì nếu chúng ta làm như vậy thì bài kiểm tra có thể vượt qua mà không cần kiểm tra bất kỳ điều gì hoặc nó có thể chạy rất chậm.
Làm cho thử nghiệm độc lập ở cấp tệp
Thước đo góc có thể chạy thử nghiệm song song khi bật tính năng chia sẻ. Các tệp này sau đó sẽ được thực thi trên các trình duyệt khác nhau khi chúng có sẵn. Carmen và Andres khuyến nghị nên thực hiện kiểm tra độc lập ít nhất là ở cấp độ tệp vì thứ tự mà chúng sẽ được chạy bằng thước đo góc là không chắc chắn và hơn nữa, việc chạy kiểm tra một cách cô lập là khá dễ dàng.
Cấu trúc dự án
Một điểm chính quan trọng khác liên quan đến hướng dẫn phong cách của Thước đo góc là cấu trúc của dự án của bạn. Sau đây là khuyến nghị về cấu trúc dự án -
Tìm hiểu thử nghiệm e2e trong một cấu trúc hợp lý
Carmen và Andres khuyến nghị rằng chúng ta phải nhóm các bài kiểm tra e2e của mình theo một cấu trúc phù hợp với cấu trúc của dự án của bạn. Lý do đằng sau khuyến nghị này là việc tìm kiếm các tệp sẽ trở nên dễ dàng và cấu trúc thư mục sẽ dễ đọc hơn. Bước này cũng sẽ tách các bài kiểm tra e2e khỏi các bài kiểm tra đơn vị. Họ khuyến nghị rằng nên tránh loại cấu trúc sau:
|-- 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.jsMặt khác, họ đề xuất loại cấu trúc sau:
|-- 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.jsChiến lược định vị
Sau đây là một số chiến lược định vị phải được cẩn thận khi sử dụng thước đo góc để kiểm tra -
Không bao giờ sử dụng XPATH
Đây là chiến lược định vị đầu tiên được đề xuất trong hướng dẫn kiểu thước đo góc. Lý do đằng sau điều tương tự là XPath cần phải bảo trì nhiều vì đánh dấu rất dễ thay đổi. Hơn nữa, biểu thức XPath là chậm nhất và rất khó gỡ lỗi.
Luôn thích các công cụ định vị dành riêng cho thước đo góc như by.model và by.binding
Các định vị cụ thể của thước đo góc như by.model và by.binding ngắn gọn, cụ thể và dễ đọc. Với sự giúp đỡ của họ, rất dễ dàng để viết bộ định vị của chúng tôi.
Thí dụ
View
<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>Đối với đoạn mã trên, bạn nên tránh những điều sau:
var nameElement = element.all(by.css('.red li')).get(0);
var personName = element(by.css('.details .personal input'));Mặt khác, những điều sau đây được khuyến nghị sử dụng:
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'));Khi không có bộ định vị Thước đo góc nào khả dụng, thì bạn nên ưu tiên by.id và by.css hơn.
Luôn tránh các trình định vị văn bản để thay đổi văn bản thường xuyên
Chúng ta phải tránh các trình định vị dựa trên văn bản như by.linkText, by.buttonText và by.cssCont rênText vì văn bản cho các nút, liên kết và nhãn thường xuyên thay đổi theo thời gian.
Đối tượng Trang
Như đã thảo luận trước đó, các đối tượng trang đóng gói thông tin về các phần tử trên trang ứng dụng của chúng tôi và do đó, điều này giúp chúng tôi viết các trường hợp thử nghiệm rõ ràng hơn. Một ưu điểm rất hữu ích của các đối tượng trang là chúng có thể được sử dụng lại qua nhiều lần kiểm tra và trong trường hợp nếu mẫu ứng dụng của chúng tôi đã bị thay đổi, chúng tôi chỉ cần cập nhật đối tượng trang. Tiếp theo là một số khuyến nghị cho các đối tượng trang phải được cẩn thận khi sử dụng thước đo góc để thử nghiệm -
Để tương tác với trang đang kiểm tra, hãy sử dụng các đối tượng trang
Bạn nên sử dụng các đối tượng trang để tương tác với trang đang kiểm tra vì chúng có thể đóng gói thông tin về phần tử trên trang đang kiểm tra và chúng cũng có thể được sử dụng lại.
Luôn khai báo đối tượng một trang cho mỗi tệp
Chúng ta nên xác định từng đối tượng trang trong tệp riêng của nó vì nó giữ cho mã sạch và việc tìm kiếm mọi thứ trở nên dễ dàng.
Ở cuối trang, tệp đối tượng luôn sử dụng một mô-đun duy nhất .exports
Khuyến nghị rằng mỗi đối tượng trang nên khai báo một lớp để chúng ta chỉ cần xuất một lớp. Ví dụ, nên tránh sử dụng tệp đối tượng sau:
var UserProfilePage = function() {};
var UserSettingsPage = function() {};
module.exports = UserPropertiesPage;
module.exports = UserSettingsPage;Nhưng mặt khác, chúng tôi khuyên bạn nên sử dụng:
/** @constructor */
var UserPropertiesPage = function() {};
module.exports = UserPropertiesPage;Khai báo tất cả các mô-đun bắt buộc ở trên cùng
Chúng ta nên khai báo tất cả các mô-đun bắt buộc ở đầu đối tượng trang vì nó làm cho các phần phụ thuộc của mô-đun trở nên rõ ràng và dễ tìm.
Khởi tạo tất cả các đối tượng trang ở đầu bộ thử nghiệm
Bạn nên khởi tạo tất cả các đối tượng trang ở phần đầu của bộ thử nghiệm vì điều này sẽ tách các phần phụ thuộc khỏi mã thử nghiệm cũng như làm cho các phần phụ thuộc có sẵn cho tất cả các thông số kỹ thuật của bộ phần mềm.
Không sử dụng kỳ vọng () trong các đối tượng trang
Chúng ta không nên sử dụng kỳ vọng () trong các đối tượng trang, tức là chúng ta không nên thực hiện bất kỳ xác nhận nào trong các đối tượng trang của mình vì tất cả các xác nhận phải được thực hiện trong các trường hợp thử nghiệm.
Một lý do khác là người đọc thử nghiệm chỉ có thể hiểu hành vi của ứng dụng bằng cách đọc các trường hợp thử nghiệm.