Tại sao tôi nên thực hành Phát triển theo hướng thử nghiệm và tôi nên bắt đầu như thế nào?

Question

Rất nhiều người nói về việc viết các bài kiểm tra cho mã của họ trước khi họ bắt đầu viết mã của họ. Thực hành này thường được gọi là Phát triển theo hướng thử nghiệm hoặc TDD. Tôi thu được lợi ích gì khi viết phần mềm theo cách này? Làm cách nào để bắt đầu với thực tiễn này?

Answer 1

Có rất nhiều lợi ích:

• Bạn nhận được thông tin phản hồi ngay lập tức về nếu mã của bạn đang hoạt động, vì vậy bạn có thể tìm thấy lỗi nhanh hơn
• Bằng cách xem thử nghiệm chuyển từ màu đỏ sang màu xanh lá cây, bạn biết rằng bạn có cả kiểm tra hồi quy đang hoạt động và mã làm việc
• Bạn có được sự tự tin để cấu trúc lại mã hiện có, có nghĩa là bạn có thể xóa mã mà không phải lo lắng về việc mã nào có thể vi phạm
• Cuối cùng, bạn có một bộ kiểm tra hồi quy có thể chạy trong quá trình xây dựng tự động để cho bạn tự tin hơn rằng codebase của bạn là rắn

Cách tốt nhất để bắt đầu là bắt đầu. Có một tuyệt vời book by Kent Beck tất cả về Kiểm tra phát triển theo hướng. Chỉ cần bắt đầu với mã mới, đừng lo lắng về mã cũ ... bất cứ khi nào bạn cảm thấy bạn cần phải refactor một số mã, viết một bài kiểm tra cho các chức năng hiện có, sau đó refactor nó và đảm bảo các bài kiểm tra ở lại màu xanh lá cây. Ngoài ra, hãy đọc this great article.

Answer 2

Phần lợi ích có recently been covered, về vị trí bắt đầu .... trên hệ thống enterprisey nhỏ, nơi không có quá nhiều ẩn danh nên rủi ro thấp. Nếu bạn chưa biết một khuôn khổ thử nghiệm (như NUnit), hãy bắt đầu bằng cách học điều đó. Nếu không, hãy bắt đầu bằng cách viết bài kiểm tra đầu tiên của bạn :)

Answer 3

Theo ý kiến ​​của tôi, điều tuyệt vời nhất là nó cho phép bạn xem mã của bạn có làm được điều gì không. Điều này có vẻ hiển nhiên, nhưng nó là siêu dễ dàng để chạy lạc lối trong những mục tiêu ban đầu của bạn, như tôi đã phát hiện ra trong quá khứ: p

Answer 4

Lợi ích

1. Bạn tìm ra cách để compartmentalize mã của bạn
2. Bạn tìm ra chính xác những gì bạn muốn mã của bạn để làm
3. Bạn biết làm thế nào nó phải hành động và, xuống đường , nếu việc tái cấu trúc vi phạm bất kỳ điều gì
4. Giúp bạn có thói quen đảm bảo mã của bạn luôn biết mình phải làm gì

Bắt đầu

Chỉ cần thực hiện. Viết một trường hợp thử nghiệm cho những gì bạn muốn làm, và sau đó viết mã mà phải vượt qua bài kiểm tra. Nếu bạn vượt qua bài kiểm tra của mình, tuyệt vời, bạn có thể chuyển sang viết các trường hợp mã của bạn sẽ luôn thất bại (ví dụ: 2 + 2 không được bằng 5).

Khi tất cả các bài kiểm tra của bạn vượt qua, hãy viết logic kinh doanh thực tế của bạn để làm bất cứ điều gì bạn muốn làm.

Nếu bạn bắt đầu từ đầu, hãy đảm bảo bạn tìm được một bộ thử nghiệm tốt, dễ sử dụng. Tôi thích PHP nên PHPUnit hoặc SimpleTest hoạt động tốt. Hầu như tất cả các ngôn ngữ phổ biến đều có sẵn một bộ thử nghiệm xUnit để giúp xây dựng và tự động kiểm tra.

Answer 5

Tốt khởi động: Getting Started with Tdd in Java using Eclipse by Brett L. Schuchert

Là một tập hợp các Screencasts về TDD trong Java và C#. Nó bắt đầu từ đầu và dạy căn bản của TDD.

Answer 6

Bạn có thể đang làm việc trong môi trường nhanh nhẹn hoặc thác nước. Có thể bạn đã có những quy trình được xác định rõ ràng đã được thử thách chiến đấu qua nhiều năm làm việc chăm chỉ, hoặc có thể bạn mới bắt đầu khởi nghiệp của riêng bạn. Bất kể tình hình là gì, bạn có thể phải đối mặt với ít nhất một, nếu không nhiều hơn, về những cơn đau, vấn đề sau đây hoặc nguyên nhân gây ra giao hàng không thành công:

• Một phần của nhóm bạn được lưu giữ trong quá trình tạo các yêu cầu, quy cách, hay những câu chuyện sử dụng
• Hầu hết, nếu không phải tất cả, các bài kiểm tra của bạn là sử dụng, hoặc bạn không có kiểm tra ở tất cả các
• Mặc dù bạn đã tự động kiểm tra, họ không phát hiện vấn đề thực sự
• Các thử nghiệm tự động được viết và thực hiện khi quá muộn để chúng có thể cung cấp giá trị thực cho dự án
• Luôn có điều gì đó khẩn cấp hơn là dành thời gian để thử nghiệm
• Các nhóm được phân chia giữa các phòng phân tích thử nghiệm, phát triển và phân tích chức năng và chúng thường không đồng bộ
• Không có khả năng tái cấu trúc mã do lo ngại một cái gì đó sẽ bị phá vỡ
• chi phí bảo dưỡng quá cao
• thị trường thời gian đưa ra là quá lớn
• khách hàng không cảm thấy rằng những gì được giao là những gì họ yêu cầu cho
• Tài liệu là không bao giờ được cập nhật
• Bạn đang sợ để triển khai sản xuất bởi vì kết quả không rõ
• Bạn thường tôi không thể triển khai vào sản xuất vì các bài kiểm tra hồi quy mất quá lâu để chạy
• Đội bóng đang dành quá nhiều thời gian cố gắng tìm ra những gì một số phương pháp hoặc lớp học không

Phát triển theo hướng thử nghiệm không giải quyết một cách kỳ diệu tất cả những vấn đề này. Thay vào đó, nó đặt chúng ta trên con đường hướng tới giải pháp. Không có viên đạn bạc, nhưng nếu có một thực hành phát triển có thể tạo ra sự khác biệt ở nhiều cấp độ, thực hành đó là TDD. Tốc độ phát triển theo định hướng tăng thời gian tiếp thị, cho phép tái cấu trúc dễ dàng hơn, giúp tạo ra thiết kế tốt hơn , và nuôi dưỡng khớp nối lỏng lẻo hơn.Trên những lợi ích trực tiếp, TDD là điều kiện tiên quyết cho nhiều thực hành khác (giao hàng liên tục là một trong số chúng). Thiết kế tốt hơn, mã được viết tốt, thời gian tiếp thị nhanh hơn, tài liệu cập nhật và phạm vi kiểm tra vững chắc, là một số kết quả bạn sẽ thực hiện bằng cách áp dụng TDD.