Tôi chưa bao giờ sử dụng cơ chế kiểm tra tự động trong bất kỳ dự án nào của mình và tôi cảm thấy mình đang thiếu rất nhiều. Tôi muốn cải thiện bản thân, vì vậy tôi phải bắt đầu giải quyết một số vấn đề mà tôi đã bỏ bê như thế này và thử Git thay vì bị mắc kẹt trên SVN.
Cách tốt để học TDD là gì? Có lẽ tôi sẽ sử dụng Eclipse để lập trình trong Java. Tôi đã nghe nói về JUnit, nhưng tôi không biết nếu có bất cứ điều gì khác tôi nên xem xét.
Câu trả lời:
Bạn có thể bắt đầu bằng cách làm việc trên katas mã hóa . Chọn một thuật toán (ví dụ: chuyển đổi số thập phân sang chữ số La Mã, ghi điểm trò chơi bowling, trò chơi cuộc sống của Conway, v.v.) và thử sử dụng TDD để giải quyết.
Cấu trúc giải pháp của bạn có thể sẽ rất đơn giản (đơn giản hơn nhiều so với mã sản xuất trong thế giới thực của bạn): một lớp cho vật cố thử nghiệm và một lớp chứa thuật toán được thử nghiệm. Và lớp học thử nghiệm không có phụ thuộc là một điểm cộng khác. Bạn có thể sử dụng tính đơn giản của thiết lập này để nhanh chóng hiểu được vòng lặp tái cấu trúc đỏ-lục.
Công cụ nào bạn sử dụng cho katas TDD của bạn không thực sự quan trọng miễn là bạn tuân thủ các nguyên tắc. Tuy nhiên, plugin JUnit cho Eclipse rất dễ sử dụng, vì vậy đây là một lựa chọn tuyệt vời.
Làm quen với AAA , đọc về nó, đọc về các vấn đề phát triển theo hướng kiểm tra ( thiết kế để kiểm tra so với các công cụ chi phí cao để thiết kế không thành vấn đề). Tìm hiểu Dependency Injection để loại bỏ các phụ thuộc bên ngoài để thử nghiệm trở nên đơn giản hơn.
Dưới đây là một tổng quan tốt về các ghi chú tôi đã ghi lại khi đọc Nghệ thuật kiểm tra đơn vị
http://imaginarydevelopment.blogspot.com/2010/01/unit-testing-reference.html
Thực sự không có gì thay thế cho việc chỉ lấy một dây nịt thử nghiệm (như NUnit), đọc một số tài liệu và sau đó bị bẩn tay.
Như James T. Kirk từng nói: "Chúng tôi học bằng cách làm".
Tôi đánh giá cao cuốn sách này: 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
Nó có một ví dụ hoạt động xuyên suốt cuốn sách và cung cấp một cái nhìn rất mạch lạc về việc khi nào nên thử nghiệm, những gì họ nên chứa và cách chúng nên được xây dựng và tái cấu trúc.
Kiểm tra liên kết này . Đây là blog của Bob Martin trên TDD - công cụ tuyệt vời giúp bạn hiểu (hoặc cung cấp cho bạn một triển vọng khác) về suy nghĩ trong TDD.