Viết unit test thủ công thường chỉ phủ đúng "happy path" — trường hợp input đẹp, đúng như mong đợi — còn những trường hợp biên (input rỗng, giá trị âm, null) dễ bị bỏ sót vì không ai nghĩ tới cho đến khi production báo lỗi. Prompt dưới đây yêu cầu AI viết test bao quát cả input hợp lệ lẫn các trường hợp biên và lỗi có chủ đích ngay từ đầu.
Khi nào nên dùng prompt này
- Có function đã viết xong nhưng chưa có test, cần bổ sung coverage trước khi merge
- Nghi ngờ test hiện tại chỉ phủ happy path, chưa chắc đã bắt được lỗi ở input bất thường
- Cần viết test nhanh cho nhiều function nhỏ mà không muốn tự nghĩ từng test case một
- Chuẩn bị refactor một function cũ, cần test bao phủ đầy đủ trước để tránh phá vỡ hành vi hiện tại
Prompt viết unit test đầy đủ trường hợp biên
Dán nguyên function (không paraphrase lại) và nêu rõ framework test đang dùng — Jest, Pytest, Vitest... mỗi framework có cú pháp mock/assert khác nhau, nêu rõ giúp code test sinh ra chạy được ngay không cần sửa lại cú pháp.
Bạn là engineer chuyên viết test, ưu tiên coverage đầy đủ.
Bối cảnh: Tôi có function sau viết bằng [ngôn ngữ], dùng framework test [tên
framework, ví dụ Jest/Pytest]:
[dán function]
Nhiệm vụ: Viết unit test cho function này, bao gồm: trường hợp input hợp lệ,
trường hợp input rỗng/null, trường hợp input ở giá trị biên, và ít nhất 1
trường hợp gây lỗi có chủ đích.
Format: Code test hoàn chỉnh, có comment ngắn giải thích từng test case.Mẹo: Nếu function đã có sẵn vài test, dán kèm cả test hiện có và hỏi thêm "những trường hợp biên nào CHƯA được test hiện tại bao phủ?" thay vì viết lại từ đầu — cách này lộ ra đúng khoảng trống thay vì tạo test trùng lặp. Luôn yêu cầu dữ liệu test thực tế (tên, email, số tiền cụ thể) thay vì chuỗi giả như "test", "foo" để test dễ đọc hơn.
Lưu ý: Test do AI viết vẫn cần tự chạy để xác nhận pass thật, không chỉ đọc qua thấy hợp lý là tin — đôi khi AI viết assertion khớp với chính hành vi (có thể sai) của function thay vì hành vi đúng mong đợi. Với function xử lý dependency ngoài (API, database), luôn kiểm tra lại phần mock có phản ánh đúng response thật hay không.
Biến thể khi cần sâu hơn
- Function phụ thuộc API/database: nêu rõ cần mock toàn bộ dependency ngoài, không gọi thật trong test
- Cần test integration thay vì unit: đổi yêu cầu thành test cả luồng thực tế thay vì cô lập từng function
- Function xử lý đồng thời (concurrent): thêm yêu cầu test riêng cho trường hợp truy cập/ghi đồng thời
Sau khi có bộ test, chạy thử coverage report để xác nhận những nhánh logic quan trọng đã được phủ — nếu vẫn có khoảng trống, quay lại hỏi thêm đúng phần đó thay vì yêu cầu viết lại toàn bộ.