1. Tóm tắt nhanh & pipeline bạn sẽ dựng
Chào bạn mới! Ở bài Page Object Model, bạn đã học cách viết script Playwright chạy được trên máy cá nhân. Nhưng script chạy tốt trên máy bạn không có nghĩa là dự án đã an toàn — nếu chỉ có bạn biết chạy nó, và chỉ chạy khi bạn nhớ, thì code lỗi vẫn có thể lọt vào nhánh chính bất cứ lúc nào đồng đội khác quên chạy test. Đây chính là lý do cần chạy test trên CI/CD (Continuous Integration/Continuous Delivery): biến việc chạy test từ 'thói quen cá nhân' thành 'quy trình tự động, luôn xảy ra' mỗi khi có push hoặc Pull Request. Chúng ta sẽ học qua pipeline thật của ShopEasy, dùng GitHub Actions — công cụ CI miễn phí, tích hợp sẵn trong GitHub.
2. Vấn đề & vì sao chạy test trên CI quan trọng
Hãy hình dung nhóm ShopEasy có 5 lập trình viên, mỗi người viết code trên nhánh riêng rồi mở Pull Request để merge vào main. Nếu quy trình chỉ dựa vào việc 'mỗi người tự chạy test trước khi push', điều gì xảy ra khi một người đang gấp deadline, quên chạy, hoặc chỉ chạy đúng phần code mình sửa mà bỏ sót ảnh hưởng tới phần khác? Test có thể vẫn tồn tại trong repo, đầy đủ và chạy được — nhưng nếu không ai bắt buộc chạy nó, nó chẳng khác gì không tồn tại.
Vấn đề còn sâu hơn: ngay cả khi ai đó có chạy test, máy của họ có thể khác máy của người khác — phiên bản Node.js khác, đã cài sẵn trình duyệt từ trước, hoặc có biến môi trường 'may mắn' đúng. Test 'pass trên máy tôi' không đảm bảo pass trên máy đồng đội, và càng không đảm bảo pass trên môi trường sẽ deploy thật. Đây là lý do cần một nơi chạy test THỐNG NHẤT, TỰ ĐỘNG, và KHÔNG PHỤ THUỘC vào việc ai đó có nhớ hay không — đó chính là CI.
CI/CD gồm 2 phần: Continuous Integration (CI) — tự động build và chạy test mỗi khi có thay đổi code; và Continuous Delivery/Deployment (CD) — tự động đưa code đã qua kiểm tra tới môi trường staging/production. Bài này tập trung vào phần CI, cụ thể là cách kích hoạt Playwright chạy tự động. Về bản chất, một máy chủ CI như GitHub Actions sẽ: nhận sự kiện (push/Pull Request), khởi tạo một máy ảo 'sạch', cài đặt dự án từ đầu, chạy test, rồi báo kết quả — tất cả không cần con người can thiệp.
Nếu bạn muốn đi làm vị trí Automation Tester hoặc SDET, kỹ năng đọc hiểu và chỉnh sửa workflow CI/CD gần như là bắt buộc — vì hầu hết công ty hiện nay đều chạy test tự động trên pipeline, không còn chạy tay đơn thuần. Nội dung automation & CI/CD testing được dạy bài bản, có dự án thực chiến, trong khoá Software Testing chuyên nghiệp (Manual + Automation) của CyberSoft Academy: https://cybersoft.edu.vn/software-testing-chuyen-nghiep-tu-zero-toi-duoc-nhan-viec-manual-automation-testing/
3. Cấu trúc workflow YAML cơ bản của GitHub Actions
Một workflow GitHub Actions là 1 file YAML nằm trong thư mục .github/workflows/ của repo. File này có 3 phần chính: 'name' (tên workflow, hiển thị trên GitHub), 'on' (khai báo sự kiện nào kích hoạt, ví dụ push hoặc pull_request), và 'jobs' (danh sách công việc cần làm, mỗi job chạy trên 1 máy ảo riêng, gồm nhiều 'steps' chạy tuần tự).
▶ Bước 1: Trong repo ShopEasy, tạo thư mục .github/workflows/ nếu chưa có, rồi tạo file tests.yml bên trong.
▶ Bước 2: Khai báo 'name' cho workflow và 'on: push, pull_request' để chạy tự động trên cả hai sự kiện, giới hạn nhánh main.
▶ Bước 3: Khai báo job 'test' chạy trên 'ubuntu-latest', đây là máy ảo Linux sạch do GitHub cấp phát mỗi lần chạy.
# .github/workflows/tests.yml
name: Run Playwright Tests
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 20
- name: Cai dat dependencies
run: npm ci
- name: Cai dat trinh duyet Playwright
run: npx playwright install --with-deps
- name: Chay Playwright tests
run: npx playwright test
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!