Bạn phải sửa một hàm 800 dòng không có test nào. Bắt đầu từ đâu?

Việc ghi lại cả hành vi sai nghe phản trực giác nhưng là điểm mấu chốt: ở đâu đó có người đang phụ thuộc vào cái sai đó, và bạn cần BIẾT khi mình thay đổi nó, chứ không phải vô tình thay đổi rồi phát hiện qua ticket. Nếu quyết định sửa hành vi, bạn sửa test một cách có chủ đích và ghi lý do — đó là một thay đổi được ghi nhận, không phải một tác dụng phụ.

Khó khăn thực tế thường là hàm đó không gọi được trong test vì nó đọc thẳng từ database, gọi API, hoặc dùng new Date(). Kỹ thuật của Michael Feathers cho việc này là “seam”: tìm chỗ có thể thay đổi hành vi mà không sửa logic — bọc lời gọi vào một phương thức protected rồi override trong lớp test, hoặc tách tham số ra. Nó xấu về mặt thiết kế và tạm thời, và nó cho bạn cái lưới để dọn dẹp phần còn lại.