[Playwright Typescript] Bài 22 - Khởi đầu thực chiến - Giải mã API với Playwright

🧩 GIẢI PHẪU: request FIXTURE LÀ CÁI QUÁI GÌ?

Trong Playwright, Fixture giống như "Hộp đồ nghề thần kỳ".

Mỗi khi bắt đầu một bài test (test(...)), Playwright sẽ phát cho bạn một hộp đồ nghề mới tinh. Bạn muốn dùng cái gì thì thò tay vào lấy cái đó ra (thông qua dấu { }).

• Muốn điều khiển trình duyệt? 👉 Lấy page.

• Muốn gọi API? 👉 Lấy request.

• Muốn biết tên bài test? 👉 Lấy testInfo.

Hình ảnh ví von: page vs. request 🚛 🏍️

Hãy tưởng tượng việc Gửi dữ liệu lên Server giống như việc Ship hàng.

🚛 page (Trình duyệt) = Xe Tải Hạng Nặng

• Đặc điểm: Nó phải chở theo cả đống thứ: Hình ảnh, CSS, Font chữ, Quảng cáo, JavaScript chạy ngầm...

• Quy trình: Phải nổ máy, mở cửa thùng xe, bốc xếp hàng, lái đi từ từ, đợi đèn đỏ (render UI).

• Tốc độ: Chậm chạp, cồng kềnh.

• Dùng khi: Bạn cần kiểm tra xem "Hàng hóa có được bọc đẹp không?" (Test giao diện).

🏍️ request (API Context) = Xe Máy Shipper (Ninja Lead)

• Đặc điểm: Chỉ chở đúng Gói hàng (Data JSON). Không chở hình ảnh, không chở giao diện.

• Quy trình: Vặn ga là bay. Luồn lách siêu nhanh. Đi đường tắt (Gửi thẳng đến Server).

• Tốc độ: Tốc độ ánh sáng.

• Dùng khi: Bạn chỉ cần quan tâm "Hàng có đến nơi an toàn không?" (Test Logic/Data).

👉 Kết luận: request fixture chính là chiếc xe máy đó. Nó được Playwright độ riêng để chạy API siêu tốc mà không cần bật cái trình duyệt nặng nề lên.

 "Under the Hood" (Bên trong nó có gì?)

Khi bạn viết async ({ request }) => { ... }, Playwright âm thầm làm 3 việc này cho bạn:

✅ 1. Tự động "Học bài" từ Config

Nó sẽ đọc file playwright.config.ts.

• Nếu bạn cài baseURL: 'https://reqres.in', nó tự nhớ. Lúc code bạn chỉ cần gõ /api/users, nó tự ghép vào.

• Nếu bạn cài extraHTTPHeaders (ví dụ Token), nó tự động đeo cái Token đó vào mọi request.
  
  

✅ 2. Tạo môi trường Độc lập (Isolation) - Cực quan trọng!

Đây là điểm "ăn tiền" so với dùng thư viện ngoài (như Axios).

• Mỗi bài test = 1 request mới tinh.

• Bài test 1 bạn đăng nhập (có Cookie A).

• Bài test 2 Playwright sẽ hủy cái request cũ, tạo cái mới. Cookie A biến mất.

• 👉 Tác dụng: Đảm bảo bài test này không làm ảnh hưởng bài test kia (No Flaky Tests).
  
  

✅ 3. Quản lý Cookies & Storage

Nó thông minh hơn curl. Nếu trong cùng 1 bài test, bạn gọi API Login thành công, server trả về Cookie. Thì các lệnh gọi API tiếp theo trong bài đó sẽ tự động mang theo Cookie đó.

🩺Phần 4: SOFT ASSERTION - KHÁM TỔNG QUÁT

Vấn đề của expect thường (Hard Assertion)

Hãy tưởng tượng bạn đi khám sức khỏe với quy trình "Khắt khe" (Hard Assertion):

1. Bác sĩ kiểm tra mắt: Tốt.

2. Bác sĩ kiểm tra mũi: Bị viêm xoang! -> DỪNG LẠI! ĐUỔI VỀ LUÔN! ❌

Hậu quả: Bạn về nhà chữa xoang xong. Hôm sau đến khám tiếp.

3. Bác sĩ kiểm tra họng: Bị đau họng! -> DỪNG TIẾP! ĐUỔI VỀ! ❌

👉 Kết luận: Nếu dùng expect() thường, bạn phải chạy đi chạy lại Test rất nhiều lần mới sửa hết lỗi. Test chết ngay tại lỗi đầu tiên.

Giải pháp expect.soft (Soft Assertion)

Quy trình "Linh hoạt" (Soft Assertion):

1. Bác sĩ kiểm tra mắt: Tốt.

2. Bác sĩ kiểm tra mũi: Viêm xoang -> Bác sĩ ghi vào sổ, nhưng vẫn khám tiếp.

3. Bác sĩ kiểm tra họng: Đau họng -> Bác sĩ ghi vào sổ, khám tiếp.

4. ... Khám hết toàn thân ...

5. KẾT LUẬN CUỐI CÙNG: "Bạn bị bệnh (Fail), danh sách bệnh gồm: Mũi, Họng..."

👉 Tác dụng: Chạy test MỘT LẦN DUY NHẤT, bắt được TOÀN BỘ LỖI.

 Phân tích Code 

test('Demo 10 Soft Assertions (So sánh với expect thường)', async ({ request }) => {
  const response = await request.get('/posts/1');
  const body = await response.json();



  console.log('🏁 BẮT ĐẦU CHẠY 10 ASSERTIONS...');


  // ✅ 1. Check ID (ĐÚNG)
  expect.soft(body.id, { message: 'Assertion #1: id phải là 1' }).toBe(1);

  // ✅ 2. Check UserId (ĐÚNG)
  expect.soft(body.userId, { message: 'Assertion #2: userId phải là 1' }).toBe(1);

  // ❌ 3. Check ID (CỐ TÌNH SAI)
  expect.soft(body.id, { message: 'Assertion #3: id phải là 999 (CỐ TÌNH SAI)' }).toBe(999);

  // ✅ 4. Check Title (ĐÚNG)
  expect.soft(body.title, { message: 'Assertion #4: title chứa "sunt aut"' }).toContain('sunt aut');

  // ❌ 5. Check Title (CỐ TÌNH SAI)
  expect.soft(body.title, { message: 'Assertion #5: title chứa ABCXYZ (CỐ TÌNH SAI)' }).toContain('ABCXYZ');

  // ✅ 6. Check Type (ĐÚNG)
  expect.soft(typeof body.body, { message: 'Assertion #6: body phải là string' }).toBe('string');

  // ❌ 7. Check UserId (CỐ TÌNH SAI)
  expect.soft(body.userId, { message: 'Assertion #7: userId phải là 999 (CỐ TÌNH SAI)' }).toBe(999);

  // ✅ 8. Check Property (ĐÚNG)
  expect.soft(body, { message: 'Assertion #8: có thuộc tính title' }).toHaveProperty('title');

  // ❌ 9. Check Property (CỐ TÌNH SAI)
  expect.soft(body, { message: 'Assertion #9: có fakeProperty (CỐ TÌNH SAI)' }).toHaveProperty('fakeProperty');

  // ✅ 10. Check GreaterThan (ĐÚNG)
  expect.soft(body.id, { message: 'Assertion #10: id > 0' }).toBeGreaterThan(0);



  console.log('🏁 Test đã chạy HẾT 10 assertions!');
  console.log('📊 Nếu dùng expect() thường, test sẽ dừng ở lỗi #3');
  console.log('📊 Với expect.soft(), bạn thấy được TẤT CẢ 4 lỗi: #3, #5, #7, #9');
});

Hãy cùng "mổ xẻ" luồng chạy của nó:

🛑 Nếu dùng expect() thường (Hard Assertion)

// Dòng này Fail (#3)
expect(body.id).toBe(999); 

// 💀 CHƯƠNG TRÌNH CRASH TẠI ĐÂY!
// Các dòng dưới (#4, #5...) KHÔNG BAO GIỜ ĐƯỢC CHẠY.
// Console.log cuối cùng cũng không hiện ra.

✅ Khi dùng expect.soft() 

Chương trình sẽ chạy băng băng từ đầu đến cuối như một chiếc xe tăng:

1. Assertion #1, #2: ✅ Pass (Êm ru).

2. Assertion #3: ❌ FAIL! (Nhưng Playwright chỉ đánh dấu "Có lỗi" rồi chạy tiếp).

3. Assertion #4: ✅ Pass.

4. Assertion #5: ❌ FAIL! (Lại ghi sổ).

5. ... chạy tiếp đến #10 ...

6. Cuối cùng: In ra dòng console.log('🏁 Test đã chạy HẾT...').

7. Báo cáo: Playwright đánh dấu Test Case này là FAILED và liệt kê danh sách 4 tội đồ: #3, #5, #7, #9.

Khi nào NÊN và KHÔNG NÊN dùng?

Không phải lúc nào cũng dùng soft đâu nhé.

👍 NÊN DÙNG (Cho API & Form Data)

Khi các dữ liệu độc lập với nhau.

• Ví dụ: Kiểm tra Response API User.

  • Tên đúng không?

  • Email đúng không?

  • Tuổi đúng không?

  • 👉 Nếu tên sai thì cứ kiểm tra tiếp email. Đừng dừng lại. Code của bạn chính là trường hợp này.
    
    

👎 KHÔNG NÊN DÙNG (Cho Critical Flow)

Khi bước sau phụ thuộc vào bước trước.

• Ví dụ:

  1. API Login (expect token trả về).

  2. API Lấy thông tin User (Dùng token trên).

  • 👉 Nếu bước 1 (Login) đã Fail rồi, thì bước 2 chạy làm gì nữa cho tốn thời gian? Lúc này bắt buộc phải dùng expect thường để chặn ngay.

5. Kết quả hiển thị trong Report

Khi chạy đoạn code trên, màn hình Terminal hoặc HTML Report sẽ trông rất "hoành tráng" như sau:

Error: 
  1. Assertion #3: id phải là 999 (CỐ TÌNH SAI)
     Expected: 999
     Received: 1

  2. Assertion #5: title chứa ABCXYZ (CỐ TÌNH SAI)
     Expected substring: "ABCXYZ"
     Received string:    "sunt aut facere..."

  3. Assertion #7: userId phải là 999 (CỐ TÌNH SAI)
     Expected: 999
     Received: 1

  4. Assertion #9: có fakeProperty (CỐ TÌNH SAI)
     Expected: object to have property "fakeProperty"

👉 Giá trị:  nhìn vào đây phát là biết ngay API đang hỏng ở những chỗ nào, sửa một lèo là xong.