Over-testing – Test nhiều hơn viết code

200 dòng code, 1.000 dòng unit test, đổi 1 dòng thì 50 test fail!

Một công ty logistics Việt Nam, team viết 1.000 dòng unit test cho 200 dòng code tính phí vận chuyển. Kết quả? Test fragile, đổi 1 dòng code fail 50 test, dev mất 2 ngày fix test thay vì feature.

Case thực tế: Test “quá đà” gây phản tác dụng

• Context: Hệ thống logistics, tính phí vận chuyển, 200 dòng code. 
• Quyết định sai: Viết 1.000 dòng unit test, test cả edge case không thực tế. 
• Vấn đề: 
  • Test fragile: Đổi tên biến, 50 test fail dù logic không đổi. 
  • Test tốn thời gian: Maintain test lâu hơn viết code. 
  • Không tập trung business: Test edge case hiếm xảy ra (VD: phí âm).

Hậu quả: 

• Velocity giảm: Dev mất 2 ngày fix test, không ra feature mới. 
• Chi phí: Tốn 100 triệu/tháng cho maintain test. 
• Team nản: Dev ngán viết test, chất lượng code giảm.

Phân tích: Tại sao sai?

• Over-testing: Test cả getter/setter, edge case không thực tế. 
• Thiếu ưu tiên: Không tập trung test logic business quan trọng. 
• Test không bền vững: Test phụ thuộc implementation, dễ fail.

Bài học: Test hợp lý

1. Test logic business: Chỉ test core logic (VD: tính phí vận chuyển). 
2. Dùng test pyramid: 70% unit test, 20% integration, 10% end-to-end. 
3. Test bền vững: Test behavior, không phụ thuộc implementation.

Code mẫu: Unit test hợp lý (Jest)

test('calculate shipping fee', () => {
    expect(calculateFee(10, 100)).toBe(50);
});

Over-testing là “tự làm khó mình”. Test logic business, dùng test pyramid, để dev không ngập trong test fail và feature ra mắt đúng hạn!

Checklist test hợp lý: 

• Test core logic, bỏ qua getter/setter. 
• Dùng test pyramid (unit, integration, end-to-end). 
• Viết test behavior-based, không fragile. 
• Audit test coverage, giữ ~70%.

🎯 Tóm lại: 1.000 dòng test cho 200 dòng code là “mua voi lấy ngà”. Test hợp lý, tập trung business, để dev không fix test đến “hóa điên”!