Các tài nguyên tốt nhất để học TDD là gì? [đóng cửa]

Tôi muốn học (và làm chủ) TDD. Điều gì là tốt nhất:

• sách
• trang web
• video
• danh sách các bài tập
• lời nói khôn ngoan

để học hỏi, đánh giá cao và sử dụng TDD?

Cá nhân tôi thấy rằng đọc một bài luận JUnit hoặc hai bài nhấn mạnh rằng "bạn viết bài kiểm tra trước khi viết mã" là đủ để tôi bắt đầu.

Phần quan trọng nhất trong việc học công nghệ này là viết RẤT NHIỀU mã dựa trên kiểm tra , bởi vì bạn cần thay đổi một số cách cơ bản nhất mà bạn nghĩ về việc viết mã. Những thứ như:

• Viết bài kiểm tra trước mã, làm cho bạn nghĩ trước về cách bạn sẽ gọi mã của mình và lấy lại kết quả. Điều này có nghĩa là bạn thiết kế API trước dựa trên cách bạn sẽ sử dụng nó. Điều này thường dẫn đến một API tốt hơn.
• Phong cách mã hóa của bạn sẽ thay đổi bởi vì bạn sẽ CẦN phải suy nghĩ nhiều mô-đun hơn, để có thể kiểm tra các phần của mã thay vì chỉ toàn bộ.
• Bạn cũng sẽ đến một điểm mà bạn có thể tự tin rút ra một đoạn lớn và chèn một đoạn mới thay vì hành xử tương tự, bởi vì bài kiểm tra của bạn vượt qua. Tôi đã làm điều đó gần đây với một thư viện phân tích ngày, vì bản gốc quá nhẹ nhàng.

Nơi tốt nhất để bắt đầu nhỏ, là với các thói quen tiện ích của bạn. Lần tới bạn cần một thiết kế, sau đó chỉ cần thiết kế với các thử nghiệm trước, viết rất nhiều thử nghiệm bao gồm tất cả các giai đoạn chính thức của bạn (bao gồm cả những gì sẽ xảy ra với giá trị null được thông qua, v.v.) và khi tất cả các trường hợp sử dụng được triển khai, bạn sẽ có thể sử dụng nó trực tiếp trong mã của bạn và tự tin rằng nó hoạt động như mong đợi.

Đó cũng là kinh nghiệm của tôi khi các bài kiểm tra tốt có thể thực hiện công việc bổ sung dưới dạng tài liệu, bởi vì bạn có rất nhiều mã rất súc tích nói chính xác cách mã hoạt động trong các tình huống khác nhau, có thể dễ dàng được chứng minh là đúng (thanh màu xanh lá cây). Với những bình luận cẩn thận, bạn sẽ không nhận được nó tốt hơn thế nhiều.

Đối với Java jUnit phiên bản 4 thực sự tốt đẹp.

Theo tôi, TDD thiên về việc làm cho mã có thể kiểm tra được, hơn là viết thử nghiệm.

Chắc chắn bạn có thể viết một bài kiểm tra trước khi mã hóa, nhưng toàn bộ lý do bài kiểm tra được viết là để bạn có thể viết mã - điều này sẽ không ngăn bạn viết mã khó kiểm tra.

Hãy xem điều này để hiểu rõ hơn về ý của tôi: Lý thuyết thống nhất về lỗi của tôi

Nếu bạn quan tâm đến khái niệm này và muốn tìm hiểu thêm, chỉ cần nhận xét - và tôi sẽ chỉ cho bạn hướng trình bày được ghi lại về chủ đề từ Google.

CẬP NHẬT:

Cách viết sạch, mã có thể kiểm tra

Trình bày Miško Hevery (bởi GoogleTechTalks ) Tại Google ở ​​NYC và được tài trợ bởi nhóm Năng suất Kỹ thuật của Google

Ngoài một số cuốn sách đã được đề cập, tôi có thể đề xuất Phát triển phần mềm hướng đối tượng được hướng dẫn bởi các thử nghiệm . Tôi chưa đọc xong, nhưng đây là một cuốn sách đáng đọc, bao gồm câu chuyện về một dự án TDD hoàn toàn giống như thật, không chỉ là các ví dụ mã đơn giản.

Tôi đã đọc hai cuốn sách:

Kiểm tra hướng phát triển: Ví dụ của Kent Beck và

Khung kiểm tra đơn vị của Paul Hamil

Cuốn sách Beck được đánh giá cao, nhưng tôi đã không bắt đầu với thử nghiệm đơn vị cho đến khi tôi đọc "Khung kiểm tra đơn vị". Tôi làm một số TDD, nhưng tôi cũng thêm các bài kiểm tra vào mã cũ hơn mà tôi phải duy trì (khi tôi có thể).

Chỉnh sửa: Ngoài ra, một khi bạn đã xử lý nó, tôi khuyên bạn nên sử dụng nó cho một dự án hiện tại ngay lập tức. Đối với tôi đó là khi việc học thực sự xảy ra và tôi nghĩ cuốn sách "Khung kiểm tra đơn vị" là một cuốn sách tham khảo tốt hơn cho mục đích này. (Tôi đã sử dụng nunit với C #).

Mặc dù không phải chủ yếu về TDD (mặc dù nó có liên quan đến nó, cũng như thiết kế để kiểm tra), The Art of Unit tests là một cuốn sách tôi muốn giới thiệu bởi vì nó dạy bạn cách viết các bài kiểm tra tốt.

Cụ thể hơn, nó dạy cách tạo ra các bài kiểm tra đáng tin cậy, có thể duy trì và có thể đọc được. Tôi nghĩ rằng đây là phần quan trọng nhất của cuốn sách, bên ngoài có lẽ là những điều cơ bản về kiểm tra đơn vị và khung cách ly. Rõ ràng là nếu các bài kiểm tra đơn vị trở thành một điểm đau hoặc thêm ma sát vào công việc của nhà phát triển, thì bất kỳ thành công hoặc lợi ích nào từ chúng sẽ bị hạn chế. Nếu một người đầu tư thời gian và công sức để tạo ra các bài kiểm tra, thì anh ta sẽ có thể nhận được nhiều tiền lãi nhất từ ​​khoản đầu tư đó.