Nếu bạn đang làm thử nghiệm phát triển đầu tiên, ở mức tối thiểu bạn phải viết một bài kiểm tra mới để biện minh cho sự thay đổi. Sự thay đổi sau đó có thể phá vỡ các thử nghiệm cũ và bạn có thể sửa chúng sau khi bạn thấy chúng thất bại, nếu sự thay đổi là ngẫu nhiên để thử nghiệm. Tuy nhiên, nếu bạn biết rằng bài kiểm tra được sử dụng để kiểm tra hành vi cũ và nó chỉ cần thay đổi cho hành vi mới, không có lý do gì để không chỉ thay đổi bài kiểm tra đó thay vì viết bài kiểm tra mới. Nó không phải là giá trị nỗ lực (theo quan điểm của tôi) để tìm ra những thử nghiệm sẽ phá vỡ với sự thay đổi và thay đổi tất cả đầu tiên bởi vì các Á hậu thử nghiệm sẽ cho bạn biết rằng sau khi bạn thực hiện thay đổi.
EDIT (để trả lời nhận xét): Tôi thích viết bài kiểm tra trước, nhưng đó là kiểu TDD. Trong trường hợp đó, thử nghiệm sẽ thúc đẩy thiết kế. Ngoài ra còn có một nhịp điệu và khuôn mẫu cho loại phát triển đó (red-green-refactor). Cách khác xung quanh là cách thử nghiệm đơn vị thuần túy hơn, bạn đã thiết kế và triển khai thực hiện những gì bạn muốn, bây giờ bạn đang thử nghiệm nó. Không có gì sai với điều đó, nó là một cách tiếp cận phát triển khác và sự lựa chọn không phụ thuộc vào sự tồn tại của các xét nghiệm khác. Nó thực sự là một cách tiếp cận phát triển nói chung.
s/hy vọng/chắc chắn/ –
Từ được chọn với ý định :) –