Chi phí thực sự của TDD là gì khi toàn bộ đội đã quen với nó?

Bao nhiêu phần trăm thời gian được tiết kiệm và chi phí làm TDD.

Tôi giả định tỷ lệ phần trăm thay đổi chi phí và phần thưởng này trong vòng đời dự án.

Tôi tưởng tượng giai đoạn đầu có chi phí cao hơn rất nhiều nhưng phần thưởng nhỏ kèm theo. Hơn nữa (trong quá trình bao thanh toán lại ) bạn sẽ nhận được lợi ích từ các bài kiểm tra của mình.

Tôi đã nghe thấy bất cứ nơi nào từ 30-50% thời gian của bạn là viết bài kiểm tra đơn vị. Tuy nhiên, điều đó không tính đến thời gian tiết kiệm từ việc viết các bài kiểm tra đó.

Kinh nghiệm của mọi người với điều này là gì?

Wes

EDIT Thời gian tiết kiệm cũng như chi phí thời gian là gì? Trong sửa lỗi và tái cấu trúc?

Tôi đã nghe thấy từ 30-50% thời gian của bạn là viết bài kiểm tra đơn vị. Tuy nhiên, điều đó không tính đến thời gian tiết kiệm

Theo kinh nghiệm của tôi, nó hơn 50%.

Khi bạn đã viết bài kiểm tra, giải pháp có xu hướng rất dễ dàng. Vì vậy, tôi nghĩ thật kỳ quặc khi dành 70% - 75% thời gian để viết bài kiểm tra, nhưng bạn sẽ dành ít thời gian hơn để viết 'mã sản xuất' (đang được kiểm tra mã) và hầu như không mất thời gian cho trình gỡ lỗi .

Bạn càng sớm tìm thấy một lỗi, thì nó càng rẻ để sửa chữa và TDD giúp điều đó rất nhiều. Tôi đã làm việc trong các dự án trong đó 2 tháng qua (của một dự án 8 tháng) đã dành để sửa lỗi và giai đoạn đó sẽ gần như được loại bỏ hoàn toàn với TDD.

Đối với tôi, giá trị thực sự là trong bảo trì. Kế thừa một cơ sở mã với các bài kiểm tra làm cho bạn bớt sợ hãi để thay đổi nó. Bạn cảm thấy như bạn đã không phá vỡ bất cứ điều gì khi các bài kiểm tra vẫn vượt qua. Vì bạn không sợ thực hiện các thay đổi, bạn sẵn sàng tái cấu trúc nếu có gì đó không đúng. Điều đó có nghĩa là mã có thể được làm sạch hơn, thiết kế có thể phù hợp hơn và theo lý thuyết, các thay đổi có thể được áp dụng. Ngược lại với mã voodoo mọi người đều sợ chạm vào.

Mỗi lần bạn chạy thử nghiệm đơn vị, bạn sẽ tiết kiệm cho mình lượng thời gian cần thiết để kiểm tra mã theo cách thủ công.

30% đến 50% thời gian bạn trích dẫn khi được yêu cầu viết bài kiểm tra của bạn cũng được bù đắp rất nhiều bởi những lợi ích của việc có một thiết kế phần mềm (có thể kiểm tra) tốt hơn.

Giả sử phải mất bốn lần thời gian để viết một bài kiểm tra tự động cũng như để thực hiện kiểm tra theo cách thủ công. Điều đó có nghĩa là lần thứ tư bạn chạy thử nghiệm tự động, nó sẽ tự trả tiền. Mỗi lần bạn chạy thử nghiệm tự động sau đó, nó đều miễn phí.

Điều này đúng cho dù thử nghiệm là thử nghiệm đơn vị tự động hay thử nghiệm chức năng tự động. Không phải tất cả các bài kiểm tra chức năng có thể được tự động, nhưng nhiều trong số chúng có thể. Thêm vào đó, bài kiểm tra tự động đáng tin cậy hơn một người; nó sẽ chạy thử nghiệm theo cùng một cách , mọi lúc.

Có các bài kiểm tra đơn vị có nghĩa là bạn có thể cấu trúc lại việc triển khai cơ bản của một phương thức (vì hiệu suất hoặc các lý do khác) và các bài kiểm tra đơn vị sẽ xác minh rằng chức năng của phương thức không thay đổi. Điều này đặc biệt đúng với TDD, trong đó bài kiểm tra đơn vị chỉ định chức năng của phương thức.

TDD thường được đo theo chất lượng mã hơn là thời gian và chi phí bỏ ra. Tuy nhiên, với chất lượng mã tốt hơn, các nhà phát triển và bất kỳ người nào làm việc với họ có thể làm việc tốt hơn (tốn ít thời gian hơn, ít chi phí hơn, hạnh phúc hơn, v.v.). http://davidlongstreet.wordpress.com/2009/04/29/new-software-metric-wtfs-per-minute/

Viết bài kiểm tra là rất tốt để giúp tự động xác minh các yêu cầu chức năng và phi chức năng. Một video đã thuyết phục tôi chấp nhận TDD (thực ra là BDD, TDD cấp cao): http://video.google.com/videoplay?docid=8135690990081075324#

• Viết các bài kiểm tra chức năng có thể giúp phát hiện ra các lỗi / vấn đề sớm hơn trong giai đoạn phát triển . Giả sử bạn có cơ sở mã lớn. Với các bài kiểm tra / thông số kỹ thuật đơn vị , bạn chỉ cần xem "Tất cả các bài kiểm tra đã vượt qua" / "2 bài kiểm tra không thành công, xem dòng xyz". Bạn chỉ cần một nhóm các nhà phát triển để thực hiện cả phát triển và thử nghiệm. Nếu không có kiểm tra đơn vị / thông số kỹ thuật , bạn phải so sánh thủ công các câu lệnh in với các câu lệnh dự kiến ​​và theo dõi thủ công phương thức / lớp nào có lỗi. Bạn có thể cần hai nhóm riêng biệt (nhà phát triển và người thử nghiệm) để làm điều này.

• Các bài kiểm tra viết giúp các nhà phát triển giải thích tiến trình và các vấn đề phải đối mặt.

• TDD giúp hoàn thành khả năng bảo trì, khả năng thích ứng và tính linh hoạt của mã. Nó khuyến khích các nhà phát triển viết các đoạn nhỏ có thể kiểm tra được và ghép chúng lại thành các khối có thể kiểm tra lớn hơn. Cách khác, vòng (một phần của thực hành tái cấu trúc) cũng hoạt động, với điều kiện chúng tôi đã viết các bài kiểm tra vững chắc. Kết quả là, chúng ta có thể có mã mô-đun được viết độc đáo.

Với TDD, chúng tôi rất vui khi biết:

• một khách hàng yêu cầu thay đổi theo yêu cầu (đáp ứng yêu cầu)
• cách tốt hơn để viết mã được phát hiện
• đồng đội có đề xuất cải tiến mã
• chúng tôi phải giải thích / chuyển mã của mình cho người khác

TDD có thể nhàm chán vì quá trình phát triển thực hiện các bước nhỏ, và do đó nó trở nên rất dễ đoán.

Trong trường hợp của chúng tôi, tôi ước tính nó gần 40%. Tuy nhiên, tôi không nghĩ rằng chúng tôi đã trải qua một giai đoạn mà nó còn hơn thế nữa. Chúng tôi có một trình tạo mã giúp tạo ra cả bộ xương mã được các nhà phát triển xác định và một bộ thử nghiệm cũng được bổ sung. Hầu hết các nỗ lực thử nghiệm của chúng tôi thực sự đi vào việc theo dõi (hoặc tạo) dữ liệu thử nghiệm phù hợp để đảm bảo rằng chúng tôi có được phạm vi bảo hiểm đầy đủ.

Các biện pháp dài hạn quan trọng không chỉ là chất lượng mã và độ tin cậy của mã, mà ngay cả moreso cũng không đốt cháy đội ngũ đang thực hiện thử nghiệm không suy nghĩ

các biện pháp ngắn hạn sẽ là ROI của việc tự động hóa các bài kiểm tra

ví dụ: tuần trước tôi đã thực hiện hơn 1000 thay đổi mã do thay đổi kiến ​​trúc nội bộ, bắt đầu bộ kiểm tra tự động và đi ngủ.

các bài kiểm tra mất 28 phút để chạy; tất cả họ đã vượt qua. thực hiện thủ công cùng hơn 40 bài kiểm tra chấp nhận sẽ mất khoảng 6 giờ.

một ví dụ khác: trong lần lặp lại trước, tôi đã đưa ra một trong các kịch bản thử nghiệm với một lỗi tinh vi mà thử nghiệm thủ công có thể không tìm thấy (các thử nghiệm tự động thực hiện kiểm tra tính toàn vẹn db mà người kiểm tra thủ công hầu như không bao giờ làm). tôi đã phải chạy kịch bản thử nghiệm đó khoảng 50 lần trước khi tôi tìm ra và sửa nó. thực hiện thủ công các hoạt động kịch bản thử nghiệm sẽ mất khoảng 50 phút. Vì vậy, đó là 41,6 giờ lao động được tiết kiệm trong một ngày

không có cách tính trước ROI của kiểm tra tự động, bởi vì bạn không thể biết chính xác mình sẽ cần bao nhiêu lần để chạy thử nghiệm.

nhưng với tôi, ROI của các bài kiểm tra tự động gần như vô hạn

Nó có thể giúp rất nhiều để hạn chế các bài kiểm tra đơn vị đối với các thuật toán phức tạp, trường hợp chúng có thể được tạo tự động và hồi quy.

Kiểm thử thành phần thường làm một công việc tuyệt vời cho mã khá tầm thường, cộng với việc thay đổi triển khai rẻ hơn rất nhiều vì các kiểm tra chỉ được kết hợp với giao diện.

Bảo hiểm đầy đủ với các bài kiểm tra đơn vị hạt mịn có một chi phí rất lớn để thay đổi hoặc tái cấu trúc một triển khai, đó chính xác là những gì họ tuyên bố là dễ dàng.