Khi phát triển thử nghiệm phát triển NHƯNG trong REVERSE

Question

Tôi đánh giá cao TDD và nghĩ rằng nó không thể thiếu nhưng luôn luôn viết bài kiểm tra của tôi CHỈ sau khi tôi viết mã nguồn của tôi sau đó refactor cho phù hợp. Tôi không bao giờ có thể tự mình viết bài kiểm tra đầu tiên sau đó là nguồn để vượt qua bài kiểm tra. Vì vậy, tôi luôn luôn đảo ngược quá trình. Đây có phải là một thực tế xấu về phía tôi không? Nhược điểm của việc làm nó ngược lại như tôi là gì?

Answer 1

Nếu bạn không viết bài kiểm tra trước thì có thể không phải là TDD. Với TDD bạn thường viết bài kiểm tra, xem nó không thành công, sau đó thực hiện để làm cho nó vượt qua.

Các ưu điểm so với công việc của bạn là:

• xét nghiệm của bạn có thể thất bại! Tất cả quá dễ dàng để tạo ra một bài kiểm tra đơn giản là không thể thất bại. Và như Eric đã chỉ ra, nếu bạn không viết bài kiểm tra đầu tiên, và xem nó thất bại, làm cách nào bạn biết bài kiểm tra thực sự đang thử nghiệm chức năng bạn vừa triển khai?
• Mã của bạn chắc chắn có thể kiểm tra được. Mặc dù tôi chắc chắn rằng bạn tuân thủ các kỹ thuật có thể kiểm tra, kiểm tra phát triển đầu tiên đảm bảo rằng mã chắc chắn có thể kiểm tra được nếu không bạn sẽ không viết mã :-)
• Biến các giải pháp của bạn "lộn ngược". Có thể tranh cãi được điều này nhưng TDD khiến bạn suy nghĩ về "những gì bạn cần" thay vì "chi tiết triển khai". Bằng cách tạo ra các bài kiểm tra đầu tiên, bạn ghép nối cấu trúc lớp/kiến ​​trúc chung của bạn trong các bài kiểm tra của bạn, sau đó bạn vào các chi tiết thực hiện.

Bạn có thể giảm thiểu rủi ro của tất cả các điểm đó, vì vậy, bạn có muốn tiếp tục theo cách của mình hoặc chuyển sang kiểm tra trước không.

Answer 2

Thiết kế có được thúc đẩy bởi các cân nhắc kiểm tra không? Nếu có thì thử nghiệm sẽ thúc đẩy sự phát triển. Đó là những gì được cho là xảy ra.

Viết thử nghiệm trước hết đảm bảo rằng thử nghiệm đã thúc đẩy phát triển. Và nó có xu hướng hạn chế tái cấu trúc.

Nếu bạn muốn viết tất cả các mã trước, sau đó refactor, bạn đang sử dụng thử nghiệm để phát triển ổ đĩa (đó là tốt). Tuy nhiên, bạn có thể lãng phí thời gian bằng cách viết tất cả các mã đầu tiên chỉ để refactor nó tất cả sau này (mà không phải là tốt.) Sử dụng TDD sẽ tạo điều kiện này; viết các bài kiểm tra trước khi mã cũng sẽ cắt giảm thời gian phát triển bằng cách tiết kiệm một số tái cấu trúc.

Answer 3

Nếu bạn viết các bài kiểm tra sau đó, chúng có thực sự thúc đẩy sự phát triển/thiết kế không? Tôi sẽ không nghĩ như vậy.

Để mở rộng câu trả lời của Steven Robbins: Nếu kiểm tra của bạn không thành công trước khi bạn vượt qua, làm cách nào để bạn biết nó đang kiểm tra đúng điều?

Answer 4

Suy nghĩ về thiết kế và mã hóa phần mềm của bạn cho phù hợp theo sau bằng cách thêm kiểm tra để đảm bảo bạn không quên điều gì đó là một cách hay để tiếp tục trong sách của mình.

Bạn nghĩ về mã của mình từ cả thiết kế phần mềm và từ quan điểm kiểm tra. Tôi có xu hướng phát triển mã và thử nghiệm song song, không bao giờ theo mô hình 'viết thử nghiệm đầu tiên của bạn' bởi vì nó có xu hướng dẫn đến mã đáp ứng các bài kiểm tra của bạn - không phải thiết kế của bạn.

Rủi ro trong TDD là do giai đoạn thiết kế bị bỏ qua. Nếu bạn xây dựng các thử nghiệm của bạn cố gắng để phá vỡ mã của bạn trong mọi cách có thể sau đó sửa chữa các vấn đề thử nghiệm của bạn mang lại cho bạn nhận được mã ổn định. Tôi đã có mã refactor đã được viết qua TDD đó là nguyên mẫu chất lượng tốt nhất, nó không phải là phương pháp cung cấp mã tốt, đó là nỗ lực tinh thần bạn đưa vào nó.

Answer 5

Tôi đã làm TDD (đúng) kể từ năm 2000. Có rất nhiều điểm tốt mà người khác đã đề cập, nhưng có một điểm đó là rất quan trọng và là mất tích từ các mô tả khác:

TDD làm cho bạn viết mã đơn giản!

Khi bạn thực hiện TDD, bạn viết bài kiểm tra và sau đó bạn viết mã đơn giản nhất có thể tuyệt đối để vượt qua bài kiểm tra. Nếu bạn đảo ngược điều đó, thì thường thì bạn viết mã phức tạp hơn nó cần phải có, và điều đó có các tác dụng phụ không mong muốn.

TDD là một môn học rất khó, nhưng điều quan trọng là vì nó có thể so sánh với một bác sĩ phẫu thuật khử trùng dụng cụ của mình trước khi phẫu thuật. Nếu bạn không khử trùng, bạn có nguy cơ lây nhiễm cho bệnh nhân của bạn. Nếu bạn không viết bài kiểm tra trước, bạn có nguy cơ lây nhiễm mã của bạn bằng nợ kỹ thuật.