Kiểm tra hướng phát triển - thuyết phục tôi! [đóng cửa]

Tôi biết một số người là những người ủng hộ lớn cho sự phát triển theo hướng thử nghiệm. Tôi đã sử dụng các bài kiểm tra đơn vị trong quá khứ, nhưng chỉ để kiểm tra các hoạt động có thể được kiểm tra dễ dàng hoặc điều mà tôi tin rằng sẽ hoàn toàn có thể đúng. Toàn bộ hoặc gần hoàn thành mã bảo hiểm có vẻ như sẽ mất rất nhiều thời gian.

1. Những dự án nào bạn sử dụng phát triển dựa trên thử nghiệm cho? Bạn chỉ sử dụng nó cho các dự án trên một kích thước nhất định?
2. Tôi có nên sử dụng nó hay không? Thuyết phục tôi!

Ok, một số lợi thế cho TDD:

1. Nó có nghĩa là bạn kết thúc với nhiều bài kiểm tra. Mọi người đều thích có bài kiểm tra, nhưng ít người thích viết chúng. Xây dựng bài kiểm tra viết vào dòng phát triển của bạn có nghĩa là bạn kết thúc với nhiều bài kiểm tra hơn.
2. Viết cho một bài kiểm tra buộc bạn phải suy nghĩ về khả năng kiểm tra của thiết kế của bạn, và thiết kế có thể kiểm tra hầu như luôn luôn là thiết kế tốt hơn. Tôi không hoàn toàn rõ ràng tại sao điều này lại xảy ra như vậy, nhưng kinh nghiệm của tôi và của hầu hết các nhà truyền giáo TDD dường như đã chịu đựng được.
3. Đây là một nghiên cứu nói rằng mặc dù TDD mất nhiều thời gian hơn để viết, nhưng lợi tức đầu tư tốt vì bạn nhận được mã chất lượng cao hơn và do đó ít sửa lỗi hơn.
4. Nó giúp bạn tự tin trong việc tái cấu trúc. Đó là một cảm giác tuyệt vời khi có thể thay đổi một hệ thống mà không phải lo lắng về việc phá vỡ mọi thứ khác bởi vì nó được bao phủ khá tốt bởi các bài kiểm tra đơn vị.
5. Bạn gần như không bao giờ gặp lỗi lặp lại, vì mỗi lỗi bạn tìm thấy nên kiểm tra trước khi sửa.

Bạn yêu cầu được thuyết phục, vì vậy đây là những lợi ích. Xem câu hỏi này để có cái nhìn cân bằng hơn.

Robert C. Martin ban đầu đã đưa ra những điểm này - tôi có thể sao lưu chúng từ kinh nghiệm của chính mình:

• Bạn sẽ tự động xây dựng một bộ kiểm tra hồi quy của các bài kiểm tra đơn vị khi bạn đi.
• Bạn sẽ hầu như không bao giờ dành thời gian để gỡ lỗi, vì nếu bạn tự mã hóa một lỗ hổng, việc hoàn tác mã của bạn đến điểm khi thử nghiệm cuối cùng được thực hiện sẽ dễ dàng hơn, thay vì mở trình gỡ lỗi.
• Cứ sau vài phút bạn xác minh rằng mã của bạn hoạt động - tất cả mã đó (hoặc ít nhất là tất cả các hành vi được bao phủ bởi các thử nghiệm, nếu bạn đang thực hiện TDD thì tỷ lệ rất cao của nó).

Tôi thường xuyên làm TDD mọi lúc, cho dù tôi đang làm việc về sản xuất hay chơi mã; Tôi thấy khó khăn để mã hóa bất kỳ cách nào khác những ngày này.

(Tuyên bố miễn trừ trách nhiệm: Tôi hầu như không thực hiện bất kỳ nội dung UI nào, vì vậy tôi không thể thảo luận về TDD cho UI.)

Tôi sử dụng TDD trong hầu hết mọi thứ tôi làm, từ các ứng dụng tầm thường đến toàn bộ ngăn xếp SIP.

Tôi không sử dụng TDD trong một trang web PHP cũ mà tôi đã tiếp quản. Tôi thấy đau đớn khi không có xét nghiệm. Và tôi thấy vô cùng khó chịu khi vô tình phá vỡ các phần của trang web vì tôi không có bộ kiểm tra hồi quy cho tôi biết tôi đã phá vỡ thứ gì đó. Khách hàng không có ngân sách để tôi (a) viết các bài kiểm tra cho cơ sở mã và (b) trong quy trình làm cho mã có thể kiểm tra được ngay từ đầu, vì vậy tôi chỉ cần đưa ra.

• Bất cứ khi nào khách hàng của bạn có thể được cung cấp hiệu quả hơn (họ có thể sẽ liên quan tốt đến các thử nghiệm - và ít nhất nó sẽ cắt giảm cuộc thảo luận cuối dự án)
• Bất cứ khi nào sẽ mất nhiều thời gian hơn, hãy thông báo cho các nhà đồng phát triển của bạn về MỌI THỨ trong mã hơn là nỗ lực xây dựng thử nghiệm - và điều này sớm hơn bạn nghĩ

Gì? Không có câu trả lời tiêu cực!?

Tuyên bố miễn trừ trách nhiệm: Tôi không chống thử nghiệm đơn vị. Khi mọi người nói TDD, tôi cho rằng họ có nghĩa là phiên bản nghe có vẻ bệnh khi họ viết bài kiểm tra trước khi họ viết mã cho 80-100% tất cả mã họ viết.

Tôi sẽ tranh cãi:

• Đó là một kẻ gây rối. Nếu việc nắm bắt các vấn đề hồi quy là một vấn đề rất lớn đối với bạn thì TDD tự động hoàn toàn ngay từ đầu có vẻ đáng giá, viết bài kiểm tra cho mỗi đoạn mã cuối cùng bạn viết, thực sự có thể giúp bạn bỏ qua vấn đề thực sự.

• Nó giúp mọi người bỏ qua vấn đề thực sự. Khi sửa một lỗi biến thành một trò chơi đánh đòn trong đó có thêm hai cửa sổ bật lên, kiến ​​trúc sẽ nổ tung. Tiêu điểm. Tập trung vào vấn đề thực sự. Nhìn thấy nốt ruồi trước khi chúng phải bị đánh là gọn gàng nhưng bạn không nên ở đó ngay từ đầu.

• Nó ăn rất nhiều thời gian. Tôi thỉnh thoảng gặp lỗi. Tôi không nhấn nhiều đến mức có vẻ đáng để tiền tố mọi thứ mới tôi viết với một bài kiểm tra cho nó. Nắm bắt các vấn đề mà chúng có khả năng xảy ra. Xử lý các lỗi sao cho dễ chẩn đoán. Xác thực. Kiểm tra tại các điểm quan trọng của chồng chéo / nút cổ chai. Nhưng để khóc thật to, đừng kiểm tra từng người nhận cuối cùng và người thiết lập trong một thứ mà có lẽ không nên có những thứ đó ngay từ đầu.

• Thiết kế tập trung: Hoàn toàn không có cách nào ngay cả một nhà phát triển giỏi sẽ viết mã tốt nhất có thể khi họ cũng đang tập trung vào thử nghiệm. Nếu nó có vẻ như là cách duy nhất bạn có thể có một thiết kế hợp lý, tôi khuyên bạn nên xem phần trên về "tập trung vào vấn đề thực sự."

• Thất bại trong thiết kế vĩ mô: Cơ sở mã hóa trong công việc hiện tại của tôi bị đánh đố với các giao diện không bao giờ được sử dụng nhiều hơn một lần và vi phạm nguyên tắc DRY cơ bản mà cuối cùng tôi chỉ bắt đầu hiểu khi tôi nhận ra mọi người đang viết cho các khung kiểm tra và thử nghiệm chung. Kiểm tra không nên dẫn đến kiến ​​trúc ngu ngốc. Không thực sự, không có gì có khả năng mở rộng hoặc đáng doanh nghiệp hơn bằng cách sao chép và dán 20 tệp và sau đó chỉ thực hiện thay đổi đáng kể cho hai trong số chúng. Ý tưởng là để tách các mối quan tâm, không phân chia chúng xuống giữa. Cruft và trừu tượng vô nghĩa sẽ khiến bạn tốn nhiều tiền hơn là không có phạm vi bảo hiểm 95% từng có.

• Nó thực sự phổ biến và rất nhiều người thực sự, thực sự thích nó. Nếu điều đó không đủ lý do để ít nhất là đoán thứ hai và / hoặc bác sĩ tào lao ra khỏi bất kỳ công nghệ nào trước khi áp dụng, hãy tìm hiểu cho bạn một số hoang tưởng.