I. Mở đầu – Mô hình Page Object Model (POM)

Với các bạn đã nghiên cứu POM trong 1 thời gian thì có thể bạn đã nghe đến Pattern này, nếu bạn chưa biết thì mình xin phép được tóm tắt lại.

Mô hình POM này là cách model Page thành những Object trong code, những actions với các WebElement được wrap trong những Page Class, rồi Test Class sẽ gọi những actions đó.

Ưu điểm của mô hình POM:

• Thỏa mãn được yêu cầu: trong phần Test sẽ không sử dụng trực tiếp API của selenium webdriver.
• Test trở nên dễ maintain hơn vì ở đó chỉ có những step theo testcase, giảm thời gian đọc code.
• Element của trang web được khai báo 1 lần nên nếu có thay đổi UI thì cũng sẽ dễ sửa chữa

II. Những hạn chế của mô hình POM

Nhược điểm của POM là nó không thỏa mãn được yêu cầu của nguyên tắc lập trình SOLID. Cụ thể là nó vi phạm 2 nguyên tắc:

• Single Responsibility Principle (SPP)
• Open Close Principle (OCP)

1.Về Single Responsibility Principle, mỗi Class chỉ nên làm 1 nhiệm vụ duy nhất hay nói cách khác là chỉ có duy nhất 1 lý do thể thay đổi (one reason to change).

Nhưng theo Login Class ở phía trên thì ta nhìn thấy có 2 lý do để thay đổi:

• Khi UI có update, ta phải sửa lại locator
• Khi flow tương tác với Element bị thay đổi, ta phải sửa lại các action

Do đó, ta cần phải tách Page Class thành những thành phần nhỏ hơn để thỏa mãn được SRP.

2.Về Open Close Principle, ý tưởng chính là 1 Class nên open cho mở rộng và close cho sửa đổi, có nghĩa là để thêm behaviour thì nên tạo những Class mới thay vì sửa vào Class cũ.

Nhưng theo POM, tất cả những actions của Page Class đều được viết ở 1 chỗ nên thay vì mở rộng thêm Class mới thì ta sẽ sửa vào Page Class

Dưới đây là Link phân tích kỹ càng hơn https://dzone.com/articles/page-objects-refactored-solid-steps-to-the-screenp

III. Những cách để tối ưu UI test

Để tối ưu code hơn, ta sẽ cố gắng khắc phục những nhược điểm của mô hình POM phía trên. Dưới đây là 3 cách mình biết:

1. Sử dụng mô hình Screenplay của Serenity BDD Framework, bạn sẽ dễ dàng mở rộng Test mà không lo sửa vào những action sẵn có và code sẽ được chia thành nhiều layers hơn và mỗi layer sẽ chỉ có 1 nhiệm vụ duy nhất, dễ maintain hơn nhiều so với POM. https://serenity-bdd.github.io/theserenitybook/latest/serenity-screenplay.html
2. Nếu bạn vẫn muốn sử dụng mô hình POM vì đã quá quen với nó, bạn có thể refactor theo gợi ý của John Ferguson Smart. https://johnfergusonsmart.com/page-objects-that-suck-less-tips-for-writing-more-maintainable-page-objects/
3. Sử dụng Fluent Interface để làm test dễ đọc hơn, đồng thời tách các thành phần của Page Class ra thành nhiều Class nhỏ hơn để thỏa mãn Single Responsibility. Đây là cách mà mình sẽ hướng dẫn ở những bài tiếp theo.

IV. Tổng kết

Một vài lời nhắn nhủ trước khi kết bài:

• Cách sử dụng Fluent Interface không phải là cách do mình nghĩ ra (Of course :D), đây là cách mình có học được từ 1 course ở trên Pluralsight. Vì Pluralsight chi phí khá đắt, mình cũng không nghĩ là nhiều bạn có thể mua mà học được, nên mình viết lại để nhiều bạn có thể tiếp cận. Mục tiêu chia sẻ kiến thức cho cộng đồng tester nên đừng bạn nào dọa mình chuyện bản quyền nhé. T__T
• Mình sẽ hướng dẫn thành 1 series mới thay vì viết tiếp vào series Selenium Webdriver mình đã viết. Ở trong series này, mình sẽ sử dụng Intellij IDEA + Gradle + Junit 5 + AssertJ để hướng dẫn, thay vì lối mòn Eclipse + Maven + TestNG mà ai cũng viết. Mình hi vọng sẽ giúp các bạn có thêm 1 chút kiến thức về automation test.
• Hết rồi, cảm ơn bạn đã đọc đến đây! 😀