[Playwright Typescript] Bài 11 - Chiến lược POM Nâng cao: Quản lý Assertions, Tránh Phản mẫu (Anti-Patterns) và Tối ưu Kiến trúc

// tests/login.spec.ts
// (Imports...)

let loginPage: LoginPage;
let profilePage: ProfilePage;

test.beforeEach(async ({ page }) => {
  loginPage = new LoginPage(page);
  profilePage = new ProfilePage(page);
});

// ... (Test TC_LOGIN_01)

test('TC_PROFILE_03: Should logout successfully', async ({ page }) => {
  await loginPage.goTo();
  await loginPage.login('valid_user', 'correct_pass');

  // CÁCH GỌI MỚI: Rõ ràng hơn nhiều 💡
  // "Từ trang profile, truy cập component header, và thực hiện hành động logout"
  await profilePage.header.logout(); 
  
  await expect(page).toHaveURL('/login');
});

⚖️ Phần 3: Chiến lược Xác thực (Assertions): Cân bằng giữa Tính Linh hoạt và Dễ đọc

Một câu hỏi kiến trúc quan trọng khác là: Nên đặt các câu lệnh expect ở đâu?. Việc này ảnh hưởng trực tiếp đến tính dễ đọc của file test và tính linh hoạt của framework 🏗️.

🏹  Cách 1: expect trong File Test (Cách phổ biến)

Đây là cách tiếp cận đơn giản nhất, nơi file test trực tiếp gọi expect trên các locators public của Page Object.

• Triển khai (tests/profile.spec.ts):

  test('Should show welcome message', async () => {
    await profilePage.goTo();
  
    // File test chịu trách nhiệm hoàn toàn về việc xác thực 🕵️
    await expect(profilePage.welcomeMessage).toContainText('Chào mừng');
  });
  

• Ưu điểm 👍:

  • Linh hoạt Tối đa: File test có thể thực hiện bất kỳ loại xác thực nào (toContainText, toHaveText, toBeVisible, toHaveAttribute, v.v.) mà không cần sửa đổi Page Object.

• Nhược điểm 👎:

  • "Ồn ào" (Noisy) 🔊: File test bị "lẫn lộn" giữa logic nghiệp vụ (gọi goTo()) và chi tiết kỹ thuật (gọi expect trên welcomeMessage).

  • Vi phạm nguyên tắc "One Assertion Per Test" (Một Xác thực mỗi Test) nếu lạm dụng.

📦 Cách 2: expect trong Page Object (Đóng gói Tối đa)

Cách tiếp cận này giấu hoàn toàn logic expect vào bên trong một phương thức helper của Page Object. Đây là một thực hành bị tranh cãi 🤔, vì nhiều chuyên gia cho rằng Page Object không nên chứa assertions.

• Triển khai (pages/profile.page.ts):

  async expectWelcomeMessageToContain(text: string) {
    // 'expect' được giấu bên trong hàm 🙈
    await expect(this.welcomeMessage).toContainText(text);
  }
  

• Triển khai (tests/profile.spec.ts):

   

  test('Should show welcome message', async () => {
    await profilePage.goTo();
  
    // File test đọc như một kịch bản, rất sạch sẽ ✨
    await profilePage.expectWelcomeMessageToContain('Chào mừng');
  });
  

• Ưu điểm 👍:

  • Dễ đọc Tối đa: File test trở nên cực kỳ sạch sẽ, đọc giống như tài liệu nghiệp vụ 📖.

• Nhược điểm 👎:

  • Kém Linh hoạt: Nếu một test khác muốn kiểm tra toHaveText (chính xác) hoặc toBeVisible, bạn sẽ phải tạo thêm các hàm helper mới (expectWelcomeMessageToHaveText, expectWelcomeMessageToBeVisible). Điều này làm "phình to" 🐡 Page Object.

  • Vi phạm SRP 🚫: Page Object giờ đây gánh thêm trách nhiệm "xác thực", vốn nên thuộc về file test.

🤝  Cách 3: Phương pháp Kết hợp (Khuyến nghị ✅)

Đây là cách tiếp cận cân bằng, tận dụng ưu điểm của cả hai cách trên.

Nguyên tắc:

1. Luôn cung cấp (expose) các locators quan trọng dưới dạng readonly public để file test có thể truy cập khi cần sự linh hoạt.

2. Cung cấp các hàm "expect helper" cho các trường hợp xác thực phổ biến nhất (chiếm 90% các test case) để giữ cho file test sạch sẽ trong hầu hết thời gian.

Ví dụ Code "Kết hợp"

File 1: pages/profile.page.ts (Cập nhật)

import { type Page, type Locator, expect } from '@playwright/test';
import { BasePage } from './base.page';

export class ProfilePage extends BasePage {
  
  // 1. LUÔN CUNG CẤP LOCATOR DƯỚI DẠNG PUBLIC 🔓
  readonly welcomeMessage: Locator;
  readonly editButton: Locator;

  constructor(page: Page) {
    super(page);
    this.welcomeMessage = page.locator('h1.welcome');
    this.editButton = page.locator('.edit-btn');
  }

  // 2. CUNG CẤP HELPER CHO CÁC CHECK PHỔ BIẾN 🎁
  async expectWelcomeMessageToContain(text: string) {
    await expect(this.welcomeMessage).toContainText(text);
  }
}

File 2: tests/profile.spec.ts (Minh họa sự linh hoạt)

// ... (khởi tạo profilePage trong beforeEach)

// Test 1: Dùng helper vì nó phổ biến 🌟
test('TC_01: Should contain welcome message', async () => {
  await profilePage.goTo();
  
  // 👍 Rất sạch sẽ và dễ đọc
  await profilePage.expectWelcomeMessageToContain('Chào mừng');
});

// Test 2: Dùng locator public vì có nhu cầu 'expect' đặc biệt 🔧
test('TC_02: Should check exact attribute of welcome message', async () => {
  await profilePage.goTo();
  
  // 👍 Vẫn linh hoạt khi cần thiết
  await expect(profilePage.welcomeMessage)
   .toHaveAttribute('data-testid', 'welcome-header');
});

🏁 Kết luận: Bằng cách cung cấp cả hai, bạn đạt được trạng thái lý tưởng: các file test của bạn sạch sẽ và dễ đọc trong 90% trường hợp, nhưng vẫn giữ được toàn bộ sự linh hoạt của expect cho 10% các trường hợp đặc biệt mà không cần phải làm "phình to" Page Object.

🚫 Phần 4: Phản Mẫu (Anti-Pattern) Cần Tránh: "Page Chaining" (Nối chuỗi Trang)

Một kỹ thuật thường được thảo luận trong POM là "Page Chaining" (còn gọi là Fluent API), nơi một phương thức hành động (như login()) trả về một thực thể của Page Object tiếp theo. Mặc dù điều này có vẻ hấp dẫn vì nó làm cho code trong file test trông "mượt mà", nhưng nó được coi là một phản mẫu (anti-pattern) ☠️ vì những lý do kiến trúc nghiêm trọng.

⛓️. Ví dụ về Phản mẫu Page Chaining

Đây là cách triển khai "Page Chaining" (Không khuyến nghị ❌):

// PHẢN MẪU: KHÔNG NÊN LÀM ❌
// trong pages/login.page.ts
import { HomePage } from './home.page.ts';

public async login(user, pass): Promise<HomePage> { // <-- Trả về HomePage
  await this.usernameInput.fill(user);
  await this.passwordInput.fill(pass);
  await this.loginButton.click();
  
  // Page Object này "biết" về Page Object tiếp theo
  return new HomePage(this.page); 
}

// trong tests/login.spec.ts
test('test', async ({ page }) => {
  const loginPage = new LoginPage(page);
  
  // Lời gọi test "fluent" 🌊
  const homePage = await loginPage.login('user', 'pass');
  await homePage.expectWelcomeMessage();
});

🔍 Phân tích Vấn đề Kiến trúc

Cách tiếp cận này vi phạm các nguyên tắc cốt lõi của thiết kế phần mềm tốt:

1. Vi phạm Nguyên tắc Đơn lẻ (Single Responsibility Principle - SRP) 🚫:

   • Trách nhiệm của LoginPage lẽ ra chỉ nên là: "Mô hình hóa các phần tử và hành vi trên trang đăng nhập".

   • Khi LoginPage trả về new HomePage(), nó đã gánh thêm một trách nhiệm thứ hai: "Quản lý và điều phối luồng điều hướng của ứng dụng".

   • Trách nhiệm điều phối (orchestration) này phải thuộc về Test Script (file *.spec.ts). File test mới là "nhạc trưởng" 🎼 quyết định luồng đi của nghiệp vụ.

2. Tạo ra Phụ thuộc Cứng (Tight Coupling) 🔗:

   • LoginPage.ts bây giờ phải import HomePage.ts. Điều này tạo ra một phụ thuộc cứng.

   • Nếu logic nghiệp vụ thay đổi (ví dụ: đăng nhập thành công giờ đây chuyển đến DashboardPage thay vì HomePage), bạn không chỉ phải sửa file test mà còn phải sửa cả class LoginPage - một class lẽ ra không liên quan gì đến DashboardPage.

3. Không thể Xử lý Điều hướng có Điều kiện 🔀:

   • Đây là vấn đề lớn nhất. Điều gì xảy ra nếu việc đăng nhập thất bại? Lẽ ra người dùng vẫn ở LoginPage.

   • Điều gì xảy ra nếu có 3 kết quả khả dĩ (ví dụ: trang chủ, trang đổi mật khẩu, trang đăng nhập thất bại)? Logic trả về trở nên cực kỳ phức tạp và không thể bảo trì.

🎻 . Giải pháp Khuyến nghị: "Test Orchestration" (Test điều phối)

Giải pháp "sạch" ✨ và tuân thủ đúng nguyên tắc Tách biệt Trách nhiệm là phương pháp đã được trình bày trong suốt bài nghiên cứu này:

• Page Object Methods trả về void: Các phương thức hành động (như login()) chỉ nên thực hiện hành động của chúng và trả về Promise<void>. Chúng "câm" 🤐 về việc điều hướng.

• Test Script là "Nhạc trưởng" (Orchestrator) 🎼: File test chịu trách nhiệm khởi tạo tất cả các Page Object mà nó cần (thường trong test.beforeEach) và quyết định khi nào sử dụng cái nào.

Ví dụ về Kiến trúc Tốt

// KIẾN TRÚC TỐT (Khuyến nghị ✅)
// trong pages/login.page.ts
public async login(user, pass): Promise<void> { // <-- Trả về void
  await this.usernameInput.fill(user);
  await this.passwordInput.fill(pass);
  await this.loginButton.click();
}

// trong tests/login.spec.ts
let loginPage: LoginPage;
let homePage: HomePage; // (hoặc ProfilePage, v.v.)

test.beforeEach(({ page }) => {
  loginPage = new LoginPage(page);   // <-- Test chịu trách nhiệm khởi tạo
  homePage = new HomePage(page);     // <-- Test chịu trách nhiệm khởi tạo
});

test('test', async () => {
  // 1. Hành động trên LoginPage
  await loginPage.login('user', 'pass');
  
  // 2. Test điều phối: "OK, hành động 1 đã xong."
  // "Bây giờ, tôi (file test) quyết định dùng HomePage để xác thực kết quả."
  await homePage.expectWelcomeMessage();
});

Cách tiếp cận này giữ cho các Page Object hoàn toàn độc lập, có thể tái sử dụng ♻️, tuân thủ SRP, và giúp cho việc bảo trì framework dễ dàng hơn rất nhiều trong dài hạn.

🧱 Phần 5: Phá vỡ Quy tắc? Phân tích "Vi phạm SRP" vì Lợi ích của Composition

 Chúng ta đã thảo luận về hai cách khởi tạo Component:

1. Toàn cục (Global) 🌐: Khởi tạo trong BasePage (ví dụ: HeaderComponent).

2. Cục bộ (Local) 🏠: Khởi tạo trong một Page Object cụ thể (ví dụ: TableComponent).

Một câu hỏi kiến trúc nâng cao được đặt ra: "Việc một Page Object tự khởi tạo component (Cách 2) có vi phạm Nguyên tắc Đơn lẻ (SRP) không?" 🤔

Bề ngoài, có vẻ là "Có". CRMDashboardPage dường như có hai trách nhiệm:

1. Định nghĩa locators/hành vi của trang CRM.

2. Khởi tạo SidebarMenuComponent.

Tuy nhiên, đây là một sự đánh đổi kiến trúc có chủ đích và là một thực hành tốt, tuân theo nguyên tắc "Ưu tiên Composition hơn Kế thừa" (Composition over Inheritance).

🧠 Phân tích Triết lý: Đâu mới là Trách nhiệm Thực sự?

Trách nhiệm thực sự của CRMDashboardPage không chỉ là "định nghĩa locator", mà là "Cung cấp một API hoàn chỉnh cho trang CRM Dashboard" 🎁.

Nếu trang CRM Dashboard thực sự có một Sidebar Menu, thì việc CRMDashboardPage chịu trách nhiệm cung cấp quyền truy cập vào SidebarMenuComponent là hoàn toàn nằm trong phạm vi trách nhiệm đơn lẻ của nó.

⚖️ So sánh các Lựa chọn Kiến trúc

Hãy xem xét một CRMDashboardPage và SalesDashboardPage đều cần SidebarMenuComponent, nhưng LoginPage thì không.

Lựa chọn 1 (Tồi 👎): Đưa SidebarMenuComponent vào BasePage

• BasePage khởi tạo HeaderComponent VÀ SidebarMenuComponent.

• LoginPage, CRMDashboardPage, SalesDashboardPage đều kế thừa BasePage.

• Vấn đề: LoginPage giờ đây cũng "thừa hưởng" một sidebarMenu mà nó không hề có trên UI. Điều này gây nhầm lẫn, phi logic và làm "phình to" (bloat) 🐡 mọi Page Object. Đây là một vi phạm kiến trúc nặng nề hơn.

Lựa chọn 2 (Tốt nhất 🏆): Composition Cục bộ

• BasePage chỉ khởi tạo các component thực sự toàn cục (ví dụ: HeaderComponent).

• Các Page Object khác kế thừa BasePage.

• Chỉ những trang cần SidebarMenuComponent mới tự khởi tạo nó.

Ví dụ Triển khai (Khuyến nghị ✅):

// pages/crmDashboard.page.ts
import { BasePage } from './base.page';
import { SidebarMenuComponent } from '../components/sidebarMenu.component';
import { type Page } from '@playwright/test';

export class CRMDashboardPage extends BasePage {
  // Trách nhiệm 1: Định nghĩa locators/hàm của riêng trang này
  readonly crmChart: Locator;
  
  // Trách nhiệm 2: Quản lý component cục bộ của nó
  readonly sidebarMenu: SidebarMenuComponent; // 👈 "Có một" SidebarMenu (Composition)

  constructor(page: Page) {
    super(page); // Kế thừa các thành phần toàn cục (như 'header') từ BasePage

    // Tự khởi tạo các component mà chỉ trang này (hoặc một nhóm) cần
    this.sidebarMenu = new SidebarMenuComponent(page);
    
    // Khởi tạo các locators của riêng trang này
    this.crmChart = page.locator('#crm-chart');
  }
  
  async getCRMChartData() {
    // ...
  }
}

🏁  Kết luận

Việc một Page Object cụ thể tự khởi tạo các Component Object (CPOM) mà nó chứa không phải là một vi phạm SRP. Đây là một ứng dụng trưởng thành của mẫu hình Composition, giúp:

• Giữ cho BasePage gọn gàng và chỉ chứa các thành phần thực sự toàn cục 🌐.

• Giữ cho các Page Object (như LoginPage) không bị "ô nhiễm" 😷 bởi các component mà chúng không có.

• Trao đúng trách nhiệm cho Page Object: "Mô hình hóa chính xác trang UI mà nó đại diện", bao gồm cả các component con của nó 👪.