Tìm kiếm Nghiên cứu Điển hình về cách TDD cải thiện Chất lượng và / hoặc Tốc độ Phát triển [đã đóng]

Tại công ty của tôi, tôi đang cố gắng đưa ra một lý do tại sao chúng ta nên làm TDD. Hiện tại hầu hết các nhà phát triển chỉ cần làm bất cứ điều gì có thể để thực hiện dự án, sau đó đi thêm các bài kiểm tra đơn vị sau khi thực tế để đáp ứng các số liệu của người quản lý. Bất kỳ ví dụ từ các công ty có uy tín làm TDD và thấy được lợi ích sẽ được đánh giá rất cao.

Một nghiên cứu về 4 dự án ở IBM và Microsoft. Được đăng trên tạp chí Kỹ thuật phần mềm Emperical .

Nghiên cứu thực nghiệm cho thấy sự phát triển dựa trên thử nghiệm cải thiện chất lượng

Một bài báo được xuất bản lần đầu trên tạp chí Kỹ thuật phần mềm theo kinh nghiệm báo cáo: "TDD dường như có thể áp dụng trong các lĩnh vực khác nhau và có thể giảm đáng kể mật độ khiếm khuyết của phần mềm được phát triển mà không làm giảm đáng kể năng suất của nhóm phát triển." Nghiên cứu đã so sánh 4 dự án, tại Microsoft và IBM đã sử dụng TDD với các dự án tương tự không sử dụng TDD ...

Bài viết bao gồm 1 trường hợp nghiên cứu tại IBM và 3 từ Microsoft. Mỗi nghiên cứu trường hợp so sánh hai nhóm làm việc trên cùng một sản phẩm, sử dụng cùng ngôn ngữ và công nghệ phát triển, dưới cùng một người quản lý cấp cao hơn, chỉ có một nhóm sử dụng phát triển dựa trên thử nghiệm (TDD). Không ai trong số các đội biết rằng họ sẽ là một phần của nghiên cứu trong chu kỳ phát triển của họ. Nghiên cứu trường hợp của IBM đã theo dõi các nhóm thực hiện phát triển trình điều khiển thiết bị. Các trường hợp của Microsoft đã theo dõi các nhóm làm việc trên Windows, MSN và Visual Studio.

Bài viết mô tả các thực hành TDD được các nhóm sử dụng như quy trình công việc từng phút, cũng như quy trình công việc ở cấp độ nhiệm vụ ...

Có một chương về TDD với một nghiên cứu trường hợp trong cuốn sách gần đây, "Làm phần mềm: Cái gì hiệu quả và tại sao chúng tôi tin nó". Nhưng bạn có thể thất vọng, vì nếu tôi nhớ lại một cách chính xác thì nghiên cứu đã không phát hiện ra bất kỳ lợi ích thực sự nào đối với TDD. Dù sao thì nghiên cứu này cũng rất thú vị và cuốn sách nói chung là một trong những cuốn sách phần mềm hay nhất mà tôi đã đọc gần đây. Nó chứa nhiều nghiên cứu trường hợp về những thứ như lập trình cặp, xem lại mã, v.v.

Chắc chắn kiểm tra này: TDD đã được chứng minh hiệu quả! Hoặc là nó?

... Khi Phil Haack tuyên bố rằng Nghiên cứu hỗ trợ Hiệu quả của TDD, tôi quan tâm nhiều hơn đến việc xem báo cáo được liên kết thực sự chứa gì. Phil trích dẫn từ trừu tượng.

Chúng tôi thấy rằng những sinh viên đầu tiên kiểm tra trung bình đã viết nhiều bài kiểm tra hơn và đến lượt mình, những sinh viên viết nhiều bài kiểm tra có xu hướng làm việc hiệu quả hơn. Chúng tôi cũng quan sát thấy rằng chất lượng tối thiểu tăng tuyến tính với số lượng thử nghiệm lập trình viên, không phụ thuộc vào chiến lược phát triển được sử dụng.

Phil rõ ràng đã đọc phần còn lại của báo cáo và cung cấp các tác phẩm yêu thích của mình dường như làm như tiêu đề của ông cho thấy. Tuy nhiên, một trong những điều tôi lo lắng khi thấy những điều hỗ trợ cho các thực tiễn phát triển phần mềm mới nhất và lớn nhất là xu hướng mạnh mẽ đối với xu hướng xác nhận - tìm kiếm xác nhận các lý thuyết hiện tại và xem xét các chỉ số phản biện.

Vì vậy, là loại người tò mò và vì TDD là điều mà tôi đang theo dõi để xem liệu đó có phải là thứ tôi có thể muốn nhận nuôi mình một ngày nào đó không, tôi đã đi vào báo cáo ...

... Không có câu hỏi, thử nghiệm đầu tiên dẫn đến có nhiều thử nghiệm hơn cho mỗi đơn vị chức năng. Câu hỏi là nếu điều này có giá trị. Nghiên cứu này dường như chỉ ra rằng điều này có thể không phải là trường hợp, ít nhất là nếu chất lượng là lợi ích dự định của bạn. Nhưng sau đó, tôi không ngạc nhiên khi số lượng thử nghiệm không tương ứng với chất lượng cũng như tôi không ngạc nhiên khi số lượng dòng mã không tương ứng với năng suất.

Tác giả có rất nhiều điểm tốt về TDD không hiệu quả lắm (imo mặc dù bị thổi phồng đến chết)

xem xét bạn và khách hàng đã dành bao nhiêu thời gian để kiểm tra phần mềm một cách thủ công; so sánh với ước tính thời gian thử nghiệm tự động kiểu TDD sẽ mất bao lâu. Bỏ túi sự khác biệt

theo kinh nghiệm của tôi, các bài kiểm tra tự động của TDD là vàng vì chúng cung cấp bảo hiểm và loại bỏ số lượng lớn các bài kiểm tra thủ công

như Andres F đã chỉ ra, bạn có thể nhận được những lợi ích này chỉ từ kiểm tra tự động, không nhất thiết là TDD - tuy nhiên, TDD yêu cầu kiểm tra tự động thay vì đó là một suy nghĩ hay hay

Bị buộc phải suy nghĩ về việc thử nghiệm trước tiên cũng buộc bạn phải suy nghĩ về các vấn đề liên quan đến chất lượng - chẳng hạn như mô-đun, thiết kế giao diện, v.v. - trước khi bạn bắt đầu viết mã.

Cá nhân, tôi tin rằng một trong những lợi ích lớn nhất của TDD là việc viết bài kiểm tra trước tiên giữ cho đặc điểm kỹ thuật của mã thực sự phải làm mới trong tâm trí của bạn trong khi bạn đang viết mã, thay vì tìm ra nó -as-you-code.

bạn muốn tạo ra trường hợp cho nó: đề nghị bạn thực hiện nó cho dự án tiếp theo, và sau đó học hỏi từ nó. Nếu nó thành ra nó hoạt động tốt cho bạn, thì tôi hy vọng bạn sẽ tiếp tục sử dụng nó và nếu mất nhiều thời gian hơn để thực hiện dự án và / hoặc dành toàn bộ thời gian để viết bài kiểm tra thay vì mã hóa, thì bạn chắc chắn sẽ bỏ nó như một thất bại.

Tôi nghĩ rằng giải pháp trong thế giới thực là (giống như hầu hết mọi thứ) ở giữa chừng, bạn muốn thử nghiệm nhưng bạn không muốn các thử nghiệm quan trọng hơn dự án.

(cá nhân tôi nghĩ TDD là một mốt nhất thời, nghe có vẻ lý thuyết, nhưng trên thực tế ... không tốt lắm. Tôi thấy thử nghiệm tích hợp quan trọng hơn nhiều, nhưng đó có thể chỉ là loại dự án phức tạp mà tôi làm việc).

Tôi đã làm việc sử dụng TDD được 2 năm và tại thời điểm đó tôi làm việc, tất cả chúng tôi đều miễn cưỡng sử dụng kể cả người quản lý. Tuy nhiên, điều đó sớm trở thành điều đúng đắn. Những lợi ích mà chúng tôi sớm nhận thấy là

• Phát hiện ra lỗi ở giai đoạn đầu.
• Viết mã tốt hơn mà không nhận ra.
• Mã của bạn bây giờ có thể được bảo trì nhiều hơn do thử nghiệm của bạn chỉ ở dạng khối nhỏ (chúng tôi đã có các chức năng là 300-400 dòng) một cách ngớ ngẩn. Bây giờ tối đa 30 và tất cả các thử nghiệm không thường xuyên.

Các nhà quản lý sẽ không biết vì tất cả họ đều quan tâm đến một điều "Bạn đã hoàn thành". Nhưng sau đó họ phàn nàn khi phần mềm tiếp tục bị hỏng mà không nhận ra. Với độ bao phủ tốt và các bài kiểm tra hợp lý. Đây không phải là số lượng mà là chất lượng bạn thực sự có thể thấy khi ai đó phá vỡ chức năng. Thật không may, thật khó khăn nếu bạn tự mình làm việc. Tôi cũng gặp vấn đề tương tự, vì bạn có thể cần phải thay đổi mã, ví dụ như các lớp cơ sở, v.v. để bạn có thể kiểm tra các phần của phần mềm.

Tôi cho bạn một ví dụ. Tôi muốn giả lập kho lưu trữ nhưng không có giao diện và tôi cần đưa kho lưu trữ vào lớp dịch vụ của mình và do đó thêm / sửa đổi một hàm tạo trên toàn bộ cửa hàng, điều này hóa ra là một vấn đề lớn nhưng trong cuối cùng tôi có hơn 200 bài kiểm tra chỉ kiểm tra một khu vực của hệ thống và họ đã rất ấn tượng.

Tôi thường làm như sau:

• Tôi giữ sự không kiên định của mình rất ngắn
• Chỉ có 1 khẳng định. Không có roulette Nga.
• Tôi kiểm tra một kịch bản ngoại lệ tích cực và ngoại lệ

Về nghiên cứu trường hợp tôi sợ, tôi không chắc tôi đã thấy bất kỳ. Bạn cần xây dựng dự án của bạn và trở thành nghiên cứu điển hình của bạn. Họ cũng có thể bị ấn tượng.

Tôi hy vọng nó sẽ giúp