Tóm tắt: Ở VAON, mã do Claude Code viết lên pull request cùng unit test và e2e test. Tiêu chí xong trong kế hoạch trở thành test case. Kỹ sư đọc test bằng bốn câu hỏi: kiểm quy tắc hay chỉ kiểm cách cài đặt, có test luôn xanh không, mock có che hành vi thật không, thiếu ca lỗi nào.
Mục lục
- Vì sao test phải nằm cùng pull request với mã AI viết?
- Tiêu chí xong trong kế hoạch trở thành test case thế nào?
- Kỹ sư đọc test AI viết bằng những câu hỏi nào?
- Pull request có test để lại bằng chứng gì cho bạn?
- Test do AI viết không thay được việc gì?
- Câu hỏi thường gặp
1. Vì sao test phải nằm cùng pull request với mã AI viết?
Test phải nằm cùng pull request vì người review cần thấy cùng lúc mã làm gì và bằng chứng mã làm đúng. Nếu test đến ở đợt sau, mã đã vào hệ thống mà chưa ai chứng minh được điều gì. Ở VAON, nhánh chính bị khoá: chưa review thì không merge.
AI viết test nhanh, nên lý do "để test sau" không còn. Câu hỏi chuyển sang chỗ khác: test đó có kiểm đúng thứ cần kiểm không? Một bộ test toàn màu xanh chưa nói được gì nếu test không bám vào yêu cầu.
Test trong pull request là bước 6 và 7 trong quy trình phát triển với Claude Code của VAON. Đây là tiêu chuẩn VAON đang áp dụng cho phần lớn dự án, chưa phải tất cả.
2. Tiêu chí xong trong kế hoạch trở thành test case thế nào?
Mỗi tiêu chí xong trong kế hoạch triển khai trở thành ít nhất một test case. Kỹ sư liệt kê test case từ tiêu chí trước khi đọc mã. Tiêu chí đã được viết thành điều kiểm được ở vòng validate kế hoạch triển khai, nên bước này chủ yếu là chép sang.
Bảng dưới là ví dụ minh hoạ, không lấy từ dự án của khách nào:
| Tiêu chí xong (minh hoạ) | Unit test | E2E test |
|---|---|---|
| Đơn từ mức duyệt trở lên chuyển sang "chờ quản lý duyệt" | Hàm tính trạng thái với đơn dưới mức, đúng bằng mức, trên mức | Nhân viên tạo đơn lớn, quản lý thấy đơn trong danh sách chờ duyệt |
| Nhân viên không xem được đơn của chi nhánh khác | Truy vấn luôn có điều kiện lọc theo chi nhánh | Đăng nhập nhân viên chi nhánh A, mở thẳng đường dẫn đơn chi nhánh B, bị từ chối |
| Bấm Lưu hai lần không tạo hai đơn | Gửi lại cùng mã yêu cầu chỉ ghi một lần | Bấm Lưu hai lần liên tiếp, danh sách chỉ có một đơn |
Unit test kiểm quy tắc ở từng hàm, chạy nhanh, nên dùng cho các ca biên như "đúng bằng mức". E2E test (kiểm thử toàn luồng như người dùng thật) kiểm các phần ghép với nhau, chậm và dễ chập chờn hơn. VAON dùng e2e cho luồng chính và chỗ phân quyền.
Tài liệu của Anthropic về làm việc với test trong Claude Code khuyên nói cụ thể hành vi cần kiểm khi nhờ Claude viết test. Tiêu chí xong chính là phần "cụ thể" đó.
3. Kỹ sư đọc test AI viết bằng những câu hỏi nào?
Kỹ sư VAON đọc test AI viết bằng bốn câu hỏi. Lý do: test AI viết hay bám vào mã vừa sinh ra, không bám yêu cầu.
| Dấu hiệu | Trông thế nào | Câu hỏi của kỹ sư |
|---|---|---|
| Kiểm cách cài đặt, không kiểm quy tắc | Giá trị mong đợi tính bằng chính công thức trong mã; đếm hàm nội bộ được gọi mấy lần | Con số mong đợi lấy từ đặc tả hay từ mã? |
| Test luôn xanh | Không có phép so sánh, so sánh điều hiển nhiên, bắt lỗi rồi bỏ qua | Cố ý làm sai mã thì test có đỏ không? |
| Mock che hành vi thật | Mock trả đúng thứ test mong đợi, hoặc mock luôn phần cần chứng minh | Phần bị thay bằng mock có phải phần cần kiểm không? |
| Thiếu ca lỗi | Chỉ có luồng thành công; không có dữ liệu rỗng, trùng, không có quyền | Đặc tả nói gì khi thao tác thất bại, test nào kiểm điều đó? |
Dấu hiệu đầu tiên khó thấy nhất. Một test tính giá trị mong đợi bằng cùng công thức với mã sẽ xanh cả khi công thức sai. Kỹ sư viết con số mong đợi bằng tay, lấy từ đặc tả.
Khi test đỏ, câu hỏi đầu tiên là mã sai hay test sai. Người trả lời là kỹ sư đọc đặc tả, không phải AI sửa test cho xanh. Cách cố ý phá mã để thử test có ở bài review code do AI viết.
4. Pull request có test để lại bằng chứng gì cho bạn?
Pull request có test để lại bằng chứng bạn xem lại được: tiêu chí nào được kiểm bằng test nào, lệnh nào đã chạy và kết quả ra sao. Mô tả pull request liệt kê tiêu chí cùng test tương ứng, và ghi rõ tiêu chí nào chưa có test, vì sao.
Tài liệu best practices của Claude Code khuyên yêu cầu Claude đưa bằng chứng: lệnh đã chạy và đầu ra. Theo tài liệu, một câu "tất cả test đều qua" tự nó cho biết rất ít.
Kỹ sư VAON dùng Claude Code và GitHub Copilot hằng ngày. AI sinh test và đọc lại mã, còn người kiểm tra trước khi phát hành. Mọi pull request ở mọi dự án còn qua cổng tự động: quét secret, quét thư viện phụ thuộc, phân tích tĩnh. Sau khi merge, bản dựng được test trên môi trường riêng trước khi tới tay bạn. Mọi dự án đều lưu hồ sơ review và test, và khách xem được. "Code AI viết ai kiểm tra?" là một trong ba câu khách hỏi VAON nhiều nhất năm 2026. Test đi cùng pull request, kèm tên người duyệt, là một phần câu trả lời.
5. Test do AI viết không thay được việc gì?
Test do AI viết chỉ kiểm được điều đã viết trong đặc tả, nên có những việc nó không thay được:
- Kiểm thử nghiệm thu của bạn. Thứ đặc tả bỏ sót thì test cũng bỏ sót. Bạn vẫn kiểm theo checklist góc người dùng.
- Quy tắc nghiệp vụ chưa ai ghi lại. AI không viết test cho quy tắc nó không biết.
- Phán đoán của người review. Một con số độ phủ cao vẫn có thể gồm toàn test luôn xanh. VAON không hứa tỷ lệ độ phủ chung.
Có hai giới hạn khác. E2E test dễ chập chờn, và test chập chờn dần bị bỏ qua, nên giữ ít và ổn định. Khi khách chưa cho phép đưa mã vào AI, kỹ sư tự viết test, chậm hơn. Vòng kiểm chứng phía đội QA có ở bài quy trình dùng AI trong kiểm thử.
6. Câu hỏi thường gặp
Độ phủ test bao nhiêu phần trăm là đủ? VAON không hứa một tỷ lệ độ phủ chung. Độ phủ chỉ cho biết dòng mã nào đã chạy qua khi test, không cho biết test có kiểm đúng quy tắc không. Câu hỏi hữu ích hơn là: mỗi tiêu chí xong trong kế hoạch có test tương ứng chưa, và tiêu chí nào chưa có thì vì sao.
Tôi không biết lập trình, làm sao kiểm tra test? Bạn không cần đọc mã test. Hãy xem mô tả pull request: tiêu chí nào được kiểm bằng test nào, và kết quả lần chạy gần nhất. Chọn một quy tắc quan trọng với bạn, ví dụ ai được duyệt đơn, rồi hỏi đội phát triển test nào kiểm quy tắc đó. Câu trả lời nên chỉ ra được một test cụ thể.
AI viết cả mã lẫn test, có phải tự chấm bài của mình không? Có rủi ro đó, và VAON xử lý ở ba chỗ. Test case được liệt kê từ tiêu chí xong trong kế hoạch, không từ mã. Kỹ sư viết giá trị mong đợi theo đặc tả. Sau đó một kỹ sư khác review pull request trước khi trưởng nhóm cho merge, và nhánh chính không nhận mã chưa review.
Đã có e2e test thì còn cần kiểm thử nghiệm thu không? Vẫn cần. E2E test chạy theo kịch bản do đội phát triển viết từ đặc tả. Kiểm thử nghiệm thu là lúc bạn, người dùng thật, kiểm theo cách công việc diễn ra hằng ngày. Hai bước bắt các lỗi khác nhau. Ở VAON, bạn kiểm theo checklist góc người dùng, mỗi mục có ảnh chụp kết quả.
Viết test cùng mã có làm dự án đắt hơn không? AI làm nhanh phần viết test lặp lại, nên chi phí viết test giảm. Phần đọc và sửa test vẫn cần kỹ sư, và VAON không cắt phần đó. Vì vậy VAON không hứa một tỷ lệ giảm chi phí chung. Báo giá dựa trên phạm vi trong tài liệu đặc tả đã chốt, test là một phần của phạm vi đó.
Việc làm được ngay: mở một pull request gần đây trong dự án của bạn. Chọn một tiêu chí xong trong đặc tả và hỏi đội phát triển: "Test nào kiểm điều này, và nếu mã sai thì test đó có đỏ không?"
Nếu muốn xem cách test đi cùng pull request trong dự án của bạn, đặt lịch trao đổi 60 phút miễn phí. CEO tham dự, không cần chuẩn bị tài liệu, không ràng buộc.
