Là thử nghiệm đơn vị hoặc phát triển dựa trên thử nghiệm có giá trị?

Nhóm của tôi đang làm việc đang chuyển sang Scrum và các nhóm khác đang bắt đầu thực hiện phát triển dựa trên thử nghiệm bằng cách sử dụng thử nghiệm đơn vị và thử nghiệm chấp nhận của người dùng. Tôi thích các UAT, nhưng tôi không được bán trong thử nghiệm đơn vị để phát triển dựa trên thử nghiệm hoặc phát triển dựa trên thử nghiệm nói chung.

Có vẻ như các bài kiểm tra viết là công việc làm thêm, mang lại cho mọi người một cái nạng khi họ viết mã thực sự và có thể không hiệu quả rất thường xuyên.

Tôi hiểu cách kiểm tra đơn vị hoạt động và cách viết chúng, nhưng bất cứ ai cũng có thể đưa ra trường hợp rằng đó thực sự là một ý tưởng hay và đáng để bỏ công sức và thời gian?

Ngoài ra, có điều gì làm TDD đặc biệt tốt cho Scrum không?

Câu trả lời ngắn gọn: Hoàn toàn tích cực.

Trả lời dài: Bài kiểm tra đơn vị là một trong những thực tiễn quan trọng nhất mà tôi cố gắng và ảnh hưởng tại nơi làm việc của tôi (ngân hàng lớn, giao dịch fx). Vâng, họ là công việc làm thêm, nhưng đó là công việc trả lại nhiều lần. Kiểm tra đơn vị tự động không chỉ giúp bạn thực sự thực thi mã bạn đang viết và tất nhiên xác minh kỳ vọng của bạn mà chúng còn hoạt động như một loại chó canh gác cho những thay đổi trong tương lai mà bạn hoặc người khác có thể thực hiện. Thử nghiệm phá vỡ sẽ dẫn đến khi ai đó thay đổi mã theo những cách không mong muốn. Tôi nghĩ rằng giá trị tương đối của các thử nghiệm đơn vị giảm tương quan với mức độ thay đổi và tăng trưởng dự kiến ​​trong một cơ sở mã, nhưng xác minh ban đầu về những gì mã làm cho nó đáng giá ngay cả khi thay đổi dự kiến ​​thấp. Giá trị thử nghiệm đơn vị cũng phụ thuộc vào chi phí của khuyết tật. Nếu chi phí (trong đó chi phí là mất thời gian / tiền bạc / danh tiếng / nỗ lực trong tương lai) của một khiếm khuyết bằng 0, thì giá trị tương đối của một bài kiểm tra cũng bằng không; tuy nhiên điều này gần như không bao giờ xảy ra trong môi trường thương mại.

Chúng tôi thường không thuê người nữa, những người không thường xuyên tạo ra các bài kiểm tra đơn vị như một phần công việc của họ - đó chỉ là điều chúng tôi mong đợi, như bật lên mỗi ngày. Tôi chưa thấy phân tích lợi ích chi phí thuần túy khi thử nghiệm đơn vị (ai đó cảm thấy thoải mái khi chỉ cho tôi một), tuy nhiên tôi có thể nói từ kinh nghiệm rằng trong môi trường thương mại, việc chứng minh mã hoạt động trong một hệ thống quan trọng lớn là đáng giá . Nó cũng cho phép tôi ngủ ngon hơn vào ban đêm khi biết rằng mã tôi đã viết có thể hoạt động được (ở một mức độ nhất định) và nếu nó thay đổi, ai đó sẽ được cảnh báo về bất kỳ tác dụng phụ không mong muốn nào do bản dựng bị hỏng.

Kiểm tra hướng phát triển, trong tâm trí của tôi không phải là một phương pháp thử nghiệm. Đó thực sự là một cách tiếp cận / thực hành thiết kế với đầu ra là hệ thống làm việc và một bộ các bài kiểm tra đơn vị. Tôi ít tôn giáo về thực hành này vì nó là một kỹ năng khá khó để phát triển và hoàn thiện. Cá nhân nếu tôi đang xây dựng một hệ thống và tôi không có ý tưởng rõ ràng về cách thức hoạt động của nó, tôi sẽ sử dụng TDD để giúp tôi tìm đường trong bóng tối. Tuy nhiên, nếu tôi đang áp dụng một mô hình / giải pháp hiện có, tôi thường sẽ không.

Trong trường hợp không có bằng chứng toán học cho bạn rằng việc viết bài kiểm tra đơn vị là hợp lý, tôi khuyến khích bạn nên thử nó trong một thời gian dài và tự mình trải nghiệm những lợi ích.

Các lỗi được tìm thấy trước đó ít tốn kém hơn để sửa chữa hơn các lỗi được tìm thấy sau đó. TDD giúp bạn xác minh tính chính xác của hệ thống của bạn. Bạn đầu tư thêm một chút về phía trước, nhưng sẽ lấy lại sau. Biểu đồ là một chút phóng đại, nhưng nó cho thấy ý tưởng tốt.

Nguồn hình ảnh

Là thử nghiệm đơn vị hoặc phát triển dựa trên thử nghiệm có giá trị trong khi?

Có nó làm . Bác Bob (Robert C Martin) đã nói trong một bài thuyết trình;

Đối với một nhà phát triển để chứng minh rằng mã của anh ta đang hoạt động tốt hơn để viết một bài kiểm tra và vượt qua nó hơn là la hét, hát hoặc nhảy về nó.

Và vì bạn sẽ không xóa bài kiểm tra, miễn là bài kiểm tra vượt qua, bạn chắc chắn rằng chức năng đang hoạt động - các vấn đề hồi quy đã được giải quyết.

Có rất nhiều thứ được viết trên đó,

1. Bạn có trách nhiệm làm cho tính năng đó hoạt động. Viết một bài kiểm tra. Cứ làm đi.
2. Khi nào cần thay thế Kiểm tra đơn vị bằng Kiểm tra tích hợp

Là SCRUM, thử nghiệm đơn vị và TDD có liên quan?

Một thời gian ngắn, khi bạn là một bậc thầy tại Unit testingbạn sẽ ở gần TDD. SCRUM không có gì để làm với điều này, nhưng như họ nói, những điều tuyệt vời trộn lẫn với nhau, những kỹ thuật phát triển phần mềm này sẽ trở thành một ngăn xếp tuyệt vời , nếu bạn chưa thử thì hãy thử.

Có điều gì làm TDD đặc biệt tốt cho SCRUM không?

Như tôi đã nói ở trên họ làm cho một sự kết hợp tốt ; Nếu bạn thêm một số thử nghiệm tự động hóa vào nó, thì nó đặc biệt hơn .

Có vẻ như các bài kiểm tra viết là công việc làm thêm, mang lại cho mọi người một cái nạng khi họ viết mã thực sự và có thể không hiệu quả rất thường xuyên.

Kiểm tra đơn vị có giá trị như một cái nạng. Nó hỗ trợ các nỗ lực phát triển của bạn, cho phép bạn thay đổi triển khai mà không sợ ứng dụng của bạn sẽ ngừng hoạt động theo yêu cầu. Các bài kiểm tra đơn vị cũng nhiều hơn một cái nạng, vì chúng cung cấp cho bạn một công cụ mà bạn có thể xác nhận rằng việc triển khai của bạn phù hợp với các yêu cầu.

Tất cả các thử nghiệm, cho dù thử nghiệm đơn vị, thử nghiệm chấp nhận, thử nghiệm tích hợp, v.v., chỉ hiệu quả như những người sử dụng chúng. Nếu bạn tiếp cận công việc của mình một cách chậm chạp, các bài kiểm tra của bạn sẽ cẩu thả, và việc thực hiện của bạn sẽ có vấn đề. Vậy tại sao phải bận tâm? Bạn bận tâm kiểm tra vì bạn cần chứng minh cho bản thân và khách hàng của mình rằng phần mềm của bạn hoạt động và không có bất kỳ vấn đề nào có thể ngăn phần mềm được sử dụng. Đúng, các bài kiểm tra chắc chắn là công việc bổ sung, nhưng cách bạn tiến hành kiểm tra sẽ xác định bạn sẽ cần bao nhiêu nỗ lực để sửa lỗi sau khi phát hành, và mã của bạn sẽ cần bao nhiêu nỗ lực để thay đổi và duy trì.

Tôi hiểu cách kiểm tra đơn vị hoạt động và cách viết chúng, nhưng bất cứ ai cũng có thể đưa ra trường hợp rằng đó thực sự là một ý tưởng hay và đáng để bỏ công sức và thời gian?

TDD, và thực sự là bất kỳ phương pháp nào yêu cầu bạn viết bài kiểm tra trước khi bạn viết mã theo cách tiếp cận mà bạn đã nỗ lực sớm như một khoản thanh toán cho khoản nợ kỹ thuật trong tương lai. Khi bạn thực hiện dự án, bất cứ điều gì bị bỏ lỡ hoặc không được triển khai tốt sẽ phát sinh thêm nợ kỹ thuật dưới dạng tăng độ khó bảo trì, điều này ảnh hưởng trực tiếp đến chi phí trong tương lai và yêu cầu cung cấp lại. Kiểm tra trước đảm bảo rằng bạn không chỉ nỗ lực giải quyết nợ kỹ thuật trong tương lai mà còn đảm bảo rằng bạn mã hóa các yêu cầu của mình theo cách mà chúng có thể được xác minh chỉ bằng cách chạy mã của bạn. Kiểm tra trước tiên cũng cung cấp cho bạn cơ hội để xác thực sự hiểu biết của bạn về miền vấn đề trước khi bạn cam kết giải quyết vấn đề trong mã và nó xác nhận các nỗ lực triển khai của bạn.

Nó thực sự đi đến nỗ lực tối đa hóa giá trị kinh doanh của mã của bạn. Mã phần lớn chưa được kiểm tra và khó bảo trì nói chung là rẻ và nhanh để tạo, và rất tốn kém để duy trì trong suốt vòng đời của sản phẩm sau khi phát hành. Mã đã được kiểm tra kỹ lưỡng ở cấp độ đơn vị thường đắt hơn để tạo, nhưng chi phí tương đối ít để duy trì trong suốt vòng đời của sản phẩm sau khi phát hành.

Ngoài ra, có điều gì làm TDD đặc biệt tốt cho SCRUM không?

TDD không đặc biệt tốt cho bất kỳ phương pháp cụ thể nào. Nó chỉ đơn giản là một công cụ. Một thực tiễn mà bạn có thể tích hợp vào các quy trình phát triển của mình để giúp bạn đạt được kết quả cụ thể. Vì vậy, để trả lời câu hỏi của bạn, TDD là miễn phí cho phương pháp của bạn, cho dù đó là SCRUM hay bất kỳ phương pháp nào khác.

Mọi người nghĩ rằng đó là nỗ lực thêm bởi vì nó là một hoạt động phía trước. Những gì bạn mất trong thời gian bây giờ bạn có được trở lại sau này.

Lý do của tôi để kiểm tra đơn vị cũng bao gồm:

Cung cấp cho bạn một mục tiêu: Bạn không thể viết bài kiểm tra nếu bạn không biết phần mềm nên làm gì. Điều này giúp loại bỏ các vấn đề trong thông số kỹ thuật sớm hơn là sau này.

Cung cấp cho bạn một cảm giác tiến bộ.

Cảnh báo bạn nếu thay đổi mã làm thay đổi đầu ra của các vùng mã khác. Điều đó làm cho tái cấu trúc dễ dàng hơn.

Cung cấp một lớp tài liệu bổ sung (đặc biệt nếu bạn nhận xét đúng bài kiểm tra của mình).

Khuyến khích tất cả các loại thực hành tốt. Bởi vì các bài kiểm tra nên chạy nhanh, nó khuyến khích bạn viết mã được tách rời và hỗ trợ chế độ chế giễu. Điều này tất cả hỗ trợ tái cấu trúc.

Có những người khác cũng được đề cập trong các bài viết khác trong chủ đề này. Đó là giá trị nó.

Là thử nghiệm đơn vị hoặc phát triển dựa trên thử nghiệm có giá trị?

Chắc chắn là có (xem các câu trả lời khác)

[Có phải] thực sự là một ý tưởng tốt và đáng giá cho nỗ lực và thời gian?

• Có nếu bạn bắt đầu một cái gì đó mới (thêm một mô-đun mới hoặc một ứng dụng hoàn toàn mới)
• Không, nếu đã có rất nhiều mã hiện tại không được phát triển dựa trên thử nghiệm và phải được mở rộng (di sản).

Theo tôi, phát triển theo hướng kiểm thử là hiệu quả nhất nếu bạn viết các bài kiểm tra đơn vị trước mã thực tế. bằng cách này, mã hoàn thành các bài kiểm tra trở nên tách biệt rõ ràng với tối thiểu các tham chiếu bên ngoài có thể kiểm tra dễ dàng.

Nếu mã đã tồn tại mà không có kiểm thử đơn vị thì thường phải viết thêm các bài kiểm tra đơn vị sau đó vì mã không được viết để kiểm tra dễ dàng.

Nếu bạn làm TDD, mã tự động rất dễ kiểm tra.

Hãy để tôi tiếp cận điều này từ phía bên kia. Điều gì xảy ra khi bạn phát triển một ứng dụng không tầm thường mà không có bài kiểm tra đơn vị? Nếu bạn có một bộ phận QA tốt, một trong những điều đầu tiên sẽ xảy ra là bạn sẽ thấy rằng bạn có một số lượng lớn các vấn đề được báo cáo. Tại sao vì bạn không kiểm tra những gì bạn đã làm và cho rằng nó sẽ hoạt động và vì bạn không chú ý nhiều đến các yêu cầu và ứng dụng của bạn không đáp ứng chúng. Rất tiếc quay lại bảng vẽ để viết lại và sửa chữa. Bây giờ bạn đã thực hiện các bản sửa lỗi và tìm ra một loạt các vấn đề mới bởi vì bạn không có cách nào để xác minh rằng các bản sửa lỗi của bạn không ảnh hưởng đến bất cứ điều gì khác trước khi bạn chuyển sang QA. Oops thời hạn đã đến và đi và quản lý là buồn.

Tình hình sẽ tồi tệ hơn nếu bạn không có bộ phận QA tốt bởi vì sau đó người dùng sẽ tìm thấy các lỗi và không chỉ khiến sếp của bạn không hài lòng, nó có thể khiến môi trường sản xuất quỳ xuống và hàng trăm hoặc thậm chí hàng ngàn người sẽ ở bế tắc trong khi bạn sửa các lỗi mà kiểm tra đơn vị sẽ ngăn chặn. Đây KHÔNG phải là một lựa chọn nghề nghiệp tốt.

Bây giờ giả sử cách tiếp cận cao bồi này diễn ra trong nhiều năm? Bây giờ mọi thay đổi, thậm chí là tầm thường, dường như làm nổi lên một vấn đề mới không được xem xét. Không chỉ vậy, nhưng nhiều điều bạn muốn làm để làm cho ứng dụng hoạt động tốt hơn, bạn không thể làm vì chúng quá rủi ro hoặc quá đắt hoặc cả hai. Vì vậy, bạn đặt các bản vá trên các bản vá làm cho hệ thống ngày càng phức tạp và buggier và khó sử dụng hơn.

Người dùng bắt đầu đặt câu hỏi về ước tính thời gian của bạn bởi vì họ ngày càng lớn hơn và thật khó để giải thích với họ rằng hệ thống đã trở thành một mớ hỗn độn phức tạp như vậy, thật khó để tìm ra nơi nào để thay đổi và vẫn khó hơn để đảm bảo họ không ' t phá vỡ một cái gì đó khác.

Tôi đã làm việc ở một nơi như thế này, sau mười năm phát triển, hầu như chúng tôi không muốn làm gì để khắc phục các vấn đề thực sự có thể được thực hiện bởi vì chúng tôi không thể biết được hàng trăm ứng dụng khách tùy chỉnh nào sẽ bị hỏng. Các nhà phát triển ban đầu có rất nhiều loại "thử nghiệm đơn vị, chúng tôi không cần loại thử nghiệm đơn vị hôi thối". Mọi người theo dõi họ đều phải chịu đựng sự thiển cận của họ.

Không có kiểm tra đơn vị, phần mềm là lỗi và mất nhiều thời gian hơn để phát triển ban đầu và duy trì. Tại sao bạn không muốn làm bài kiểm tra trên trái đất? Thời gian bạn viết bài kiểm tra sẽ ít hơn nhiều so với thời gian bạn dành để khắc phục các sự cố bạn nên tìm thấy trước đó (lỗi càng sớm thì càng mất ít thời gian để khắc phục) và các vấn đề bạn sẽ tránh hoàn toàn bằng cách viết bài kiểm tra đầu tiên giúp hiểu rõ hơn về các yêu cầu trước khi bạn bắt đầu viết mã.

Tất cả các mã bạn viết cần phải được kiểm tra tại một số điểm. Bạn không muốn viết tất cả mọi thứ trong một lần và sau đó nhấn nút biên dịch và bắt chéo ngón tay của bạn. Bạn viết và biên dịch các khối nhỏ và gửi đầu vào được làm cẩn thận theo mã của bạn để xác minh rằng nó làm những gì bạn nghĩ nó làm. Sau đó, bạn thường xóa bộ máy kiểm tra đặc biệt của mình và chuyển sang thành phần tiếp theo.

Với thử nghiệm đơn vị, nó đơn giản hóa quá trình này và cung cấp cho bạn một cái cớ để giữ cho các thử nghiệm của bạn xung quanh. Theo cách đó, nếu bạn thực hiện bất kỳ thay đổi nào phá vỡ nội dung mà bạn đã kiểm tra trước đây, bạn có thể nắm bắt được hồi quy đó một cách rõ ràng thay vì cho phép nó ảnh hưởng đến các phần khác trong mã của bạn. Có giá trị thực sự trong đó.

Đối với cách tiếp cận tái cấu trúc đỏ-xanh đối với TDD, tôi thấy điều đó hơi tẻ nhạt. Nhưng để mỗi riêng của mình.

Hầu hết thời gian tôi thấy các nhà phát triển đều kiên cường với ý tưởng viết bài kiểm tra. Nó không quá nhiều đến nỗi họ sẽ cho rằng các bài kiểm tra không có giá trị mà thay vào đó chúng chỉ là một phương tiện để tìm ra cách giải quyết một vấn đề cụ thể. Thông thường vấn đề này thay đổi dựa trên bối cảnh. Một khi điều đó được thực hiện thì các bài kiểm tra không phục vụ mục đích và cũng có thể bị xóa. Đây là một mẫu bối cảnh mà các đồng nghiệp của tôi đã đưa ra trong quá khứ về cách quyết định khi nào nên viết bài kiểm tra và bạn sẽ tìm thấy câu trả lời duy nhất có thể theo họ là không bao giờ:

• vấn đề hiện tại phải là một ví dụ trong sách giáo khoa cho TDD, chẳng hạn như ngăn xếp hoặc máy tính
• mã tầm thường không nên được kiểm tra (làm mất hiệu lực đối số trước đó)
• mã quan trọng hoặc khó khăn cần được kiểm tra kỹ lưỡng (ngụ ý bởi đối số trước đó)
• các thử nghiệm không nên được kết hợp chặt chẽ với việc triển khai để cho phép quét tái cấu trúc (làm mất hiệu lực đối số trước đó)
• việc kiểm tra các tác dụng phụ như gọi dịch vụ của bên thứ ba với tải trọng cụ thể là không cần thiết (vì vậy không cần kiểm tra hộp đen)

Trên thực tế có một loại thử nghiệm mà tôi đã tìm thấy thường được chấp nhận và tôi tin rằng cuối cùng là vô dụng. Cụ thể là thử nghiệm dựa trên GUI như bằng cách sử dụng selen, webdo, watir hoặc arquillian. Đây là cách chúng tôi có được chu kỳ xây dựng 7 giờ thay vì chu kỳ xây dựng 5 phút trong các dự án TDD của tôi.

Những nhà phát triển tương tự thường phàn nàn với mọi người khác về mức độ xấu của mã và mức độ không đủ của các nhà phát triển trước đó. Họ cũng thấy điều cực kỳ quan trọng là bạn tạo ra một thiết kế phù hợp bằng cách sử dụng bảng trắng, văn phòng MS hoặc wiki và rất cẩn thận để đảm bảo thiết kế này vẫn được cập nhật.

Đó là điều cuối cùng thực sự khiến tôi nhận ra những nhà phát triển như vậy là lừa đảo. Chúng ta đều biết bất kỳ tài liệu thiết kế nào không phải là thử nghiệm đơn vị sẽ trở nên lỗi thời và sẽ không được cập nhật vì chi phí bảo trì tuyệt đối để làm như vậy. Trong thực tế, tôi đã cố gắng và cố gắng đưa ra một phương tiện tốt để thể hiện ý tưởng thiết kế ở định dạng văn phòng MS rất hữu ích và dễ đọc cả trước và sau khi thực tế viết mã. Tôi đã thất bại trong mọi trường hợp và mặc dù có những người quản lý để tạo ra một tài liệu văn phòng MS có vẻ đẹp nhưng tôi chưa bao giờ thực sự thấy chúng hữu ích.

Vì vậy, bạn có một sự lựa chọn. Bạn có thể thực hiện thiết kế và tài liệu bằng cách thực hành TDD, đây là phương pháp duy nhất được biết và đã được chứng minh để sản xuất tài liệu đó dựa trên 10 năm kinh nghiệm phát triển của tôi. Hoặc bạn có thể đi vào chính trị.