Page Object Model (POM) cho người mới: tổ chức script tự động bền vững (có code chạy được)

1. Tóm tắt nhanh & màn hình bạn sẽ test

Chào bạn mới! Khi vừa học automation, phản xạ tự nhiên là viết thẳng: mở trình duyệt, tìm phần tử bằng id, click, nhập liệu — tất cả nằm gọn trong 1 file test. Cách này chạy tốt với vài test đầu tiên. Nhưng khi số lượng test tăng lên vài chục, và nhiều test cùng phải 'đăng nhập' trước khi làm việc khác, bạn sẽ thấy cùng một đoạn code lặp đi lặp lại ở khắp nơi. Page Object Model chính là cách giải quyết vấn đề này: gom mọi thứ 'biết về giao diện' vào một lớp riêng, để file test chỉ còn tập trung vào việc kiểm tra đúng/sai. Chúng ta sẽ học qua màn đăng nhập và giỏ hàng thật của ShopEasy, có hình minh hoạ và code Playwright chạy được.

2. Vấn đề: test tự động không có cấu trúc rõ ràng

Hãy hình dung bạn viết 10 test cho ShopEasy, và cả 10 test đều cần đăng nhập trước. Nếu không có cấu trúc, mỗi file test sẽ có đúng đoạn code: tìm ô email bằng '#email-input', tìm ô mật khẩu bằng '#password-input', click nút '#btn-login'. Ban đầu điều này có vẻ vô hại — chỉ là copy-paste vài dòng. Nhưng khi dự án lớn lên tới 50, 100 test, cùng một đoạn code đăng nhập tồn tại ở 50, 100 nơi khác nhau.

Vấn đề thật sự lộ ra khi giao diện thay đổi — điều gần như chắc chắn sẽ xảy ra trong một dự án đang phát triển. Đội thiết kế đổi id nút, thêm bước xác thực, hay đổi nhãn ô nhập. Nếu locator nằm rải rác trong 50 file, bạn phải rà từng file để sửa, dễ bỏ sót, dễ sửa sai chỗ này đúng chỗ kia. Đây chính là lúc chi phí bảo trì automation vượt xa lợi ích nó mang lại — và cũng là lý do nhiều đội automation 'bỏ cuộc' giữa chừng vì test ngày càng giòn, khó tin tưởng.

3. Page Object Model là gì & nguyên tắc cốt lõi

Nguyên tắc cốt lõi của POM là 'tách biệt trách nhiệm' (separation of concerns): mỗi màn hình của ứng dụng được đại diện bởi một lớp — gọi là Page Object — chứa TẤT CẢ những gì liên quan tới giao diện màn hình đó: locator của các phần tử, và các hành động có thể thực hiện (điền form, bấm nút, đọc nội dung). File test không còn 'biết' id hay class CSS nào cả — nó chỉ gọi các hàm như loginPage.login(email, password) rồi kiểm tra kết quả.

Nói cách khác: Page Object 'biết' giao diện trông ra sao và cách thao tác lên nó, còn file test chỉ 'biết' nghiệp vụ — dữ liệu nào cần nhập, kết quả nào là đúng. Khi giao diện đổi, chỉ phần 'biết giao diện' (Page Object) cần sửa; phần 'biết nghiệp vụ' (test) hầu như không đổi vì logic kiểm tra vẫn y hệt. Đây là lý do POM giúp automation bền vững hơn hẳn theo thời gian, đặc biệt với dự án nhiều màn hình dùng chung (như đăng nhập xuất hiện trước hầu hết mọi luồng).

4. Cấu trúc thư mục dự án automation dùng POM

Một dự án Playwright dùng POM thường tách rõ 2 khu vực: thư mục pages/ chứa các lớp Page Object (mỗi màn hình 1 file), và thư mục tests/ chứa các kịch bản test (mỗi luồng nghiệp vụ 1 file). Cách đặt tên nhất quán giúp bất kỳ thành viên mới nào cũng nhanh chóng tìm đúng chỗ cần sửa khi có lỗi.

shopeasy-automation/
├── pages/
│   ├── BasePage.js       # hanh vi dung chung: goto, cho tai trang...
│   ├── LoginPage.js      # locator + hanh dong man Dang nhap
│   └── CartPage.js       # locator + hanh dong man Gio hang
├── tests/
│   ├── login.spec.js     # kich ban test dang nhap, dung LoginPage
│   └── cart.spec.js      # kich ban test gio hang, dung LoginPage + CartPage
├── fixtures/
│   └── test-data.json    # du lieu mau: tai khoan, san pham...
├── playwright.config.js
└── package.json