Thử nghiệm phát triển theo định hướng (TDD) có thực sự mang lại lợi ích cho một dự án thế giới thực không?

Tôi không mới để viết mã. Tôi đã viết mã (nghiêm túc) trong hơn 15 năm nay. Tôi đã luôn luôn có một số thử nghiệm cho mã của tôi. Tuy nhiên, trong vài tháng qua tôi đã học thử nghiệm thiết kế / phát triển (TDD) dựa trên thử nghiệm bằng cách sử dụng Ruby on Rails . Cho đến nay, tôi không thấy lợi ích.

Tôi thấy một số lợi ích để viết bài kiểm tra cho một số điều, nhưng rất ít. Và trong khi tôi thích ý tưởng viết bài kiểm tra trước tiên, tôi thấy tôi đã dành nhiều thời gian hơn để cố gắng gỡ lỗi bài kiểm tra của mình để khiến họ nói điều tôi thực sự có ý nghĩa hơn là tôi gỡ lỗi mã thực tế. Điều này có thể là do mã kiểm tra thường phức tạp hơn nhiều so với mã mà nó kiểm tra. Tôi hy vọng đây chỉ là thiếu kinh nghiệm với các công cụ có sẵn ( RSpec trong trường hợp này).

Tôi phải nói rằng, tại thời điểm này, mức độ thất vọng xen lẫn với sự thiếu hiệu suất đáng thất vọng là không thể chấp nhận được. Cho đến nay, giá trị duy nhất tôi thấy từ TDD là một thư viện các tệp RSpec đang phát triển làm mẫu cho các dự án / tệp khác. Điều này không hữu ích hơn nhiều, có thể ít hữu ích hơn so với các tệp mã dự án thực tế.

Khi đọc các tài liệu có sẵn, tôi nhận thấy rằng TDD dường như là một thời gian lớn chìm lên phía trước, nhưng cuối cùng cũng được đền đáp. Tôi chỉ tự hỏi, có bất kỳ ví dụ thực tế? Liệu sự thất vọng to lớn này có bao giờ được đền đáp trong thế giới thực?

Tôi thực sự hy vọng tôi đã không bỏ lỡ câu hỏi này ở một nơi khác ở đây. Tôi đã tìm kiếm, nhưng tất cả các câu hỏi / câu trả lời đã được vài năm tuổi. Đó là một dịp hiếm hoi khi tôi tìm thấy một nhà phát triển sẽ nói bất cứ điều gì tồi tệ về TDD, đó là lý do tại sao tôi đã dành nhiều thời gian cho việc này như tôi có. Tuy nhiên, tôi nhận thấy rằng dường như không ai chỉ ra các ví dụ cụ thể trong thế giới thực. Tôi đã đọc một câu trả lời rằng anh chàng gỡ lỗi mã vào năm 2011 sẽ cảm ơn bạn vì đã có một bộ kiểm thử đơn vị hoàn chỉnh (tôi nghĩ rằng nhận xét đó được thực hiện vào năm 2008).

Vì vậy, tôi chỉ tự hỏi, sau ngần ấy năm, cuối cùng chúng ta có ví dụ nào cho thấy mức chi trả là có thật không? Có ai thực sự được thừa kế hoặc quay trở lại mã được thiết kế / phát triển với TDD và có một bộ kiểm tra đơn vị hoàn chỉnh và thực sự cảm thấy có một khoản tiền không? Hoặc bạn có thấy rằng bạn đã dành quá nhiều thời gian để cố gắng tìm ra bài kiểm tra nào đang thử nghiệm (và tại sao nó quan trọng) đến mức bạn chỉ cần vứt bỏ toàn bộ mớ hỗn độn và đào sâu vào mã?

Bài viết này chứng minh rằng TDD tăng thêm 15 - 35% thời gian phát triển để đổi lại việc giảm 40-90% mật độ khiếm khuyết đối với các dự án tương tự.

Bài báo đề cập đầy đủ giấy (pdf) - Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, và Laurie Williams. Nâng cao chất lượng thực hiện 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 đội công nghiệp. ESE 2008 .

_{trừu tượngPhát triển dựa trên kiểm thử (TDD) là một thực tiễn phát triển phần mềm đã được sử dụng một cách rời rạc trong nhiều thập kỷ. Với thực tiễn này, một kỹ sư phần mềm xoay vòng từng phút giữa việc viết các bài kiểm tra đơn vị thất bại và viết mã thực thi để vượt qua các bài kiểm tra đó. Sự phát triển của Testdriven gần đây đã xuất hiện trở lại như là một thực tiễn quan trọng cho phép các phương pháp phát triển phần mềm linh hoạt. Tuy nhiên, rất ít bằng chứng thực nghiệm hỗ trợ hoặc bác bỏ tiện ích của thực tiễn này trong bối cảnh công nghiệp. Nghiên cứu trường hợp được thực hiện với ba nhóm phát triển tại Microsoft và một tại IBM đã áp dụng TDD. 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. Chủ quan,}

_{Bài báo đầy đủ cũng tóm tắt ngắn gọn các nghiên cứu thực nghiệm có liên quan về TDD và kết quả cấp cao của họ (phần 3 Công việc liên quan ), bao gồm George và Williams 2003, Müller và Hagner (2002), Erdogmus et al. (2005), Müller và Tichy (2001), Janzen và Seiedian (2006).}

Tôi thấy một số lợi ích để viết bài kiểm tra cho một số điều, nhưng rất ít. Và trong khi tôi thích ý tưởng viết bài kiểm tra trước tiên, tôi thấy tôi đã dành nhiều thời gian hơn để cố gắng gỡ lỗi bài kiểm tra của mình để khiến họ nói điều tôi thực sự có ý nghĩa hơn là tôi gỡ lỗi mã thực tế.

Tôi đã làm việc TDD trong ba năm qua và kinh nghiệm của tôi hoàn toàn ngược lại. Tôi dành ít thời gian hơn để viết các bài kiểm tra đơn vị mà tôi sẽ gỡ lỗi mã, nếu tôi không viết các bài kiểm tra đơn vị.

Tôi không chỉ làm TDD, tôi còn làm việc bên ngoài, tức là lần đầu tiên tôi triển khai TDD lớp trên cùng / gui. Việc triển khai lớp trên cùng xác định các yêu cầu cho lớp tiếp theo trong hệ thống mà tôi phát triển bằng TDD, v.v. cho đến khi tất cả các mã cần thiết cho tính năng đã được triển khai. Thông thường, tôi trải nghiệm rằng sau khi tôi đã triển khai một tính năng như thế này và tôi hút thử nghiệm tính năng này trong hệ thống thực tế, nó hoạt động lần đầu tiên. Không phải tất cả thời gian, nhưng thường xuyên.

Và do mất nhiều thời gian hơn để hút thử nghiệm một tính năng trong hệ thống thực tế so với việc thực hiện một vài thử nghiệm đơn vị, tôi tiết kiệm được rất nhiều thời gian. Nó thực sự nhanh hơn đối với tôi khi thực hiện một tính năng bằng TDD so với việc không thực hiện tính năng không viết bài kiểm tra đơn vị nào cả.

Nhưng viết bài kiểm tra đơn vị là một kỹ năng phải được học và thành thạo, giống như bất kỳ kỹ năng lập trình nào khác. Khi tôi bắt đầu làm TDD, tôi đã có 12 năm kinh nghiệm chuyên môn về lập trình và tôi là một lập trình viên rất thành đạt. Tôi nghĩ rằng việc viết các bộ thử nghiệm lớn cho mã hệ thống sẽ là một điều đơn giản. Nhưng khi số lượng mã kiểm tra tăng lên, và các phần khác nhau của hệ thống đã thay đổi và các kiểm tra hiện tại phải được sửa đổi, tôi đã học được rằng kiểm tra đơn vị cấu trúc và viết là một kỹ năng cần phải học và thành thạo. Ngoài ra không phải tất cả các mã đều có thể kiểm tra như nhau. Mã hệ thống phải được ghép rất lỏng lẻo để có thể kiểm tra một cách hiệu quả. Thực tế việc học TDD đã giúp tôi làm cho mã hệ thống được ghép lỏng lẻo hơn.

Nhưng hiệu quả hiện tại của tôi khi làm việc TDD đến từ sự kết hợp của cả việc thành thạo cách viết bài kiểm tra đơn vị, mà còn làm chủ công nghệ mà hệ thống được triển khai trong (C # trong trường hợp này).

Làm TDD trong khi học một công nghệ mới có thể khó khăn, ví dụ mặc dù tôi đã làm một chút về lập trình iPhone, tôi không viết một số lượng đáng kể các bài kiểm tra đơn vị, vì tôi không thành thạo ngôn ngữ, mục tiêu c, tôi cũng không thành thạo thư viện. Vì vậy, tôi không biết làm thế nào để cấu trúc các bài kiểm tra đơn vị của mình, thậm chí còn ít hơn cách cấu trúc mã hệ thống làm thế nào để làm cho nó có thể kiểm tra được.

Nhưng làm thế nào nó hoạt động tốt trên các dự án thực tế?

Trong dự án tôi đã thực hiện trong vài năm qua, mặc dù có một yêu cầu là mã phải được bao phủ đầy đủ bởi các bài kiểm tra đơn vị, tôi là người duy nhất trong nhóm viết bài kiểm tra đầu tiên. Nhưng bộ thử nghiệm lớn giúp tôi tự tin có thể cấu trúc lại hệ thống và tin rằng hệ thống sẽ hoạt động chính xác nếu bộ thử nghiệm vượt qua.

Nhưng thật không may vì nhiều bài kiểm tra được viết sau mã hệ thống, khá nhiều bài kiểm tra bị lỗi, tức là chúng không thực sự kiểm tra những gì chúng dự định kiểm tra. Imho này không thể tránh được. Mỗi khi bạn viết một đoạn mã, có một xác suất mã không hoạt động như bạn dự định, tức là có lỗi. Tương tự với mã kiểm tra. Do đó, có khả năng bạn viết một bài kiểm tra vượt qua mặc dù mã mà nó nên kiểm tra không hoạt động như dự định.

Viết bài kiểm tra trước, xác minh không chỉ là bạn bị lỗi kiểm tra mà bài kiểm tra thất bại với chính xác thông báo lỗi bạn mong đợi trước khi triển khai mã hệ thống làm giảm nghiêm trọng nguy cơ lỗi trong mã kiểm tra đơn vị.

Vì vậy, để tóm tắt, theo kinh nghiệm của tôi một khi bạn đã thành thạo nghệ thuật TDD, bạn sẽ không chỉ tiết kiệm thời gian trong thời gian dài, bạn sẽ tiết kiệm thời gian trước. Nhưng phải mất thời gian, ngay cả đối với một lập trình viên có kinh nghiệm, để làm chủ nghệ thuật TDD. Và phải mất nhiều thời gian hơn nữa để một nhóm các nhà phát triển kỹ năng khác nhau có thể làm chủ nghệ thuật TDD.

Chúng tôi đã được hưởng lợi ồ ạt.

Chúng tôi là Người bán cấp 1, có nghĩa là chúng tôi xử lý hơn sáu triệu giao dịch thanh toán mỗi năm.

Hệ thống cổng thanh toán của chúng tôi có hàng ngàn bài kiểm tra đơn vị và tích hợp. Các xét nghiệm này cho chúng tôi niềm tin vào khả năng xử lý thanh toán của mình. Bạn muốn tự tin rằng phanh xe của bạn hoạt động, phải không? Chúng tôi muốn tự tin rằng chúng tôi sẽ không mất việc kinh doanh vì chúng tôi không thể xử lý các khoản thanh toán.

Mã bảo hiểm cung cấp cho bạn sự tự tin đó. Tất nhiên là không đủ, nhưng đó là một khởi đầu rất tốt.

Hầu hết hệ thống cổng thanh toán của chúng tôi được viết bằng TDD. Một số khía cạnh khá khó kiểm tra, vì vậy chúng tôi đã quyết định cắt giảm các góc bằng cách hy sinh một số bảo hiểm mã. Chúng tôi sẽ lấy lại và giải quyết những vấn đề này cuối cùng.

Cá nhân, tôi thấy khó khăn để viết bất kỳ logic trước khi viết bài kiểm tra. Phải nói rằng, tôi phải mất một chút thời gian để bắt đầu suy nghĩ theo cách TDD.

Tham khảo Visa PCI: http://usa.visa.com/merchants/risk_manloyment/cisp_merchants.html

Mặc dù các bài kiểm tra thường có thể được coi là một cách làm quá nhiều bởi một số người, tôi nghĩ rằng nó thực sự đáng để gặp rắc rối trong một số trường hợp nhất định.

Tôi đã phát triển Killer Sudoku Solver cho trường học khoảng 3 tháng, nó sử dụng nhiều "chiến lược" để loại bỏ các khả năng và giải pháp. Thực tế là, một lỗi trong một khả năng có thể gây tử vong và dẫn đến một vấn đề cần giải quyết sudoku bởi vì khi một số khả năng bị loại bỏ, bạn không thử nó nữa và nếu đó là giải pháp, chương trình không thể giải quyết Lưới nữa.

Nhưng thực sự rất khó để kiểm tra thủ công, ý tôi là phải có lưới, tôi có thể thấy các tầng nào đang làm gì trong một ví dụ trong thế giới thực, nhưng tôi chỉ không thể kiểm tra mỗi lần áp dụng chiến lược vì điều này thể hiện quá nhiều dữ liệu.

Và các chiến lược được áp dụng trên một lưới nhất định khá "ngẫu nhiên", điều đó có nghĩa là bạn sẽ không sử dụng tất cả trên một lưới cụ thể.

Vì vậy, tôi đã viết các bài kiểm tra trên từng chiến lược, kiểm tra kết quả trên mỗi ô, chỉ sử dụng các tình huống đơn giản (ví dụ chỉ hai ô đã loại bỏ các khả năng) và nó đã giúp tôi tiết kiệm hàng giờ mỗi ngày khi tôi không may có một lưới không thể giải quyết được. Bởi vì tôi đã biết vấn đề ở đâu rồi.

Ưu điểm của TDD là bạn tìm ra cách gọi mã trước khi viết mã thực tế.

Nói cách khác, TDD giúp thiết kế API của bạn.

Theo kinh nghiệm của tôi, kết quả này trong API tốt hơn, từ đó cung cấp mã tốt hơn.

EDIT: Như tôi đã viết, đây là "theo kinh nghiệm của tôi", tức là khi viết "các dự án trong thế giới thực" nhưng thật không may, đây là với một cơ sở mã nguồn đóng, tôi không thể để thế giới nhìn thấy. Tôi có thể hiểu từ các ý kiến ​​rằng đây là những gì thực sự được yêu cầu, và không chỉ là một xác nhận về sự tồn tại đơn thuần của các dự án như vậy.

Tôi cũng đã tìm thấy - một lần nữa theo kinh nghiệm cá nhân của tôi - rằng lợi ích thực sự cho thấy khi bạn vào chế độ bảo trì vì các yêu cầu có xu hướng thay đổi. API sạch của làm cho nó dễ dàng hơn để bày tỏ những yêu cầu mới hoặc thay đổi trong mã kiểm tra, và tất cả các bài kiểm tra làm cho nó rất dễ dàng để xem cho một nhà bảo trì trong tương lai như thế nào đang được kêu gọi và những gì có thể được dự kiến sẽ trở lại.

Các trường hợp thử nghiệm đang chạy các phiên bản của đặc tả và cho phép bạn thấy rất, rất dễ dàng cách gọi API của bạn. Đây có lẽ là hình thức phân tích "CÁCH" hữu ích nhất mà tôi từng thấy từ trước đến nay (so sánh với tài liệu "TẠI SAO" như JavaDoc) vì bạn chắc chắn rằng nó là chính xác (nếu không thì thử nghiệm sẽ thất bại).

Gần đây, tôi đã phải duy trì một máy khách ftp có thể tạo tập lệnh với một tập hợp các tùy chọn rất lớn, tất cả đều ảnh hưởng đến cách ứng dụng hoạt động. TDD đã được giới thiệu gần đây cho chức năng mới và bộ thử nghiệm lớn cho phép chúng tôi thực hiện các hotfix trong khi tự tin rằng chức năng được sử dụng vẫn hoạt động như mong đợi. Nói cách khác, quá trình chuyển đổi này đã được chứng minh là rất nhanh chóng.

Cách tiếp cận cụ thể để kiểm tra có giá trị như thế nào phụ thuộc vào mức độ quan trọng của hệ thống đang được phát triển và mức độ một số hệ thống quan trọng khác phụ thuộc vào nó. Một tập lệnh lưu bút đơn giản cho trang web của bạn khó có thể được coi là nhiệm vụ quan trọng, nhưng nếu trang web chạy trên đó có khả năng bị xâm phạm bởi một lỗi cho phép nhập vào cơ sở dữ liệu và trang web đó cung cấp một số dịch vụ quan trọng, thì nó đột nhiên trở nên nhiều hơn quan trọng đối với kịch bản lưu bút được kiểm tra kỹ lưỡng. Điều tương tự cũng đúng với mã khung / thư viện. Nếu bạn phát triển một khung có lỗi, thì mọi ứng dụng sử dụng tính năng khung đó cũng có lỗi tương tự.

Phát triển theo hướng kiểm tra cung cấp cho bạn thêm một lớp an toàn khi nói đến các bài kiểm tra. Nếu bạn viết các bài kiểm tra bên cạnh hoặc thậm chí sau mã bạn muốn kiểm tra, thì có nguy cơ thực sự là bạn làm bài kiểm tra sai. Nếu bạn viết tất cả các bài kiểm tra trước, thì cách mã hoạt động bên trong không thể ảnh hưởng đến những gì bạn viết bài kiểm tra, và do đó, ít có khả năng bạn vô tình viết các bài kiểm tra nghĩ rằng một đầu ra sai cụ thể là chính xác.

Phát triển theo hướng kiểm tra cũng khuyến khích các nhà phát triển của bạn viết mã dễ kiểm tra, vì họ không muốn tự mình làm nhiều việc hơn nữa! Mã dễ kiểm tra có xu hướng là mã dễ hiểu, tái sử dụng và bảo trì.

Và bảo trì là nơi bạn sẽ thực sự gặt hái những phần thưởng của TDD. Phần lớn các nỗ lực lập trình dành cho phần mềm là liên quan đến bảo trì. Điều này có nghĩa là thực hiện các thay đổi đối với mã trực tiếp để cung cấp cho nó các tính năng mới, sửa lỗi hoặc điều chỉnh nó theo các tình huống mới. Khi thực hiện các thay đổi như vậy, bạn muốn chắc chắn rằng những thay đổi bạn thực hiện có hiệu quả mong muốn và quan trọng hơn, chúng không có hiệu ứng bất ngờ. Nếu bạn có một bộ kiểm tra đầy đủ cho mã của mình, thì thật dễ dàng để xác minh rằng bất kỳ thay đổi nào bạn thực hiện không phá vỡ thứ gì khác và nếu những thay đổi bạn thực hiện sẽ phá vỡ thứ khác thì bạn có thể nhanh chóng tìm ra lý do tại sao. Những lợi ích là lâu dài.

Bạn đã nói như sau trong câu hỏi của bạn:

Tôi thấy một số lợi ích để viết bài kiểm tra cho một số điều, nhưng rất ít. Và trong khi tôi thích ý tưởng viết bài kiểm tra trước tiên, tôi thấy tôi đã dành nhiều thời gian hơn để cố gắng gỡ lỗi bài kiểm tra của mình để khiến họ nói điều tôi thực sự có ý nghĩa hơn là tôi gỡ lỗi mã thực tế. Điều này có thể là do mã kiểm tra thường phức tạp hơn nhiều so với mã mà nó kiểm tra. Tôi hy vọng đây chỉ là thiếu kinh nghiệm với các công cụ có sẵn (rspec trong trường hợp này).

Điều này dường như gợi ý cho tôi rằng bạn không hoàn toàn kiểm tra. Một bài kiểm tra đơn vị được cho là cực kỳ đơn giản, chỉ là một chuỗi các cuộc gọi phương thức, theo sau là một xác nhận để so sánh kết quả mong đợi với kết quả thực tế. Chúng có nghĩa là đơn giản vì các lỗi trong bài kiểm tra của bạn sẽ là thảm họa và nếu bạn đưa ra các vòng lặp, phân nhánh hoặc kiểm soát ném chương trình khác vào kiểm tra thì nhiều khả năng bài kiểm tra sẽ có lỗi được đưa vào. Nếu bạn đang dành nhiều thời gian để gỡ lỗi các bài kiểm tra thì điều đó cho thấy các bài kiểm tra của bạn quá phức tạp và bạn nên đơn giản hóa chúng.

Nếu các bài kiểm tra không thể được đơn giản hóa, thì thực tế đó cho thấy rằng có điều gì đó không đúng với mã đang được kiểm tra. Ví dụ: nếu lớp của bạn có các phương thức dài, các phương thức có nhiều câu lệnh if / otherif / other hoặc chuyển đổi hoặc một số lượng lớn các phương thức có tương tác phức tạp được quy định bởi trạng thái hiện tại của lớp thì các bài kiểm tra sẽ phải cực kỳ phức tạp để cung cấp bảo hiểm mã đầy đủ và kiểm tra tất cả các tình huống. Nếu lớp của bạn có các phụ thuộc được mã hóa cứng vào các lớp khác thì điều này một lần nữa sẽ làm tăng số lượng vòng bạn sẽ phải nhảy để kiểm tra mã của bạn một cách hiệu quả.

Nếu bạn giữ cho các lớp học của bạn nhỏ và tập trung cao độ, với các phương thức ngắn với một vài đường dẫn thực hiện và cố gắng loại bỏ trạng thái bên trong thì các bài kiểm tra có thể được đơn giản hóa. Và đây là loại mấu chốt của vấn đề. Mã tốt vốn đã dễ dàng để kiểm tra. Nếu mã không dễ kiểm tra thì có lẽ có gì đó không ổn với nó.

Viết bài kiểm tra đơn vị là một cái gì đó có lợi cho bạn về lâu dài, và tránh chúng chỉ đơn giản là lưu trữ rắc rối cho sau này. Bạn có thể không quen thuộc với khái niệm nợ kỹ thuật, nhưng nó hoạt động rất nhiều như nợ tài chính. Không viết bài kiểm tra, không bình luận mã, viết trong các phụ thuộc được mã hóa cứng và vì vậy là những cách để đi vào nợ nần. Bạn "mượn" thời gian bằng cách cắt giảm sớm và điều này có thể giúp bạn đạt được thời hạn chặt chẽ, nhưng thời gian bạn tiết kiệm sớm hơn trong dự án là cho vay. Mỗi ngày trôi qua mà không làm sạch mã, nhận xét đúng hoặc xây dựng bộ kiểm tra sẽ khiến bạn phải trả lãi. Càng kéo dài, tiền lãi tích lũy càng nhiều. Cuối cùng, bạn sẽ phát hiện ra mã của mình đã trở thành một mớ hỗn độn mà bạn không thể thay đổi mà không gây ra hậu quả ngoài ý muốn.

Bạn có thể nghĩ về việc viết bài kiểm tra đơn vị sớm và cập nhật chúng như một hình thức "tín dụng kỹ thuật". Bạn đang dành thời gian cho ngân hàng bằng cách dành thời gian sớm cho dự án theo thông lệ tốt. Bạn sẽ kiếm được tiền lãi từ tầm nhìn xa này sau này khi bạn đến giai đoạn bảo trì của dự án. Khi bạn muốn thực hiện thay đổi, bạn có thể dễ dàng xác nhận tính chính xác của thay đổi và nó không có bất kỳ tác dụng phụ không mong muốn nào và bạn có thể nhận được các bản cập nhật nhanh chóng và không phiền phức. Nếu lỗi xuất hiện, bạn có thể thêm một bài kiểm tra đơn vị mới thực hiện lỗi, sau đó sửa lỗi trong mã. Khi bạn chạy thử nghiệm tiếp theo, bạn sẽ có thể xác minh rằng lỗi đã được sửa và nó không gây ra bất kỳ vấn đề nào khác. Hơn nữa, bạn sẽ tránh được "hồi quy",

TL: DR - Vâng, họ là một trợ giúp trong thế giới thực, nhưng họ là một khoản đầu tư. Những lợi ích chỉ trở nên rõ ràng sau này.

Tôi đang sử dụng TDD khá thường xuyên trong công việc. Kinh nghiệm của tôi là TDD tự biện minh vì bạn không phải trả thêm thời gian hoặc công sức, bạn hãy lưu nó.

• Vì tôi sử dụng TDD, tôi dành ít thời gian hơn để gỡ lỗi. Nó chỉ hoạt động ngay từ đầu vì tôi không coi mã sản xuất được viết miễn là các bài kiểm tra không vượt qua.

• QA báo cáo ít lỗi hơn nhiều, vì vậy chúng tôi tiết kiệm chi phí sửa chữa mã của chúng tôi sau khi phát hành. Điều này là do TDD không cho phép bạn viết mã mà không cần kiểm tra nên phạm vi bảo hiểm mã tốt hơn nhiều.

• Tôi có thể chạy mã (hiệu quả) của mình thường xuyên hơn và nhanh hơn vì tôi không cần phải khởi động toàn bộ máy chủ ứng dụng. Bắt đầu bài kiểm tra đơn vị là một thứ tự cường độ nhanh hơn. Tất nhiên tôi chỉ được hưởng lợi từ nó khi thử nghiệm đã được thực thi khi tôi muốn thử mã sản xuất. Khi các bài kiểm tra đến sau đó lợi ích này bị bỏ lỡ.

• Tôi làm thử nghiệm thủ công ít hơn nhiều. Các đồng nghiệp của tôi, những người không thực hành TDD đã dành rất nhiều thời gian nhấp qua ứng dụng cho đến khi họ đạt đến điểm mà mã mới được thực thi. Tôi chỉ kiểm tra thủ công một lần, ngay trước khi tôi cam kết kiểm soát phiên bản.

• Ngay cả khi tôi sử dụng trình gỡ lỗi, việc gỡ lỗi thực thi kiểm tra sẽ nhanh hơn nhiều so với toàn bộ ứng dụng.

Có thể bạn nghĩ về các bài kiểm tra đơn vị như các bài kiểm tra hồi quy. Đó là một trong những mục đích của họ nhưng hiểu chúng là một công cụ để phát triển làm cho chúng đáng giá hơn nhiều.

Một lợi thế khác (ngoài những người được đề cập bởi những người khác đã trả lời) phát huy khi người kiểm tra chấp nhận khách hàng hoặc người dùng sản xuất (trời cấm) phát hiện ra lỗi. Biến báo cáo lỗi thành một bài kiểm tra kiểu TDD cho lớp dường như có lỗi. Xem nó thất bại. Sửa nó. Xem nó qua. Sau đó, bạn biết rằng bạn đã sửa lỗi. Kỹ thuật này đã giúp tôi tiết kiệm hàng giờ.

Chà, tôi biết rằng cá nhân tôi được hưởng lợi bằng cách nhanh gấp đôi so với các nhà phát triển đồng nghiệp của tôi và viết ít hơn một nửa các lỗi họ làm vì họ KHÔNG làm TDD. Những người có lẽ nên tốt hơn tôi thậm chí ... Tôi vượt trội họ ít nhất là 2 nhân tố.

Tôi đã không đến đó ngay lập tức. Tôi khá giỏi trong việc viết mã ra khỏi vòng bít và không cần khai thác. Có vẻ như một sự lãng phí lớn để viết tất cả các crap thêm này. Nhưng nó thực hiện một số điều, bao gồm (không độc quyền):

• Buộc một thiết kế hướng đến việc tách rời và tái sử dụng (mọi thứ phải được sử dụng lại trong một bài kiểm tra đơn vị).
• Cung cấp một nền tảng để phát triển mã theo từng phần nhỏ và mô-đun để tôi không phải tìm ra mọi thứ và hoàn thành trước khi chạy một loại thử nghiệm đơn giản "Liệu nó có biên dịch và thực hiện đầu vào" không.
• Cung cấp một nền tảng thử nghiệm nhanh để thực hiện các thay đổi khi mọi người yêu cầu thay đổi tính năng mà tôi không mong đợi.

Một ví dụ về bit sau này là một dự án tôi hiện đang làm việc trong đó người dẫn đầu đột nhiên quyết định HOÀN TOÀN viết lại giao thức truyền thông mà nó sử dụng với lý do khá nhiều. Tôi đã có thể phản ứng với sự thay đổi đó trong 2 giờ khi tôi đã tách nó ra khỏi mọi thứ khác và có thể làm việc hoàn toàn độc lập cho đến khi lần cuối cùng kết hợp nó và tích hợp kiểm tra bước đó. Hầu hết các đồng nghiệp của tôi có thể đã ở đó một ngày hoặc hơn vì mã của họ sẽ không bị tách rời và họ sẽ thay đổi ở đây, ở đó, ở mọi nơi ... biên dịch tất cả ... kiểm tra tích hợp ... lặp lại, lặp lại ... Mất nhiều thời gian hơn theo cách đó và không nơi nào ổn định.

Câu trả lời là có. Trong công ty của tôi, chúng tôi đã phát triển một ứng dụng C ++ trong hơn 20 năm. Năm ngoái, chúng tôi đã tham gia TDD trong một số mô-đun mới và tỷ lệ lỗi giảm đáng kể. Chúng tôi thích nó đến nỗi một số người trong chúng tôi thậm chí còn thêm các bài kiểm tra vào mã kế thừa mỗi khi chúng tôi thay đổi điều gì đó ở đó.

Hơn nữa, toàn bộ một mô-đun đã được hoàn thành từ đầu đến cuối, trải qua quá trình sản xuất mà không bao giờ gặp lỗi (và đó cũng là một mô-đun quan trọng). Do đó, sự phát triển của nó nhanh hơn bình thường, bởi vì thông thường những gì sẽ xảy ra nếu một mô-đun sẽ được "hoàn thành", chỉ để trả lại 4-5 lần từ bản thử nghiệm beta để sửa lỗi. Đó là một cải tiến đáng kể và các nhà phát triển cũng hài lòng hơn về quy trình mới.

Tôi chưa thực hiện nhiều Rails TDD, nhưng tôi đã làm được nhiều thứ trong C ++, C #, Java và Python. Tôi có thể nói với bạn rằng nó chắc chắn hoạt động. Tôi đoán là bạn đang dành nhiều thời gian suy nghĩ về tên thử nghiệm vì bạn không đủ tự tin. Viết bài kiểm tra của bạn trước, nhưng hãy để sự sáng tạo của bạn tuôn trào ...

Tôi đã nhận thấy rằng một khi bạn thực sự hiểu được TDD, bạn bắt đầu quan tâm hơn một chút về "Làm thế nào tôi sẽ đặt tên cho bài kiểm tra này ... argh!", Và bạn chỉ cần đọc nó, tái cấu trúc và điều chỉnh đã được viết kiểm tra để phù hợp với tình hình hiện tại.

Thời gian cho một mẹo

Mẹo số 1

Vì vậy, mẹo tôi nghĩ sẽ giúp bạn nhiều nhất là đừng quá lo lắng. Một trong những điều đẹp nhất về TDD là nó mang lại cho bạn sự can đảm về việc thay đổi những thứ đã được viết và làm việc. Và bao gồm các bài kiểm tra.

Mẹo số 2

Bắt đầu các bài kiểm tra lớp mới bằng một bài kiểm tra "canCreate" đơn giản, chỉ để đưa tâm trí của bạn đi đúng hướng, như trong "Ok, tôi đang làm việc trên lớp này ngay bây giờ ... đúng."

Sau đó bắt đầu thêm nhiều bài kiểm tra, nhưng chỉ thực hiện một lần một lần và đảm bảo rằng mỗi bài kiểm tra bạn tạo, đó là trường hợp đơn giản tiếp theo xuất hiện trong đầu bạn lúc đó (nghĩ về nó không quá 30 giây, và sau đó hết thời gian với những gì tốt nhất bạn có tại thời điểm đó).

Và nhớ

Đừng lo lắng về việc tái cấu trúc các bài kiểm tra hiện tại hoặc thậm chí loại bỏ các bài kiểm tra lỗi thời hoặc dư thừa. Không nhiều người nhận ra điều này, nhưng trong TDD bạn thực sự có được 2 lưới an toàn với giá 1. Các thử nghiệm của bạn là mạng an toàn để thay đổi mã sản xuất, nhưng mã sản xuất của bạn cũng là một mạng lưới an toàn để tái cấu trúc các thử nghiệm. Các mối quan hệ là lẫn nhau. Đó thực sự là một trường hợp tốt của khớp nối chặt chẽ.

Cho nó một phát súng nữa. Và hãy để tôi khuyên bạn nên xem Clean Code Casts , đặc biệt là những người về TDD.

Ví dụ không tầm thường trong thế giới thực:

Tôi đã phải viết một hàm chuyển đổi cấu trúc dữ liệu. Đầu vào sẽ là một cấu trúc dữ liệu (thực ra là một cấu trúc dữ liệu lồng nhau, giống như một cái cây) và đầu ra sẽ là một cấu trúc dữ liệu tương tự. Tôi không thể hình dung sự chuyển đổi thực tế trong tâm trí của tôi. Một trong những lợi ích chính của TDD (đối với tôi, dù sao đi nữa) là việc thực thi các bước bé nếu bạn không biết cách tiến hành (xem "Ví dụ TDD của Kent Becks"). Bởi vì tôi không biết chuyện này sẽ diễn ra ở đâu nên tôi đã bắt đầu với những trường hợp cơ bản đơn giản như đầu vào trống rỗng hoặc tầm thường và tìm cách giải quyết những vụ án phức tạp hơn cho đến khi tôi nhận ra mình đã bao quát tất cả. Cuối cùng, tôi đã có một thuật toán làm việc và các bài kiểm tra đã chứng minh điều đó. Các bài kiểm tra không chỉ chứng minh rằng việc triển khai của tôi đang hoạt động ngay bây giờ, chúng còn giúp tôi không làm hỏng bất cứ điều gì sau này.

Tôi không thích ý tưởng mù quáng làm theo bất kỳ lời khuyên chung chung nào vì tôi không tin rằng có một đề xuất một kích cỡ phù hợp với tất cả các nhà phát triển sẽ làm việc hiệu quả hơn và giảm lỗi trong các ứng dụng. Từ kinh nghiệm của tôi, bạn càng lo lắng về chất lượng, bạn sẽ càng mất đi số lượng tính năng mới được cung cấp. Vì vậy, mức độ quan trọng bạn muốn cung cấp cho chất lượng so với khả năng cung cấp sẽ thực sự phụ thuộc vào sản phẩm và chiến lược hiện tại của bạn và rất có thể đó sẽ là người khác quyết định chiến lược điều quan trọng hơn trong thời điểm hiện tại: mạnh mẽ hoặc khả năng cung cấp.

Ngay cả quyết định này không phải là đen hay trắng. Rất có thể một số phần trong ứng dụng của bạn phải mạnh mẽ trong khi những phần khác thì không. Khi bạn xác định được bộ phận nào có chất lượng cao, bạn nên tập trung vào chúng từ góc độ thử nghiệm vì bạn muốn đảm bảo chất lượng cao cho các bộ phận đó.

Tất cả những gì tôi đã nói cho đến nay không liên quan gì đến TDD, đặc biệt là về cách viết bài kiểm tra trước khi thực hiện, nhưng tôi tin rằng điều quan trọng là phải phân tách lợi ích của việc kiểm tra mã so với viết bài kiểm tra trước.

Khi bạn hiểu được lợi ích của việc kiểm tra chính nó, TDD hay không, bạn có thể thảo luận về chiến lược thử nghiệm cho mã bạn muốn được kiểm tra. Một số người sẽ tranh luận rằng nếu bạn viết bài kiểm tra sau này bạn sẽ bỏ lỡ một số điều kiện trong bài kiểm tra của mình, nhưng tôi tin rằng bạn nên là người đánh giá xem điều đó có áp dụng cho bạn không. Nó chắc chắn không áp dụng cho tôi.

Vì vậy, đây là cách nó làm việc cho tôi. Về cơ bản có hai tình huống sẽ khiến tôi viết bài kiểm tra: nó sẽ chỉ cải thiện chất lượng hoặc nó sẽ tăng tốc độ phát triển một số tính năng của tôi. Vì vậy, tình huống tôi sẽ viết bài kiểm tra là khi không có tính năng mới trong hồ sơ tồn đọng và sau đó tôi có thể quyết định cải thiện hiệu suất của ứng dụng, đơn giản hóa cơ sở mã hoặc cải thiện bộ kiểm tra. Một tình huống khác là cần phải có một mã làm việc vững chắc, nơi các lỗi sẽ có tác động đủ lớn trong các khách hàng thực sự. Tuy nhiên, một số khác là để kiểm tra mã phức tạp, dễ bị phá vỡ khi làm việc với nó. Ví dụ, có một lớp QueryBuilder trong cơ sở mã của tôi xử lý nhiều trường hợp sử dụng và sẽ dễ dàng phá vỡ một số trong số chúng trong khi sửa lỗi hoặc thêm một tính năng mới.

Cuối cùng, có trường hợp viết bài kiểm tra trước tiên cho phép tôi viết một tính năng nhanh hơn sau đó không viết bài kiểm tra nào cả. QueryBuilder đó cũng là một trường hợp quy tắc này cũng được áp dụng, nhưng điều đó không có nghĩa là TDD cũng sẽ là con đường tốt nhất. Một ví dụ khác về TDD giúp tăng tốc độ phát triển là để kiểm tra việc tạo Excel chẳng hạn, trong khi trong ứng dụng thực, bạn có thể phải thực hiện một số bước mỗi lần bạn muốn kiểm tra một số điều kiện cụ thể trong thế hệ. Hoặc nếu bạn cần tạo một số bản ghi để kiểm tra một tính năng và thật khó hoặc không thể xóa chúng theo cách thủ công sau khi bạn đã kiểm tra mã theo cách thủ công.

Vì vậy, nếu bạn dễ dàng tạo lại các bước để chạy một số mã đang phát triển theo chương trình (thông qua các bài kiểm tra), hãy thực hiện. Nhưng nếu việc viết bài kiểm tra phức tạp hơn thì kiểm tra bằng tay, thì bạn phải quyết định xem đây có phải là lúc để tập trung vào chất lượng hay nếu bạn có nhiều yêu cầu trong hồ sơ tồn đọng của bạn và ai đó trong công ty có thể sẽ biết rõ hơn và cho bạn biết biết nơi bạn nên tập trung phù hợp với nhu cầu hiện tại và chiến lược công ty của họ.

Trong một thế giới lý tưởng, tất cả các mã đều được kiểm tra, nhưng người ta không thể giả vờ rằng không có sự đánh đổi và cho rằng TDD luôn là con đường tốt nhất và duy nhất. Như với tất cả các thực tiễn tốt nhất hiện có, bạn phải luôn tập trung vào những gì tốt nhất cho công ty bạn làm việc thay vì những gì tốt hơn cho bạn. Khi bạn tự làm chủ, bạn có thể tự do quyết định thực hiện TDD mọi lúc nếu bạn nghĩ đó là con đường tốt nhất. Nếu công ty của bạn tin rằng tất cả mã phải được kiểm tra, thì bạn phải viết kiểm tra cho tất cả mã bạn viết. Nhưng đối với hầu hết các trường hợp, bạn phải có được bức tranh lớn và hiểu được sự đánh đổi trước khi bạn đưa ra bất kỳ quyết định nào. Xin lỗi, nhưng đây không phải là một khoa học chính xác và không có câu trả lời dễ dàng (hoặc khó) phù hợp với tất cả mọi người mà bạn nên tuân theo mọi lúc.

Cũng giống như với các mẫu thiết kế. Hiểu cách chúng hoạt động và lý do tại sao chúng được tạo ra và loại vấn đề nào chúng giải quyết và nhược điểm của chúng là gì. Hiểu lý luận là cách quan trọng hơn nhiều so với việc ghi nhớ các giải pháp được đề xuất. Một hoạt động đắt tiền ngày hôm nay có thể dễ dàng đạt được vào ngày mai với các công nghệ khác. Nếu tiền đề cho một số giải pháp được thiết lập tốt không còn hiệu lực thì có lẽ giải pháp đó không còn là giải pháp tốt nhất để sử dụng. Khi các yêu cầu, công nghệ có sẵn hoặc chiến lược của công ty đã thay đổi, bạn phải luôn đánh giá lại hộp công cụ của mình và khi điều đó xảy ra, bạn cần hiểu lý do tại sao bạn chọn mỗi đường dẫn ở vị trí đầu tiên thay vì lấy chúng làm lựa chọn tốt nhất.