[Playwright Typescript] Bài 20 - PLAYWRIGHT DEEP DIVE: Kiến trúc process, Data-driven và tối ưu song song

📘 Phần 3: CẨM NANG: CHIẾN LƯỢC CỐ ĐỊNH DỮ LIỆU (DATA FIXATION)

Từ cơ chế "Main đọc trước, Worker đọc sau" và sự tách biệt bộ nhớ, chúng ta rút ra NGUYÊN TẮC VÀNG cho Playwright:

"Dữ liệu dùng để SINH test (Parameters) phải là DỮ LIỆU TĨNH (Static) hoặc ĐỒNG BỘ (Synchronous) tại thời điểm chạy lệnh."

Tại sao lại khắt khe như vậy? Hãy cùng đi sâu vào "trái tim" của hệ thống.

Bản Chất Kiến Trúc: Sự "Lệch Pha" Tiềm Ẩn

Playwright hoạt động dựa trên mô hình Đa Tiến Trình Cô Lập (Isolated Multi-Process):

1. Main Process: Chỉ quản lý, lên danh sách.

2. Worker Process: Thực thi logic, chạy trình duyệt.

Vấn đề nằm ở chỗ: Hai tiến trình này không chia sẻ bộ nhớ. Để cả hai cùng hiểu một file test, chúng buộc phải ĐỌC FILE ĐÓ 2 LẦN ở 2 thời điểm khác nhau.

Chính sự chênh lệch thời gian này tạo ra rủi ro nếu dữ liệu của bạn không cố định.

Giải Mã Qua Mô Hình: "Phát Vé - Soát Vé" 🎟️

Để hiểu rõ tại sao API/Random gây lỗi, hãy tưởng tượng quy trình chạy test như một rạp chiếu phim:

• Tấm Vé = Tiêu đề bài test (Ví dụ: Login: Case A). Đây là thứ duy nhất Main chuyển cho Worker.

• Danh sách khách = Dữ liệu đầu vào (users = ['A', 'B']).
  
  

✅ Kịch bản Chuẩn (Happy Path)

Cả hai bên cùng sử dụng một Danh sách khách cố định (Static Data).

1. Main Process (Người Phát Vé):

   • Mở danh sách khách cố định. Thấy khách A.

   • In ra tấm vé: "Login: Case A".

   • Gửi vé này xuống cổng kiểm soát.

2. Worker Process (Người Soát Vé):

   • Tự mở danh sách khách cố định (Load lại file). Cũng thấy khách A.

   • Tự in ra tấm vé: "Login: Case A".

   • Khớp Lệnh: Worker nhận vé từ Main, so với vé mình vừa in -> TRÙNG KHỚP.

   • 👉 Mời vào (Chạy test).
     
     

❌ Kịch bản Lỗi (Khi dùng Data Động / API / Random)

Dữ liệu thay đổi theo thời gian hoặc không ổn định.

1. Main Process (Lúc 8:00):

   • Gọi API/Random -> Ra khách A.

   • In vé: "Login: Case A". Gửi đi.

2. Worker Process (Lúc 8:01):

   • Load lại file. Gọi lại API/Random.

   • Do mạng lag hoặc thuật toán random -> Ra khách B.

   • Nó in ra vé của riêng nó: "Login: Case B".

3. Hậu quả (Mâu thuẫn):

   • Worker cầm vé Main đưa (Case A).

   • Worker nhìn vào danh sách vé của mình (Case B).

   • Worker hét lên: "Vé giả! Trong danh sách của tao làm gì có Case A?"

   • 👉 Lỗi: Test not found hoặc Worker failed to load test.

import { test } from '@playwright/test';

// ❌ SAI LẦM CHẾT NGƯỜI: Sinh số ngẫu nhiên ở Top-level
// Biến này sẽ được tính toán LẠI mỗi khi file được load
const luckyNumber = Math.floor(Math.random() * 100); 

// Đặt tên test dựa trên số ngẫu nhiên này
test(`Test Vé Số: ${luckyNumber}`, async ({ page }) => {
  console.log('Tôi trúng số rồi!');
});

// ❌ SAI LẦM: Dùng thời gian thực
const timestamp = Date.now(); 

test(`Test lúc: ${timestamp}`, async ({ page }) => { ... });

3. Giải Pháp: Chiến Lược Cố Định Dữ Liệu

Để tránh thảm họa trên, chúng ta có 2 chiến lược để đảm bảo Danh sách khách là bất biến.

🛡️ Chiến Lược 1: Static Data (Code/JSON) - Khuyên Dùng

Dữ liệu nằm cứng trong file. Dù đọc 1 tỷ lần thì 'A' vẫn là 'A'.

• Cách làm: Import trực tiếp file .json hoặc biến const trong .ts.

• Ưu điểm: Nhanh, đồng bộ tuyệt đối.

🔄 Chiến Lược 2: Dynamic via Pre-Script (Bước đệm)

Nếu data bắt buộc phải lấy từ Server (API/DB):

1. Bước 1 (Pre-script): Chạy một script riêng trước khi chạy test. Script này gọi API và ghi kết quả xuống file data.json.

2. Bước 2 (Test Run): Playwright đọc file data.json đó. (Lúc này Động đã hóa thành Tĩnh).
   
   

4. Triển Khai Code Chuẩn Kiến Trúc

import { test, expect } from '@playwright/test';

// ============================================================
// 1️⃣ CHUẨN BỊ DỮ LIỆU CỨNG (STATIC DATA)
// ============================================================
// Đây chính là "Danh sách khách mời" cố định.
// Main Process và Worker Process đều nhìn thấy mảng này y hệt nhau.
const TEST_CASES = [
  {
    id: 'TC01',
    description: 'Đăng nhập thành công (Standard User)',
    username: 'standard_user',
    password: 'secret_sauce',
    shouldPass: true,
  },
  {
    id: 'TC02',
    description: 'User bị khóa (Locked Out)',
    username: 'locked_out_user',
    password: 'secret_sauce',
    shouldPass: false,
    expectedError: 'Epic sadface: Sorry, this user has been locked out.'
  },
  {
    id: 'TC03',
    description: 'Sai mật khẩu',
    username: 'standard_user',
    password: 'wrong_password',
    shouldPass: false,
    expectedError: 'Epic sadface: Username and password do not match any user in this service'
  },
  {
    id: 'TC04',
    description: 'Bỏ trống Username',
    username: '',
    password: 'secret_sauce',
    shouldPass: false,
    expectedError: 'Epic sadface: Username is required'
  }
];

// ============================================================
// 2️⃣ SINH TEST TỰ ĐỘNG (PARAMETERIZED)
// ============================================================
test.describe('SauceDemo Login Data-Driven', () => {

  // Vòng lặp chạy ngay khi Main Process quét file
  for (const data of TEST_CASES) {

    // Tạo tên test DUY NHẤT bằng cách ghép ID + Description
    test(`[${data.id}] ${data.description}`, async ({ page }) => {
      
      // --- BƯỚC 1: Truy cập trang ---
      await page.goto('https://www.saucedemo.com/');

      // --- BƯỚC 2: Điền dữ liệu (Nếu có) ---
      // Nếu data.username rỗng thì thôi không điền (để test case bỏ trống)
      if (data.username) {
        await page.locator('[data-test="username"]').fill(data.username);
      }
      
      if (data.password) {
        await page.locator('[data-test="password"]').fill(data.password);
      }

      // --- BƯỚC 3: Click Login ---
      await page.locator('[data-test="login-button"]').click();

      // --- BƯỚC 4: Kiểm tra kết quả (Assertion) ---
      if (data.shouldPass) {
        // ✅ Kịch bản mong đợi Thành Công
        // Check URL đổi sang trang inventory
        await expect(page).toHaveURL(/.*inventory.html/);
        
        // Check tiêu đề "Products" hiện ra
        await expect(page.locator('.title')).toHaveText('Products');
        
      } else {
        // ❌ Kịch bản mong đợi Lỗi (Negative)
        // Tìm cái thông báo lỗi màu đỏ
        const errorMsg = page.locator('[data-test="error"]');
        
        await expect(errorMsg).toBeVisible();
        await expect(errorMsg).toHaveText(data.expectedError!); // Dấu ! là báo TS biến này chắc chắn có
      }

    });
  }

});

🔍 Phân tích tại sao ví dụ này "Chuẩn Kiến Trúc"

Dù đơn giản, nhưng nó tuân thủ mọi nguyên tắc:

1. Dữ liệu Tĩnh (TEST_CASES):

   • Được khai báo bằng const ngay đầu file.

   • Không gọi API, không Random.

   • => Main Process và Worker Process đảm bảo nhìn thấy 4 test case y hệt nhau.

2. Định danh Duy nhất:

   • Tên test: [TC01] Đăng nhập thành công....

   • Không bao giờ bị trùng tên, giúp Report rõ ràng.

3. Logic "Rẽ Nhánh" (if/else):

   • Chúng ta dùng chung 1 logic fill/click.

   • Nhưng phần Assertion (kiểm tra) được tách ra dựa vào biến shouldPass.

   • Cách này giúp tận dụng code (Code Reuse) tối đa.

Áp dụng vào hệ thống AnhCRM

import { test, expect } from '@playwright/test';
// Import Helper và Data Catalog từ file index
import { testDataCatalog, getTestDataSimple } from './data/index';

// Reset storage để đảm bảo mỗi test chạy sạch sẽ
test.use({ storageState: { cookies: [], origins: [] } });

// ============================================================
// 🔍 GIAI ĐOẠN 1: PARSE & PLAN (Main & Worker cùng chạy)
// ============================================================
// Giai đoạn này chạy siêu nhanh, chỉ xử lý logic trên RAM để chia nhóm test

console.log(`📦 [PARSE] Loading keys from testDataCatalog... (PID: ${process.pid})`);

const loginCases = testDataCatalog.loginCases;
type LoginCaseKey = keyof typeof loginCases;

// 1. Lấy toàn bộ Keys
const allKeys = Object.keys(loginCases) as LoginCaseKey[];

// 2. Chia nhóm Positive/Negative ngay lập tức (Static Logic)
// Main Process dùng cái này để biết test nào thuộc Group nào
const positiveKeys = allKeys.filter(key => loginCases[key].data.expectedResult === 'success');
const negativeKeys = allKeys.filter(key => loginCases[key].data.expectedResult === 'error');

console.log(`   👉 Found ${positiveKeys.length} positive cases.`);
console.log(`   👉 Found ${negativeKeys.length} negative cases.`);


// ============================================================
// 🧪 GIAI ĐOẠN 2: TEST GENERATION (Main ghi danh)
// ============================================================

// --- GROUP 1: POSITIVE CASES (@smoke) ---
test.describe('Login - Positive Cases', { tag: '@smoke' }, () => {
  
  for (const key of positiveKeys) {
    // Lấy description để đặt tên Test (Chỉ lấy metadata, chưa clone data nặng)
    const { description } = loginCases[key];

    test(`${key}: ${description}`, async ({ page }) => {
      
      // ======================================================
      // 🚀 GIAI ĐOẠN 3: EXECUTION (Chỉ Worker chạy)
      // ======================================================
      // Clone data mới tinh cho bài test này.
      // Đảm bảo không bị "nhiễm bẩn" từ các bài test khác.
      const testData = getTestDataSimple('loginCases', key);

      console.log(`▶️ Running Positive Case: ${key}`);

      await page.goto('/admin/authentication');
      await page.locator('#email').fill(testData.email);
      await page.locator('#password').fill(testData.password);
      await page.getByRole('button', { name: 'Login' }).click();
      
      // Verify redirect (Ép kiểu nhẹ vì ta biết chắc chắn đây là success case)
      await expect(page).toHaveURL(new RegExp((testData as any).expectedUrl));
    });
  }
});


// --- GROUP 2: NEGATIVE CASES (@regression) ---
test.describe('Login - Negative Cases', { tag: '@regression' }, () => {
  
  for (const key of negativeKeys) {
    const { description } = loginCases[key];

    test(`${key}: ${description}`, async ({ page }) => {
      
      // Clone data mới tinh
      const testData = getTestDataSimple('loginCases', key);
      
      console.log(`▶️ Running Negative Case: ${key}`);

      await page.goto('/admin/authentication');
      
      const emailInput = page.locator('#email');
      const passwordInput = page.locator('#password');
      
      // Xử lý điền dữ liệu (có thể rỗng)
      await emailInput.fill(testData.email);
      await passwordInput.fill(testData.password);
      await page.getByRole('button', { name: 'Login' }).click();
      
      // --- LOGIC CHECK LỖI ---
      // Dùng (testData as any) để truy cập các trường đặc thù của negative case
      const validationType = (testData as any).validationType;
      const expectedError = (testData as any).expectedError;

      if (validationType === 'browser') {
        // Case 1: Browser Validation (HTML5 Bubble)
        
        // Check 1: Input phải ở trạng thái invalid
        const isInvalid = await emailInput.evaluate((el: HTMLInputElement) => !el.validity.valid);
        expect(isInvalid).toBe(true);
        
        // Check 2: Message trình duyệt
        const validationMessage = await emailInput.evaluate((el: HTMLInputElement) => el.validationMessage);
        // Lưu ý: Message trình duyệt phụ thuộc ngôn ngữ OS, nên dùng toContain cho an toàn
        expect(validationMessage).toContain(expectedError);
        
      } else {
        // Case 2: Server Validation (Alert Box)
        // Locator này tùy dự án, ví dụ check alert chung
        const alertBox = page.locator('.alert-danger, .alert-warning, div[role="alert"]');
        await expect(alertBox).toBeVisible();
        await expect(alertBox).toContainText(expectedError);
      }
      
      // Verify vẫn đứng yên ở trang login
      await expect(page).toHaveURL(/authentication/);
    });
  }
});

5. Tại sao cấu trúc này "Bất Tử"?

1. Sự Nhất Quán (Consistency):

   Nhờ loginTestKeys được lấy từ nguồn tĩnh (testDataCatalog), Main và Worker luôn nhìn thấy cùng một bản danh sách. Tấm vé Main phát ra luôn tìm thấy người nhận ở phía Worker.

2. Hiệu Suất (Efficiency):

   • Main Process: Chỉ thao tác với mảng string (keys) rất nhẹ. Quét 1000 test case trong tích tắc.

   • Worker Process: Chỉ khi nào chạy test nào thì mới clone data nặng của test đó. Không chiếm dụng RAM vô ích.

Khả Năng Truy Vết (Traceability):

Tên bài test được gắn cứng với Key và Description. Dù bạn chạy lại bao nhiêu lần, lịch sử test trên Report/CI vẫn thẳng tắp, không bị nhảy lung tung như khi dùng random ID.

🕵️ Phần 4: GIẢI PHẪU QUY TRÌNH CHẠY TEST (THE LIFECYCLE)

Với Parameterized Testing (sinh ra 10, 20 hay 100 test case từ data), nếu chạy tuần tự (cái này xong mới tới cái kia) thì rất lâu. Chạy Parallel (Song song) sẽ giúp tốc độ nhanh gấp N lần (N = số lượng Worker/CPU của máy).

Hãy tưởng tượng hệ thống Playwright là một Nhà Hàng Lớn.

• Bạn (User): Là khách hàng, người bấm nút gọi món (npx playwright test).

• Main Process: Là Quản Lý Nhà Hàng (Chỉ điều phối, không nấu ăn).

• Worker Process: Là Đầu Bếp (Người trực tiếp nấu ăn - chạy test).

• File Test (.spec.ts): Là Cuốn Sách Công Thức.
  
  

import { defineConfig } from '@playwright/test';

export default defineConfig({
  // Thuê đúng 4 đầu bếp cứng
  workers: 4, 
  
  // HOẶC: Thuê dựa trên phần trăm sức mạnh máy tính (50%)
  // workers: '50%', 
});​

import { defineConfig } from '@playwright/test';

export default defineConfig({
testDir: './tests/demo-parallel', // Gom vào 1 folder chạy cho dễ

// ⛔ QUAN TRỌNG: Ép chạy đúng 2 công nhân
workers: 2,

// Tắt cái này để Playwright phân chia theo FILE (File A xong mới đến File khác)
fullyParallel: false,

reporter: 'list', // Để xem log chạy realtime cho sướng
use: {
headless: true,
},
});​

import { test } from '@playwright/test';

test('Test 01 (Nhanh)', async ({ page }, testInfo) => {
console.log(`🚀 [Worker ${testInfo.workerIndex}] BẮT ĐẦU: 01_fast.spec.ts`);

// Giả vờ làm việc 2 giây
await new Promise(resolve => setTimeout(resolve, 2000));

console.log(`✅ [Worker ${testInfo.workerIndex}] KẾT THÚC: 01_fast.spec.ts`);
});​

import { test } from '@playwright/test';

test('Test 02 (Siêu Chậm)', async ({ page }, testInfo) => {
console.log(`🐢 [Worker ${testInfo.workerIndex}] BẮT ĐẦU: 02_slow.spec.ts (Xui xẻo vớ phải bài nặng)`);

// Giả vờ làm việc 10 giây
test.setTimeout(15000); // Tăng timeout kẻo bị fail
await new Promise(resolve => setTimeout(resolve, 10000));

console.log(`✅ [Worker ${testInfo.workerIndex}] KẾT THÚC: 02_slow.spec.ts`);
});
​

import { test } from '@playwright/test';

test('Test 03 (Nhanh)', async ({ page }, testInfo) => {
console.log(`🚀 [Worker ${testInfo.workerIndex}] BẮT ĐẦU: 03_fast.spec.ts`);
await new Promise(resolve => setTimeout(resolve, 2000));
console.log(`✅ [Worker ${testInfo.workerIndex}] KẾT THÚC: 03_fast.spec.ts`);
});​

import { test } from '@playwright/test';

test('Test 04 (Nhanh)', async ({ page }, testInfo) => {
console.log(`🚀 [Worker ${testInfo.workerIndex}] BẮT ĐẦU: 04_fast.spec.ts`);
await new Promise(resolve => setTimeout(resolve, 2000));
console.log(`✅ [Worker ${testInfo.workerIndex}] KẾT THÚC: 04_fast.spec.ts`);
});
​