Có bất kỳ số liệu thống kê có sẵn để mất bao lâu để phát triển các ứng dụng khi tạo thử nghiệm đơn vị trong quá trình phát triển so với chỉ mã hóa?
Có một số nghiên cứu rất thú vị về điều này. Đọc whitepaper sau:
Hiện thực hóa cải tiến chất lượng thông qua phát triển theo hướng thử nghiệm: kết quả và kinh nghiệm của bốn nhóm công nghiệp
Whitepaper và những người khác nghiên cứu từ một trong những tác giả của nó, Nachi Nagappan , sẽ được thảo luận ở đây:
http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx
Nghiên cứu và kết quả của nó đã được công bố trong một bài báo có tên Thực hiện cải tiến chất lượng thông qua phát triển dựa trên thử nghiệm: kết quả và kinh nghiệm của bốn nhóm công nghiệp, bởi Nagappan và các đồng nghiệp nghiên cứu E. Michael Maximilien thuộc Trung tâm nghiên cứu IBM Almaden; Thirumalesh Bhat, trưởng nhóm phát triển phần mềm chính tại Microsoft; và Laurie Williams của Đại học bang Bắc Carolina. Điều mà nhóm nghiên cứu tìm thấy là các nhóm TDD đã tạo ra mã tốt hơn 60 đến 90% về mật độ khiếm khuyết so với các nhóm không TDD. Họ cũng phát hiện ra rằng các đội TDD mất nhiều thời gian hơn để hoàn thành các dự án của họ, lâu hơn 15 đến 35%.
Càng vượt qua chu kỳ phát triển 12 tháng, 35% là bốn tháng nữa, rất lớn, ông Nag Nagan nói. Tuy nhiên, sự đánh đổi là bạn giảm đáng kể chi phí bảo trì sau phát hành, vì chất lượng mã tốt hơn rất nhiều. Một lần nữa, đây là những quyết định mà các nhà quản lý phải đưa ra, họ nên đánh ở đâu? Nhưng bây giờ, họ thực sự có dữ liệu định lượng để đưa ra những quyết định đó.
Ngoài ra, Jason Gorman đã đề xuất một thử nghiệm như vậy cho hội nghị Thủ công phần mềm năm nay. Anh ấy đã thử một thí nghiệm tạo ra cùng một ứng dụng bằng cách sử dụng TDD và cách tiếp cận không TDD và gần đây anh ấy đã viết về kết quả của mình :
Trải qua 3 lần lặp, thời gian trung bình để hoàn thành kata mà không cần TDD là 28m 40s. Thời gian trung bình với TDD là 25m 27s. Không có TDD, trung bình tôi đã thực hiện 5,7 lượt (đưa vào thử nghiệm chấp nhận). Với TDD, trung bình tôi thực hiện 1,3 đường chuyền (trong hai lần thử, chúng đã vượt qua lần đầu tiên, trong một lần phải mất 2 đường chuyền.)
Bây giờ, đây là một thí nghiệm trẻ em, tất nhiên. Và không chính xác điều kiện phòng thí nghiệm. Nhưng tôi lưu ý một vài điều thú vị, tất cả đều giống nhau.
Sẽ rất thú vị khi xem kết quả đầy đủ của thí nghiệm này khi có nhiều người thực hiện nó.
Có bất kỳ số liệu thống kê nào cho thấy việc bảo trì giảm bao nhiêu giờ khi có các bài kiểm tra đơn vị (tốt) không?
Từ whitepaper ở trên:
Kết quả của các nghiên cứu trường hợp chỉ ra rằng mật độ khiếm khuyết trước khi phát hành của bốn sản phẩm giảm từ 40% đến 90% so với các dự án tương tự không sử dụng thực hành TDD.