TDD với nguồn lực hạn chế


13

Tôi làm việc trong một công ty lớn, nhưng trong một nhóm chỉ có hai người phát triển các ứng dụng LOB trên máy tính để bàn. Tôi đã nghiên cứu TDD khá lâu rồi và mặc dù rất dễ nhận ra lợi ích của nó đối với các ứng dụng lớn hơn, tôi gặp khó khăn khi cố gắng chứng minh thời gian bắt đầu sử dụng TDD trên quy mô của các ứng dụng của chúng tôi.

Tôi hiểu lợi thế của nó trong việc tự động hóa thử nghiệm, cải thiện khả năng bảo trì, v.v., nhưng trên quy mô của chúng tôi, việc viết các thử nghiệm đơn vị cơ bản cho tất cả các thành phần của chúng tôi có thể dễ dàng tăng gấp đôi thời gian phát triển. Vì chúng tôi đã không bị ảnh hưởng với thời hạn cuối cùng, tôi không chắc nên đi theo hướng nào. Trong khi các thực tiễn khác như phát triển lặp lại nhanh nhẹn trở nên hoàn hảo kể từ đó, tôi lại cảm thấy khó chịu với sự đánh đổi năng suất của TDD trong một nhóm nhỏ.

Những lợi thế của TDD có xứng đáng với thời gian phát triển thêm trên các đội nhỏ với lịch trình rất chặt chẽ không?


LOB có nghĩa là gì? Ngành kinh doanh?
gnat

Câu trả lời:


14

Sự thật xấu xí là ban đầu nó sẽ làm bạn chậm lại . Bất kỳ quá trình hoặc thực hành mới đôi khi phải tăng cường. Theo kinh nghiệm của tôi, TDD không xuất chi với việc triển khai ban đầu nhiều như với bảo trì, sửa lỗi và mở rộng. Tôi biết đối với những người khác có một khoản thanh toán ngay lập tức, vì vậy nó sẽ phụ thuộc vào phong cách mã hóa hiện tại của mỗi người.

Trong khi tôi là một người ủng hộ TDD rất lớn (tôi đã đưa nó vào công việc hiện tại của tôi) tôi nghĩ bạn cần có một phòng thở nhỏ (thời hạn / thời gian) để khám phá và hiểu thực tiễn.

Nhóm của bạn càng nhỏ, bạn càng có thể hưởng lợi ngay từ TDD. Tôi đã thấy khoản thanh toán này ở quy mô đội từ 6 đến 3.


2
+1: không phải là tiết kiệm thời gian phát triển, nó tiết kiệm (rất nhiều!) Trong thời gian gỡ lỗi và bảo trì.
Javier

4
"Nếu bạn nghĩ rằng bản thử nghiệm đầu tiên là đắt tiền, hãy thử gỡ lỗi sau"
Ryan Bigg

@Ryan Bigg: Tôi đồng ý rằng các bài kiểm tra đơn vị là một hỗ trợ tuyệt vời để gỡ lỗi nhưng mã được viết tốt thực sự không khó để gỡ lỗi với trình gỡ lỗi truyền thống.
Giorgio

@Giorgio: mã có thể được viết càng tốt càng tốt, khi bạn không thể kiểm tra mã riêng lẻ vì thiếu cơ sở hạ tầng xung quanh mã đó, chu trình kiểm tra / gỡ lỗi / thay đổi / kiểm tra lại cần thêm thời gian. Điều đó đặc biệt đúng khi bạn đang tìm kiếm một lỗi mà bạn không biết nguyên nhân gốc và bạn không biết nơi nào trong 100K dòng mã được viết tốt của bạn, sự thất bại có thể xảy ra.
Doc Brown

10

Thời gian phát triển thêm mà bạn đang nói có thể là một ảo ảnh .

Điều làm cho TDD khác với thử nghiệm đơn vị tiêu chuẩn là nó không chỉ được sử dụng để thực hiện các thử nghiệm.

TDD is a new way of developing software. Đó là một trong những cách tốt nhất mà tôi biết.

Do đó, nó không liên quan đến quy mô dự án của bạn. Bạn sẽ trích xuất những lợi ích từ dòng mã đầu tiên .

  • nó sẽ buộc bạn cấu trúc mã của mình theo cách nó sẽ dễ bảo trì và tái sử dụng hơn. Nó thúc đẩy thiết kế phần mềm của bạn.
  • nó sẽ làm cho tái cấu trúc nhanh, an toàn và thú vị.
  • nó giúp bạn viết các phần nhỏ hơn của các chức năng giúp cho việc thực hiện các nhiệm vụ dễ dàng hơn nhiều.
  • nó thường làm cho công việc gỡ lỗi ít thường xuyên hơn.

Tôi định trả lời, nhưng Pierre nói tốt. Bắt đầu nhỏ, trên một cái gì đó mà bạn phải xây dựng bằng mọi cách, và bạn nên bắt đầu những lợi ích ngay ngày đầu tiên.
Marcie

2
Nó cũng có thể không phải là ảo ảnh. Một thực hành mới có thể mất một lúc để bắt đầu. Đặc biệt là nếu không có ai xung quanh đã làm điều đó. Tôi có thể nói nó có thể đi một trong hai cách thân mật.
dietbuddha

@dietbuddha: Tôi đồng ý với điều đó, tôi ngần ngại đưa ra một số từ chối trách nhiệm, nhưng tôi muốn nhấn mạnh vào lợi ích thực sự trên TDD khi áp dụng tốt.

1
@Pierre - TDD dường như có một bước đầu tiên đặc biệt khó chịu (và tôi nói từ những cuộc đấu tranh lặp đi lặp lại của mình để bắt đầu) phải chịu đựng cùng một vấn đề tức là quá nhiều việc phải làm và quá ít thời gian. Tôi không cần phải bị thuyết phục về những lợi ích - nhưng tự mình khởi động và sau đó các đồng nghiệp của tôi hiện đang vượt xa tôi (bạn sẽ phải tin rằng đó không phải là thiếu khả năng của tôi ...) - một phần vì áp lực của thời gian và một phần vì không biết khá
Murph

1
@Murph: Bạn đang làm việc trên các ứng dụng tăng cường UI? Tôi có xu hướng ngừng sử dụng nó khi tôi làm việc trên các ứng dụng như vậy.

8

quan niệm sai lầm phổ biến, hãy để tôi hét lên:

KIỂM TRA TRONG TDD LÀ ĐẶC ĐIỂM

EOM.

Chỉnh sửa: hãy để tôi giải thích: "viết ... kiểm tra đơn vị cho tất cả hoặc các thành phần của chúng tôi" là kiểm tra đơn vị , không phải TDD. Tôi thường xuyên sử dụng TDD cho các đội một người với thành công lớn; mức chi trả là phi thường.


1
quan niệm sai lầm phổ biến, TDD tạo ra các thử nghiệm dự án. Thực tế là TDD tạo ra các thông số kỹ thuật của dự án.
Tên hiển thị

3

Có một cuốn sách tuyệt vời về TDD, Nghệ thuật thử nghiệm đơn vị ( trang web chính thức ) có các ví dụ trong .net với phiên bản java trên các tác phẩm. Phần tốt là có toàn bộ các chương xem xét các vấn đề như "Tích hợp thử nghiệm đơn vị vào tổ chức" - Chương 8 và "Làm việc với mã kế thừa" - Chương 9. Mặc dù tôi không phải là chuyên gia về lĩnh vực này (chưa :-)) , dựa trên kinh nghiệm của tôi, tôi tin rằng đây là điểm khởi đầu tốt.

Nghệ thuật kiểm tra đơn vị


1

Có một vài câu hỏi bạn cần để có câu trả lời cho:

  1. Bạn dành bao nhiêu thời gian sau khi phát hành sửa lỗi trong mã? Nếu bạn có thể định lượng được điều này, bạn có thể thấy rằng nó bằng hoặc thậm chí vượt quá thời gian "thêm", bạn sẽ phải viết bài kiểm tra giúp ngăn chặn các lỗi này xảy ra.

  2. Làm thế nào thường xuyên chỉnh sửa rõ ràng thẳng về phía trước để cấu trúc lại mã hoặc thêm tính năng mới đã phá vỡ một cái gì đó dường như không liên quan? Một lần nữa với phạm vi kiểm tra tốt những điều này có thể được giảm.

Ngay cả khi bạn không thể đặt con số chính xác cho những con số này, bạn vẫn có thể chứng minh rằng dù sao bạn cũng dành thời gian này để bạn cũng có thể sử dụng nó "trước mắt" và (hy vọng) kết thúc với một sản phẩm ổn định hơn nhiều.


1

Khi mọi người nói chuyện với tôi về việc bắt đầu áp dụng thử nghiệm trong nhóm của họ, trước tiên tôi luôn kiểm tra xem các thử nghiệm sẽ được chạy như thế nào. Thông thường các đội không có một bản dựng liên tục tại chỗ. Nếu bạn có nguồn lực hạn chế thì tôi khuyên bạn nên thiết lập máy chủ CI là điều kiện tiên quyết để bắt đầu bất kỳ bước đột phá nghiêm trọng nào vào thử nghiệm.

Khi bạn đã có thiết lập đó, hãy bắt đầu thực hành TDD. Hãy nhớ rằng nếu hệ thống chưa được phát triển với thử nghiệm, bạn có thể đấu tranh để làm cho mã hiện tại có thể kiểm tra được và sẽ rất tốn kém khi cơ cấu lại nó.

Bắt đầu bằng cách tìm kiếm những nơi dễ dàng để bắt đầu với TDD - các lớp hoặc mô-đun mới, với một vài phụ thuộc. Các lớp tiện ích và cấu trúc dữ liệu thường là những thứ tốt để bắt đầu.

Hãy cảm nhận về cách nó thay đổi cách bạn nghĩ về mã của bạn, lưu ý rằng mã bạn sản xuất tốt hơn bao nhiêu và bạn tự tin hơn về mã đó như thế nào.

Tôi biết tôi chưa thực sự trả lời câu hỏi, nhưng tôi đoán quan điểm của tôi là bạn sẽ có thể làm tất cả những điều này mà không phải trả thêm chi phí lớn. Khi thực hiện các ví dụ đầu tiên, bạn sẽ hiểu rõ hơn về các lợi thế cho dự án của mình.

Điểm mấu chốt - phát triển chậm hơn, nhưng ít lỗi, vì vậy thời gian sửa lỗi ít hơn.


1
Một bổ sung: Ban đầu, tìm kiếm các bài kiểm tra giá trị cao nhất. Các thử nghiệm cho bạn biết, sớm, bạn đã phá vỡ cơ sở mã của mình. Những bài kiểm tra này có xu hướng cao, các bài kiểm tra sâu rộng không cho bạn biết những gì bạn đã phá vỡ, nhưng bạn đã phá vỡ nó. Bạn sẽ nhanh chóng thấy giá trị của một CI, với thử nghiệm, môi trường. Sử dụng các bài kiểm tra để gỡ lỗi. Với một hệ thống sẵn có, chi phí cho việc thêm các bài kiểm tra mới bắt đầu trở nên dễ dàng hơn / rẻ hơn và bạn có thể tập trung vào nhiều bài kiểm tra hơn để chứng minh rằng nó hoạt động tốt và hiển thị ở đâu không.
Jim Rush

0

Đây là nơi tôi nghĩ rằng Phát triển hướng hành vi cho thấy lợi ích ngay lập tức, nhưng tôi không chắc rằng phát triển theo hướng thử nghiệm có.

Trong phát triển theo hướng hành vi, bạn tiếp cận vé của mình theo một cách khác: bạn ngồi xuống với người kinh doanh và làm việc với họ để xác định các hành vi mà khối chức năng này nên có. Tôi mô tả điều này trong một mục trên blog của tôi, (tiêu đề bài viết: Viết hành vi ).

Ngồi xuống với người kinh doanh hoặc bất kỳ ai sẽ giúp bạn và họ hiểu rõ hơn những gì hệ thống cần làm để mọi người hài lòng với chức năng đó. Những gì nó cần làm để có thể được chấp nhận bởi quy trình QA mà bạn có tại chỗ.

Xác định tiêu chí kiểm tra, sau đó viết các tiêu chí kiểm tra đó vào bộ kiểm tra tự động của bạn, sẽ làm giảm số lượng bạn nhận được: ai đó tuyên bố chức năng bị hỏng, vì bạn đã bỏ lỡ điều gì đó (vì bạn đã bỏ lỡ điều gì đó một cách hợp pháp hoặc vì họ không bao giờ nói bạn về nó).

Nó cũng có thể giúp nhận thức của nhóm khác về nhóm của bạn: nếu bạn ngồi xuống và xác định những gì cần phải làm trong hệ thống, bạn có thể đi từ "những kẻ ngốc vượt qua mọi thứ và dành thời gian cho những thứ chúng tôi không yêu cầu", đến, "Dân gian thông minh đang đến với các tính năng hữu ích".

TL; DR: Phát triển hướng hành vi có thể cho thấy sự cải thiện nhanh chóng vì đó là "khách hàng" tập trung. Kiểm tra hướng phát triển, đối với tôi, dường như là về thử nghiệm nội bộ của cơ sở mã mà "không ai" quan tâm và mang lại lợi ích kinh doanh ít rõ ràng hơn. . , họ đang có một cuộc họp về Tính năng X, có nghĩa là có sự tiến bộ trên mặt trận đó! ")

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.