Testing
Testing
Kim tự tháp kiểm thử 2 tầng: Unit test (đáy, nhiều nhất) và Integration test (giữa, ít hơn). Test tự động là bản ghi vĩnh viễn của 'thử tay đúng cách' — chạy lại trong vài giây thay vì tự tay thử lại toàn bộ mỗi lần.
Nắm vững nguyên lý và khái niệm nền tảng trước khi đi vào công cụ thực tế.
Áp dụng quy trình từng bước, case study thực chiến và template mẫu có sẵn.
Kiểm tra checklist hoàn thành, né tránh các sai lầm kinh điển để vận hành bền vững.
Nắm vững các khái niệm nền tảng, cơ chế hoạt động và mô hình tư duy cốt lõi.
1. Mục tiêu học tập
Sau bài này, bạn có thể:
2. Khái niệm cốt lõi
Vì sao cần test tự động (không phải chỉ “thử tay”): ở bài 59, bạn tự tay tái hiện lỗi mất dữ liệu để xác minh đã sửa xong — cách này hiệu quả cho 1 lỗi cụ thể, nhưng không mở rộng được: mỗi lần thêm 1 tính năng mới (bài 60, 64), bạn sẽ phải nhớ tự tay thử lại toàn bộ tính năng cũ để chắc chắn không có gì hỏng. Test tự động là cách ghi lại vĩnh viễn một lần “thử tay đúng cách”, để chạy lại bất cứ khi nào chỉ trong vài giây.
Kim tự tháp kiểm thử (test pyramid — kiến thức chuyên môn phổ quát, không gắn 1 công cụ AI nào):
- Unit test (đáy kim tự tháp, nhiều nhất) — kiểm tra 1 đơn vị nhỏ, độc lập, ví dụ: “hàm xóa ghi chú có xóa đúng ghi chú theo ID không, mà không ảnh hưởng ghi chú khác.” Chạy rất nhanh, dễ xác định lỗi nằm ở đâu khi fail.
- Integration test (giữa kim tự tháp, ít hơn) — kiểm tra nhiều phần phối hợp, ví dụ: “khi người dùng bấm nút thêm ghi chú ở Frontend, dữ liệu có thực sự tới được Database qua đúng API không” (đúng mô hình 4 lớp bài 55). Chạy chậm hơn unit test, nhưng phát hiện được lỗi giữa các lớp mà unit test từng lớp riêng lẻ không thấy.
Level 6 chỉ cần 2 tầng này — tầng cao nhất của kim tự tháp đầy đủ (kiểm thử toàn bộ giao diện người dùng tự động, “end-to-end”) vượt phạm vi người mới bắt đầu, không bắt buộc cho dự án tích lũy.
Quy trình chính thức “Work with tests” khi làm việc với Claude Code:
- Xác định code chưa có test — ví dụ nguyên văn: “find functions… that are not covered by tests.”
- Sinh khung test (scaffolding) — ví dụ: “add tests for the notification service.”
- Thêm test case có ý nghĩa, đặc biệt edge case (tình huống biên, bất thường) — ví dụ: “add test cases for edge conditions.”
- Chạy và xác minh test, sửa lỗi nếu có — ví dụ: “run the new tests and fix any failures.”
Verified fact quan trọng: Claude Code đọc các file test hiện có của dự án để khớp đúng style/framework/assertion pattern đang dùng — không tự bịa convention mới. Để có coverage toàn diện, có thể chủ động yêu cầu AI tìm edge case, lỗi biên, input bất ngờ mà con người dễ bỏ sót.
3. Tại sao nội dung này quan trọng
Test là “lưới an toàn” cho mọi thay đổi sau này — đặc biệt cho bài 60 (Refactor), nơi mục tiêu là thay đổi cấu trúc code mà không đổi hành vi: không có test, bạn không có cách nào chắc chắn hành vi thực sự không đổi, chỉ có thể “hy vọng.”
4. Cơ chế hoạt động
Phân định AI vs con người:
| Điều bạn cần hiểu | Điều AI có thể thực hiện | Điều bạn phải xác nhận | |
|---|---|---|---|
| Xác định phạm vi | Tính năng nào quan trọng nhất cần test trước | Quét code, liệt kê phần chưa có test | Danh sách AI đưa ra có đúng ưu tiên đúng tính năng cốt lõi (lưu/đọc dữ liệu quan trọng hơn màu nút bấm) |
| Sinh test | Test cần phản ánh đúng hành vi mong muốn, không phải hành vi hiện tại nếu hiện tại đang sai | Viết khung test theo đúng style dự án | Test có thực sự kiểm tra đúng điều bạn quan tâm, không phải test hình thức “cho có” |
| Edge case | Edge case là tình huống biên dễ bị bỏ sót (ghi chú rỗng, ghi chú rất dài) | Chủ động đề xuất edge case | Danh sách edge case có phủ đúng rủi ro thật của sản phẩm bạn, không chỉ ví dụ chung chung |
| Chạy & xác minh | Test fail nghĩa là có gì đó cần xem lại — đôi khi là code sai, đôi khi là test viết sai | Chạy test, tự sửa nếu fail | Khi test fail, xác định đúng là code sai hay test viết sai trước khi để AI “sửa cho qua” |
5. Mental model
Nếu bài 59 là lúc bạn phát hiện và vá 1 vết rò nước cụ thể, bài này là lúc bạn lắp cảm biến rò nước ở những vị trí quan trọng nhất trong nhà — không phải để tránh mọi vết rò tương lai (không thể), mà để biết ngay khi có vết rò mới xuất hiện, thay vì phải tự đi kiểm tra từng phòng mỗi lần.
Quy trình thực thi từng bước, case study cụ thể và bộ prompt/template áp dụng ngay.
6. Hướng dẫn từng bước
Áp dụng cho dự án tích lũy: Trợ Lý Ghi Chú Cá Nhân Có AI Tóm Tắt.
7. Ví dụ thực tế
Edge case dễ bị bỏ sót cho dự án ghi chú: xóa 1 ghi chú, sau đó thử xóa lại đúng ghi chú đó lần nữa (đã không còn tồn tại) — sản phẩm nên xử lý thế nào (thông báo lỗi rõ ràng, hay im lặng không làm gì)? Đây là loại tình huống người mới thường không tự nghĩ ra khi “thử tay”, nhưng Claude Code có thể chủ động đề xuất nếu được yêu cầu tìm edge case.
8. Prompt/template/workflow
Tìm các chức năng trong [tên file/module] chưa có test.Viết unit test cho [chức năng cụ thể], kiểm tra [hành vi mong muốn].Sau đó, đề xuất thêm edge case tôi có thể chưa nghĩ tới.Chạy toàn bộ test và sửa nếu có lỗi.[ ] Có ít nhất 1 unit test cho phần logic cốt lõi?[ ] Có ít nhất 1 integration test cho chu trình đầy đủ (qua đúng API)?[ ] Đã yêu cầu AI đề xuất edge case, không chỉ dùng test "đường thẳng"?[ ] Toàn bộ test đã chạy và pass?9. Visual hoặc diagram cần thiết
10. Bài tập thực hành
- Yêu cầu Claude Code liệt kê chức năng nào trong dự án của bạn chưa có test.
- Sinh unit test cho 1 chức năng cốt lõi (thêm hoặc xóa ghi chú).
- Sinh integration test cho chu trình đầy đủ tương ứng.
- Yêu cầu AI đề xuất ít nhất 2 edge case, thêm test cho cả 2.
- Chạy toàn bộ test, xác nhận tất cả pass.
Checklist kiểm tra mức độ sẵn sàng, nhận diện các bẫy sai lầm và nguyên tắc vàng vận hành.
11. Checklist
12. Lỗi thường gặp
15. Best practices
16. Nội dung nâng cao (không bắt buộc)
Test tự động còn đóng vai trò là 1 dạng “tài liệu sống”: đọc lại các test case của 1 chức năng cho biết chính xác hành vi mong đợi của chức năng đó là gì, thường rõ ràng hơn đọc code trực tiếp — hữu ích khi bạn (hoặc AI) quay lại 1 phần dự án đã lâu không động tới.
⚠️ 13. Giới hạn & khi nào KHÔNG nên áp dụng
- Bài này không dạy kiểm thử giao diện tự động ở tầng cao nhất kim tự tháp (end-to-end UI testing) — vượt phạm vi người mới bắt đầu.
- Bài này không dạy refactor — đó là bài 60; ở đây test chỉ đóng vai trò chuẩn bị nền tảng để bài 60 có thể refactor an toàn (chạy lại test sau mỗi thay đổi để xác nhận hành vi không đổi).
- Test không thay thế được bước xác minh thủ công cuối cùng trước khi deploy (bài 63) — test chỉ kiểm tra được những gì bạn đã nghĩ tới viết thành test case.
🔐 14. An toàn & quản trị (Safety/Governance)
Test tự động không phải “làm cho có” — đây là cơ chế phát hiện sớm chính xác loại rủi ro đã nêu ở bài 56 (code AI-đồng-tác-giả có tỷ lệ lỗi nghiêm trọng cao hơn khi thiếu review). Một bộ test tốt giúp phát hiện lỗi ngay khi vừa phát sinh (ví dụ: sau khi thêm tính năng mới ở bài 64), thay vì để người dùng thật phát hiện ra sau khi deploy (bài 63) — chi phí sửa lỗi lúc đó cao hơn nhiều.
📚 17. Nguồn tham khảo
Common Workflows, Anthropic (code.claude.com/docs) — quy trình chính thức “Work with tests” (xác định phạm vi → sinh khung test → thêm edge case → chạy và xác minh), verified fact về việc AI khớp đúng convention test hiện có của dự án · Dẫn chiếu (không trích dẫn mới): bài 55 (mô hình 4 lớp, dùng để phân biệt unit vs integration test), bài 59 (test tự động là phiên bản tự động hóa của bước xác minh thủ công đã học).