Liệu triển khai rõ ràng của TDD có nghĩa là mã trước, kiểm tra sau?

Bạn tôi và tôi là TDD tương đối mới và có tranh cãi về kỹ thuật "Thực hiện rõ ràng" (từ "TDD theo ví dụ" của Kent Beck). Bạn tôi nói điều đó có nghĩa là nếu việc triển khai là rõ ràng, bạn nên tiếp tục và viết nó - trước bất kỳ thử nghiệm nào cho hành vi mới đó. Và thực sự cuốn sách nói:

Làm thế nào để bạn thực hiện các hoạt động đơn giản? Chỉ cần thực hiện chúng.

Cũng thế:

Đôi khi bạn chắc chắn rằng bạn biết cách thực hiện một thao tác. Đi về phía trước.

Tôi nghĩ ý nghĩa của tác giả là bạn nên thử nghiệm trước, sau đó "chỉ thực hiện" nó - trái ngược với "Fake It ('Till You Make It)" và các kỹ thuật khác, đòi hỏi các bước nhỏ hơn trong giai đoạn thực hiện. Ngoài ra, sau những trích dẫn này, tác giả nói về việc nhận "các thanh màu đỏ" (không thực hiện các bài kiểm tra) khi thực hiện "Thực hiện rõ ràng" - làm thế nào bạn có thể có được một thanh màu đỏ mà không cần kiểm tra?.

Tuy nhiên, tôi không thể tìm thấy bất kỳ trích dẫn từ cuốn sách nói "rõ ràng" vẫn có nghĩa là thử nghiệm đầu tiên.

Bạn nghĩ sao? Chúng ta nên kiểm tra trước hay sau khi việc triển khai là "hiển nhiên" (theo TDD, tất nhiên)? Bạn có biết một cuốn sách hoặc bài viết blog chỉ nói điều đó?

Tôi đồng ý với cách giải thích của bạn - đó vẫn là Red Refactor, chỉ với bit Refactor còn lại;)

Vì vậy, trước tiên hãy viết một bài kiểm tra thất bại, sau đó thực hiện giải pháp rõ ràng thay vì từ từ xây dựng một thiết kế "đơn giản nhất có thể".

Bạn có biết một cuốn sách hoặc bài viết blog chỉ nói điều đó?

Tôi sẽ tranh luận rằng cuốn sách của Beck chỉ nói như vậy.

Anh ấy tiếp tục nói

Tuy nhiên, bằng cách chỉ sử dụng Thực hiện rõ ràng, bạn đang đòi hỏi sự hoàn hảo của bản thân. Về mặt tâm lý, đây có thể là một động thái tàn phá. Điều gì xảy ra nếu những gì bạn viết không thực sự là thay đổi đơn giản nhất có thể khiến bài kiểm tra vượt qua? Điều gì nếu đối tác của bạn cho bạn thấy một người thậm chí còn đơn giản hơn? Bạn là một thất bại! Thế giới của bạn sụp đổ xung quanh bạn! Bạn chết. Bạn đóng băng

Làm thế nào bạn có thể vượt qua bài kiểm tra bằng cách viết mã nếu nó không tồn tại trước khi mã không?

Rõ ràng không có quy tắc cứng và nhanh nào ở đây, đã nhanh nhẹn để chúng ta có thể và nên thích nghi khi chúng ta lặp đi lặp lại :)

Một phần nó sẽ phụ thuộc vào thao tác đơn giản và khi bạn thực hành TDD ngày càng nhiều, bạn sẽ thường xuyên tìm thấy những thứ bạn đã kiểm tra kém hoặc thực sự không thực sự kiểm tra, tất cả đều là một phần của quá trình học tập.

Cũng đừng quên rằng TDD cho phép bạn kiểm tra giao diện và cách triển khai trước khi cam kết nó thành mã trực tiếp.

Bạn có thể biết cách triển khai một cái gì đó nhưng tần suất bạn viết một lớp / phương thức hoàn hảo, v.v. Lần đầu tiên không có một số điều chỉnh trên đường đi hoặc bước qua mã một hoặc hai lần và sáu tháng sau khi bạn thay đổi một thứ gì đó bạn có thể làm như vậy với tự tin hơn và một lần nữa trong hộp cát của các bài kiểm tra.

Tất nhiên, các thử nghiệm không có nghĩa là bạn viết mã lần đầu tiên chính xác hơn nhưng các thay đổi của bạn được điều khiển bởi thử nghiệm và các thử nghiệm trở thành khách hàng đầu tiên của mã và vì các thử nghiệm có chi phí rất thấp và quan trọng hơn là không có rủi ro để thay đổi bạn có thêm tự tin và tự do trong khi phát triển.

Nếu bạn thực sự cố gắng để có được phạm vi bảo hiểm tốt và chất lượng cao hơn thì hãy bắt đầu thực hiện nhiều bài kiểm tra hơn, khi bạn thực hành TDD càng nhiều, bạn sẽ càng phát triển ý thức về mức độ bảo hiểm bạn cần.

Tôi đã học được rằng đối với mã tầm thường, không nên có bất kỳ sự không đáng tin nào cả.

Ví dụ: Nếu bạn có một phương thức java getter / setter ánh xạ một phương thức tới một biến cục bộ thì một điều không đáng tin nhất cho điều này sẽ là quá mức cần thiết.

có thể đây là ý nghĩa của tác giả

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."