Họ đang đo gì
Bạn có tư duy về lớp tương đương và giá trị biên không, hay chỉ test những gì mình vừa viết.
Trả lời ngắn~30 giây
Mình bắt đầu bằng việc liệt kê các LỚP đầu vào chứ không liệt kê giá trị: đơn rỗng, một sản phẩm, nhiều sản phẩm, có mã giảm giá, mã hết hạn, số lượng bằng 0, số lượng âm, giá bằng 0. Rồi test giá trị biên của mỗi ngưỡng trong nghiệp vụ — nếu miễn phí ship từ 500k thì test 499.999, 500.000 và 500.001. Và một test cho tính chất tổng quát: tổng tiền không bao giờ âm, bất kể đầu vào.
Giải thích sâu
Giá trị biên là nơi bug tập trung vì đó là nơi lập trình viên phải chọn giữa < và <=, và cả hai đều biên dịch được. Một test ở 400k và một test ở 600k đều xanh với cả hai cách viết; chỉ test đúng tại 500.000 mới phân biệt được. Đây là lý do một bộ test nhiều mà chọn giá trị tuỳ tiện vẫn có thể bỏ lọt phần lớn lỗi thật.
Property-based testing đáng nhắc tới vì nó tìm ra những tổ hợp mà không ai nghĩ ra: bạn khai báo tính chất (“áp mã giảm giá không bao giờ làm tổng tăng lên”) và thư viện sinh hàng nghìn đầu vào ngẫu nhiên, rồi tự thu nhỏ ca lỗi về dạng tối giản nhất khi tìm thấy. Với logic tính tiền có nhiều quy tắc chồng nhau thì nó rất hiệu quả, và nó bổ sung chứ không thay thế test theo ví dụ.
Câu hỏi tiếp theo họ sẽ hỏi
?TDD có bắt buộc không?
Không, nhưng nó hữu ích nhất đúng ở loại bài toán này: viết test trước buộc bạn định nghĩa hành vi ở các biên TRƯỚC khi cài đặt, nên bạn ít bị dẫn dắt bởi code mình vừa viết. Với việc khám phá thiết kế thì mình linh hoạt hơn; với logic nghiệp vụ có quy tắc rõ ràng thì viết test trước gần như luôn nhanh hơn.
Trả lời thế này là mất điểm
- Chỉ test đường thành công. Đó là test chứng minh bạn đã chạy thử code một lần.
- Test lặp lại chính công thức trong code. Nếu công thức sai thì test cũng sai theo, và nó không bắt được gì.