Thử nghiệm đơn vị nghe có vẻ tuyệt vời đối với tôi, nhưng tôi không chắc mình nên dành thời gian thực sự học nó trừ khi tôi có thể thuyết phục người khác rằng nó có giá trị quan trọng. Tôi phải thuyết phục các lập trình viên khác và quan trọng hơn là các nhân viên quản lý, rằng tất cả thời gian dành cho việc học khung kiểm tra, viết bài kiểm tra, cập nhật chúng, v.v. sẽ tự trả tiền, và sau đó là một số.

Có bằng chứng gì? Có ai thực sự phát triển cùng một phần mềm với hai nhóm riêng biệt, một nhóm sử dụng thử nghiệm đơn vị và nhóm kia không, và so sánh kết quả? Tôi nghi ngờ điều đó. Tôi chỉ có nghĩa vụ phải biện minh cho nó, "Hãy tìm nó trên Internet, mọi người đang nói về nó, vì vậy đó phải là điều đúng đắn"?

Đâu là bằng chứng cứng sẽ thuyết phục các giáo dân rằng thử nghiệm đơn vị là đáng để nỗ lực?

Đúng. Đây là một liên kết đến một nghiên cứu của Boby George và Laurie Williams tại NCST và một nghiên cứu khác của Nagappan et al. Tôi chắc chắn có nhiều hơn nữa. Các ấn phẩm của Tiến sĩ Williams về thử nghiệm có thể cung cấp một điểm khởi đầu tốt để tìm thấy chúng.

[EDIT] Hai bài báo trên tham khảo cụ thể về TDD và cho thấy thời gian phát triển ban đầu tăng 15 - 35% sau khi áp dụng TDD, nhưng giảm 40-90% các khiếm khuyết trước khi phát hành. Nếu bạn không thể có được các phiên bản văn bản đầy đủ, tôi khuyên bạn nên sử dụng Google Scholar để xem liệu bạn có thể tìm thấy phiên bản công khai không.

"Tôi phải thuyết phục các lập trình viên khác và quan trọng hơn là các nhân viên quản lý, rằng tất cả thời gian dành cho việc học khung kiểm tra, viết bài kiểm tra, giữ cho họ cập nhật, v.v. sẽ tự trả tiền, và sau đó là một số. "

Tại sao?

Tại sao không làm điều đó, lặng lẽ và rời rạc. Bạn không cần phải làm tất cả cùng một lúc. Bạn có thể làm điều này trong những mảnh nhỏ.

Việc học khung mất rất ít thời gian.

Viết một bài kiểm tra, chỉ một, mất rất ít thời gian.

Không có thử nghiệm đơn vị, tất cả những gì bạn có là sự tự tin về phần mềm của bạn. Với một bài kiểm tra đơn vị, bạn vẫn có sự tự tin của mình, cộng với bằng chứng rằng ít nhất một bài kiểm tra đã vượt qua.

Đó là tất cả những gì nó cần. Không ai cần biết bạn đang làm điều đó. Cứ làm đi.

Tôi có một cách tiếp cận khác về điều này:

Điều gì đảm bảo bạn có mã của bạn là chính xác? Hoặc nó không phá vỡ giả định X khi ai đó trong nhóm của bạn thay đổi func1 ()? Nếu không có bài kiểm tra đơn vị giữ cho bạn 'trung thực', tôi không chắc bạn có nhiều sự đảm bảo.

Khái niệm giữ các bài kiểm tra cập nhật là thú vị. Các bài kiểm tra thường không phải thay đổi. Tôi đã nhận được gấp 3 mã kiểm tra so với mã sản xuất và mã kiểm tra đã được thay đổi rất ít. Tuy nhiên, đó là điều cho phép tôi ngủ ngon vào ban đêm và điều cho phép tôi nói với khách hàng rằng tôi tin tưởng rằng tôi có thể thực hiện chức năng Y mà không làm hỏng hệ thống.

Có lẽ trong giới hàn lâm có bằng chứng, nhưng tôi chưa bao giờ làm việc ở bất cứ đâu trong thế giới thương mại nơi mà bất cứ ai cũng sẽ trả tiền cho một bài kiểm tra như vậy. Tuy nhiên, tôi có thể nói với bạn rằng nó hoạt động tốt với tôi, mất ít thời gian để làm quen với khung kiểm tra và kiểm tra viết khiến tôi thực sự nghĩ về yêu cầu của mình và thiết kế, hơn rất nhiều so với khi tôi làm việc trong các nhóm đã viết không có bài kiểm tra.

Đây là nơi nó tự trả tiền: 1) Bạn có niềm tin vào mã của mình và 2) Bạn gặp vấn đề sớm hơn so với cách khác. Bạn không có anh chàng QA nói "này, bạn không bận tâm đến việc kiểm tra hàm xyz () phải không? Anh ta không tìm thấy lỗi đó vì bạn đã tìm thấy nó một tháng trước. Điều đó tốt cho Anh ấy, tốt cho bạn, tốt cho công ty và tốt cho khách hàng.

Rõ ràng đây là giai thoại, nhưng nó đã làm việc kỳ diệu đối với tôi. Không chắc chắn tôi có thể cung cấp cho bạn bảng tính, nhưng khách hàng của tôi rất vui và đó là mục tiêu cuối cùng.

Chúng tôi đã chứng minh bằng chứng cứng rằng có thể viết phần mềm tào lao mà không cần Kiểm thử đơn vị. Tôi tin rằng thậm chí còn có bằng chứng cho phần mềm crappy với Kiểm thử đơn vị. Nhưng đây không phải vấn đề.

Kiểm thử đơn vị hoặc Phát triển hướng thử nghiệm (TDD) là một kỹ thuật Thiết kế, không phải là kỹ thuật kiểm tra. Mã được kiểm tra bằng văn bản trông hoàn toàn khác với mã không.

Mặc dù đây không phải là câu hỏi của bạn, tôi tự hỏi liệu đây có thực sự là cách dễ nhất để đi xuống đường và trả lời các câu hỏi (và đưa ra bằng chứng có thể bị thách thức bởi các báo cáo khác) có thể bị hỏi sai. Ngay cả khi bạn tìm thấy bằng chứng cứng cho trường hợp của bạn - người khác có thể tìm thấy bằng chứng cứng chống lại.

Có phải việc kinh doanh của quầy đậu để xác định người kỹ thuật nên làm việc như thế nào? Có phải họ đang cung cấp các công cụ rẻ nhất trong mọi trường hợp bởi vì họ tin rằng bạn không cần những công cụ đắt tiền hơn?

Lập luận này hoặc là chiến thắng dựa trên niềm tin (một trong những giá trị cơ bản của các đội nhanh nhẹn) hoặc bị mất dựa trên sức mạnh vai trò của bên chiến thắng. Ngay cả khi những người đề xướng TDD giành chiến thắng dựa trên sức mạnh vai trò, tôi vẫn coi đó là mất.

Nếu bạn cũng quan tâm đến bằng chứng chống lại thử nghiệm đơn vị thì đây là một bài viết được nghiên cứu và suy nghĩ kỹ:

Tại sao hầu hết các thử nghiệm đơn vị là lãng phí của James O Coplien (guru gầy và nhanh nhẹn)

Nói thêm về TDD hơn là kiểm tra đơn vị nghiêm ngặt, đây là một liên kết đến việc cải thiện chất lượng thông qua phát triển theo hướng kiểm tra: kết quả và kinh nghiệm của bốn nhóm nghiên cứu công nghiệp , bởi Nagappan, E. Michael Maximilien, Thirumalesh Bhat và Laurie Williams. bài báo được xuất bản bởi nhóm Kỹ thuật phần mềm và đo lường thực nghiệm (ESM) của Microsoft và đã được đề cập ở đây.

Nhóm nghiên cứu nhận thấy rằng các nhóm TDD đã tạo ra mã tốt hơn từ 60% đến 90% (về mật độ khiếm khuyết) so với các nhóm không TDD. Tuy nhiên, các đội TDD mất từ ​​15% đến 35% để hoàn thành các dự án của họ.

Đây là một bài đọc tuyệt vời và thú vị về một anh chàng thay đổi công ty của mình từ bên trong. Nó không giới hạn ở TDD. http://jamesshore.com/Change-Derator/ Lưu ý rằng ông đã không thuyết phục được "quầy đậu" trong một thời gian và thay vào đó đã thực hiện "chiến thuật du kích".

Chỉ cần thêm thông tin vào các câu trả lời này, có hai tài nguyên phân tích tổng hợp có thể giúp tìm ra các hiệu ứng năng suất & chất lượng trên nền tảng học thuật và công nghiệp:

Giới thiệu của biên tập viên khách: TDD từ Nghệ thuật lập trình không sợ hãi [ link ]

Tất cả các nhà nghiên cứu dường như đồng ý rằng TDD khuyến khích tập trung vào nhiệm vụ tốt hơn và bảo hiểm thử nghiệm. Thực tế của nhiều thử nghiệm không nhất thiết có nghĩa là chất lượng phần mềm sẽ tốt hơn, nhưng sự chú ý của lập trình viên ngày càng tăng đối với thiết kế thử nghiệm vẫn rất đáng khích lệ. Nếu chúng ta xem thử nghiệm là lấy mẫu một lượng rất lớn các hành vi tiềm năng, thì nhiều thử nghiệm hơn có nghĩa là một mẫu kỹ lưỡng hơn. Trong phạm vi mà mỗi bài kiểm tra có thể tìm thấy một vấn đề quan trọng mà không ai trong số các bài kiểm tra khác có thể tìm thấy, các bài kiểm tra rất hữu ích, đặc biệt là nếu bạn có thể chạy chúng với giá rẻ.

Bảng 1. Tóm tắt các nghiên cứu thực nghiệm được lựa chọn về phát triển dựa trên thử nghiệm: những người tham gia ngành *

Bảng 2. Tóm tắt các nghiên cứu thực nghiệm được lựa chọn về TDD: người tham gia học tập *

Tác động của phát triển dựa trên thử nghiệm đối với chất lượng và năng suất bên ngoài: Phân tích tổng hợp [ link ]

Trừu tượng:

Bài viết này cung cấp một phân tích tổng hợp có hệ thống của 27 nghiên cứu điều tra tác động của Phát triển dựa trên thử nghiệm (TDD) đến chất lượng và năng suất mã bên ngoài.

Kết quả chỉ ra rằng, nói chung, TDD có ảnh hưởng tích cực nhỏ đến chất lượng nhưng ít hoặc không ảnh hưởng rõ rệt đến năng suất. Tuy nhiên, phân tích phân nhóm đã tìm thấy cả sự cải thiện chất lượng và giảm năng suất sẽ lớn hơn nhiều trong các nghiên cứu công nghiệp so với các nghiên cứu học thuật. Một sự sụt giảm năng suất lớn hơn đã được tìm thấy trong các nghiên cứu trong đó sự khác biệt về nỗ lực thử nghiệm giữa TDD và quy trình của nhóm kiểm soát là rất đáng kể. Một sự cải thiện lớn hơn về chất lượng cũng được tìm thấy trong các nghiên cứu học thuật khi sự khác biệt trong nỗ lực kiểm tra là đáng kể; tuy nhiên, không có kết luận nào có thể được rút ra liên quan đến các nghiên cứu công nghiệp do thiếu dữ liệu.

Cuối cùng, ảnh hưởng của trải nghiệm nhà phát triển và quy mô nhiệm vụ khi các biến số của người điều hành đã được nghiên cứu và mối tương quan tích cực có ý nghĩa thống kê đã được tìm thấy giữa kích thước nhiệm vụ và mức độ cải thiện chất lượng.

Vâng, có một số công ty lớn yêu cầu bạn sử dụng thử nghiệm đơn vị nhưng nếu bạn là một công ty nhỏ tại sao lại bắt chước những công ty lớn?

Đối với tôi khi tôi bắt đầu thử nghiệm đơn vị, nhiều năm trước, (ngày nay chúng tôi chủ yếu sử dụng mô hình hành vi ) đó là vì tôi không thể kiểm soát tất cả các đường dẫn trong một ứng dụng.

Tôi đã quen với việc lập trình dưới cùng và REPL vì vậy khi tôi có Bài kiểm tra đơn vị (Một bài kiểm tra cho mọi chức năng), nó giống như mang lại một REPL cho các ngôn ngữ có rất nhiều biên dịch. Nó mang lại niềm vui cho mỗi dòng mã tôi đã viết. Tôi cảm thấy chúa. Tôi thích nó. Tôi không cần một báo cáo để nói với tôi rằng tôi đã bắt đầu viết mã tốt hơn nhanh hơn. Sếp của tôi không cần báo cáo để thông báo rằng vì chúng tôi làm những việc điên rồ nên chúng tôi đột nhiên không bao giờ bỏ lỡ thời hạn. Sếp của tôi không cần báo cáo để nhận thấy rằng số lỗi "đơn giản" giảm từ (đến nhiều) xuống gần như không vì điều này rất lạ khi viết mã phi sản xuất.

Như một poster khác đã được viết, bạn không sử dụng TDD để Kiểm tra (xác minh). Bạn viết nó để nắm bắt đặc tả, hành vi của đơn vị của bạn (đối tượng, mô-đun, chức năng, lớp, máy chủ, cụm) hoạt động.

Có rất nhiều thất bại và câu chuyện thành công khi chuyển sang một mô hình phát triển phần mềm khác nhau ở rất nhiều công ty.

Tôi chỉ bắt đầu sử dụng nó bất cứ khi nào tôi có một cái gì đó mới để viết. Có một câu nói cũ rất khó để tôi dịch sang tiếng Anh nhưng:

Bắt đầu với một cái gì đó đơn giản đến mức bạn không nhận thấy rằng bạn làm điều đó. Khi tập luyện cho một cuộc đua marathon, hãy bắt đầu bằng cách đi bộ 9 mét và chạy 1 mét, lặp lại.

Có số liệu thống kê chứng minh rằng việc sửa một lỗi được tìm thấy trong bài kiểm tra đơn vị / tích hợp có chi phí thấp hơn nhiều lần so với sửa lỗi một lần trên hệ thống trực tiếp (chúng dựa trên việc giám sát hàng ngàn dự án thực tế).

Chỉnh sửa : ví dụ, như đã chỉ ra, cuốn sách " Hoàn thành mã " báo cáo về các nghiên cứu đó (đoạn 20.3, "Hiệu quả tương đối của các kỹ thuật chất lượng"). Nhưng cũng có nghiên cứu tư nhân trong lĩnh vực tư vấn cũng chứng minh điều đó.

Tôi có một bộ điểm dữ liệu cho việc này - từ một kinh nghiệm đã bán cho tôi trong các bài kiểm tra đơn vị.

Nhiều mặt trăng trước đây tôi là một sinh viên mới tốt nghiệp làm việc trong một dự án VB6 lớn và có dịp viết một khối lớn mã thủ tục được lưu trữ. Trong hệ thống con tôi đã viết, nó chiếm khoảng 1/4 toàn bộ cơ sở mã - khoảng 13.000 LỘC trong số 50 nghìn hoặc hơn.

Tôi đã viết một tập các thử nghiệm đơn vị cho các thủ tục được lưu trữ nhưng thử nghiệm đơn vị mã UI VB6 không thực sự khả thi nếu không có các công cụ như Rational Robot; ít nhất nó đã không trở lại sau đó.

Số liệu thống kê từ QA trên tác phẩm là khoảng 40 hoặc 50 lỗi được nêu ra trên toàn bộ hệ thống con, trong đó hai lỗi bắt nguồn từ các thủ tục được lưu trữ. Đó là một khiếm khuyết trên 6.500 dòng mã so với 1 trên 1.000-1.200 hoặc hơn trên toàn bộ. Cũng nên nhớ rằng, khoảng 2/3 mã VB6 là mã soạn sẵn để xử lý lỗi và ghi nhật ký, giống hệt nhau trong tất cả các quy trình.

Nếu không có quá nhiều thao tác tay, bạn có thể quy định ít nhất là một sự cải thiện về mức độ nghiêm trọng đối với các thử nghiệm đơn vị.