Chạy test song song & giữ test độc lập cho người mới (có code Playwright chạy được)

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

Chào bạn mới! Khi bộ test tự động của bạn còn ít — vài test, mười test — chạy tuần tự (test này xong mới tới test kia) không phải vấn đề lớn, chỉ mất vài phút. Nhưng khi bộ test lớn dần lên hàng chục, hàng trăm test, chạy tuần tự có thể mất cả tiếng đồng hồ, làm chậm cả pipeline CI/CD và khiến cả đội phải chờ. Câu trả lời là chạy test song song — nhưng chạy test song song CHỈ an toàn khi mọi test đều độc lập với nhau. Bài này sẽ giúp bạn hiểu rõ hai khái niệm đi liền nhau này: chạy test song song và giữ test độc lập, qua ví dụ thật của ShopEasy, có hình minh hoạ và code Playwright chạy được.

2. Vấn đề: chạy tuần tự 100 test quá lâu

Hãy hình dung bộ test ShopEasy có 120 test: đăng nhập, tìm kiếm sản phẩm, thêm giỏ hàng, thanh toán, huỷ đơn... Nếu chạy tuần tự — Playwright mở trình duyệt, chạy xong test 1, đóng lại, mở lại cho test 2, cứ thế lần lượt — mỗi test trung bình mất 20 giây thì 120 test sẽ mất khoảng 40 phút. Với một đội chạy CI mỗi lần push code, 40 phút chờ đợi mỗi lần là con số rất lớn, làm chậm cả vòng lặp phát triển.

Vấn đề không chỉ là 'chờ lâu' — nó còn ảnh hưởng tới thói quen của cả đội. Khi CI chạy quá lâu, lập trình viên có xu hướng gộp nhiều commit lại trước khi push, hoặc bỏ qua việc chờ kết quả test mà merge luôn, làm giảm giá trị của automation. Giải pháp tự nhiên là chạy nhiều test cùng lúc bằng nhiều worker (chạy song song) — nhưng làm vậy an toàn hay không phụ thuộc hoàn toàn vào việc các test có ĐỘC LẬP với nhau hay không, điều ta sẽ tìm hiểu ngay sau đây.

3. Test độc lập là gì & vì sao quan trọng

Một test được coi là ĐỘC LẬP khi kết quả pass/fail của nó không phụ thuộc vào: (1) test nào đã chạy trước nó, (2) test nào sẽ chạy sau nó, và (3) test đó chạy một mình hay chạy cùng lúc với các test khác. Nói cách khác, dù bạn chạy test này đầu tiên, cuối cùng, hay chạy song song với 10 test khác — kết quả luôn giống nhau, vì test tự lo liệu đủ mọi thứ nó cần (dữ liệu, trạng thái đăng nhập, môi trường) mà không dựa vào 'may mắn' rằng test khác đã chuẩn bị sẵn.

Vì sao điều này quan trọng đến mức được coi là nguyên tắc nền tảng của automation? Vì test tự động chỉ có giá trị khi bạn TIN TƯỞNG được kết quả của nó. Nếu một test có thể pass hôm nay, fail ngày mai chỉ vì thứ tự chạy đổi khác (do CI chọn ngẫu nhiên, do chạy song song, do có người thêm test mới ở giữa), cả đội sẽ dần mất niềm tin vào bộ test, coi 'fail' là chuyện bình thường và bỏ qua — đây chính là lúc automation mất hết ý nghĩa vốn có của nó.

4. Nguyên tắc: không chia sẻ trạng thái giữa các test

Nguồn gốc phổ biến nhất khiến test mất độc lập là CHIA SẺ TRẠNG THÁI (shared state): nhiều test cùng đọc/ghi lên cùng một tài khoản, cùng một sản phẩm, hay cùng một biến toàn cục trong code test. Ví dụ ở ShopEasy: nếu 'test thêm sản phẩm vào giỏ' và 'test xoá sản phẩm khỏi giỏ' cùng thao tác trên MỘT tài khoản 'test@shopeasy.vn' cố định, thứ tự chạy sẽ quyết định giỏ hàng đang có gì — test nào chạy sau sẽ 'thừa hưởng' trạng thái không đoán trước được từ test chạy trước.

Nguyên tắc để tránh điều này: mỗi test nên có 'sân chơi' riêng — tài khoản riêng, sản phẩm riêng, đơn hàng riêng — thay vì dùng chung dữ liệu cố định. Ngoài dữ liệu, cũng cần tránh chia sẻ trạng thái trình duyệt: mỗi test nên chạy trong một browser context riêng (Playwright tự làm điều này mặc định cho mỗi test), không tái sử dụng cookie/session đăng nhập từ test trước để lại nếu không chủ đích. Không chia sẻ trạng thái là điều kiện cần để đạt được test độc lập ở chương trước.