Ý thức kiểm tra đơn vị mà không cần TDD

Chúng tôi có dự án mới (khá lớn) bắt đầu, mà chúng tôi dự định phát triển bằng TDD.

Ý tưởng về TDD đã thất bại (nhiều lý do kinh doanh và phi kinh doanh), nhưng ngay bây giờ chúng tôi có một cuộc trò chuyện - chúng tôi có nên viết bài kiểm tra đơn vị hay không. Bạn tôi nói rằng không có ý nghĩa (hoặc gần bằng không) khi viết bài kiểm tra đơn vị mà không có TDD, chúng ta chỉ nên tập trung vào các bài kiểm tra tích hợp. Tôi tin điều ngược lại, rằng vẫn còn một số ý nghĩa trong việc viết các bài kiểm tra đơn vị đơn giản, chỉ để làm cho mã tương lai nhiều hơn. Bạn nghĩ sao?

Đã thêm: Tôi nghĩ rằng đây không phải là bản sao của >> câu hỏi này << - Tôi hiểu sự khác biệt giữa UT và TDD. Câu hỏi của tôi không phải là về sự khác biệt , mà là về ý nghĩa của việc viết Bài kiểm tra đơn vị không có TDD.

TDD được sử dụng chủ yếu (1) để đảm bảo phạm vi bảo hiểm, (2) và để lái thiết kế có thể bảo trì, dễ hiểu, có thể kiểm tra. Nếu bạn không sử dụng TDD, bạn sẽ không nhận được bảo hiểm mã. Nhưng điều đó không có nghĩa là bạn nên từ bỏ mục tiêu đó và hoàn toàn sống với mức bảo hiểm 0%.

Kiểm tra hồi quy đã được phát minh cho một lý do. Lý do là về lâu dài, chúng giúp bạn tiết kiệm nhiều thời gian hơn trong các lỗi được ngăn chặn hơn là chúng phải nỗ lực thêm để viết. Điều này đã được chứng minh nhiều lần. Vì vậy, trừ khi bạn đang thuyết phục nghiêm túc rằng tổ chức của bạn là nhiều, tốt hơn nhiều ở công nghệ phần mềm so với tất cả các bậc thầy người khuyên kiểm tra hồi quy (hoặc nếu bạn có kế hoạch đi xuống rất sớm để có là không có chạy dài cho bạn), vâng, bạn hoàn toàn nên có các bài kiểm tra đơn vị, vì chính xác lý do áp dụng cho hầu hết mọi tổ chức khác trên thế giới: bởi vì họ bắt lỗi sớm hơn các bài kiểm tra tích hợp và điều đó sẽ giúp bạn tiết kiệm tiền. Không viết chúng giống như chuyển tiền miễn phí chỉ nằm quanh đường.

Tôi có một giai thoại liên quan từ một cái gì đó đang xảy ra ngay bây giờ cho tôi. Tôi đang tham gia một dự án không sử dụng TDD. Những người QA của chúng tôi đang đưa chúng tôi đi theo hướng đó, nhưng chúng tôi là một bộ trang phục nhỏ và đó là một quá trình dài, rút ​​ra.

Dù sao , gần đây tôi đã sử dụng thư viện của bên thứ ba để thực hiện một nhiệm vụ cụ thể. Có một vấn đề liên quan đến việc sử dụng thư viện đó, do đó, về cơ bản tôi đã tự mình viết một phiên bản của thư viện đó. Tổng cộng, nó đã trở thành khoảng 5.000 dòng mã thực thi và khoảng 2 tháng thời gian của tôi. Tôi biết các dòng mã là một số liệu kém, nhưng đối với câu trả lời này, tôi cảm thấy đó là một chỉ số tốt về độ lớn.

Có một cấu trúc dữ liệu cụ thể mà tôi cần, cho phép tôi theo dõi số lượng bit tùy ý. Vì dự án là ở Java, tôi đã chọn Java BitSetvà sửa đổi nó một chút (tôi cũng cần khả năng theo dõi các 0s hàng đầu , điều mà Bitset của Java không làm vì một số lý do .....). Sau khi đạt phạm vi bảo hiểm ~ 93%, tôi bắt đầu viết một số bài kiểm tra thực sự sẽ làm căng thẳng hệ thống mà tôi đã viết. Tôi cần phải đánh giá các khía cạnh nhất định của chức năng để đảm bảo chúng sẽ đủ nhanh cho các yêu cầu cuối cùng của tôi. Không có gì đáng ngạc nhiên, một trong những chức năng mà tôi đã ghi đè từ BitSetgiao diện bị chậm một cách vô lý khi xử lý các tập bit lớn (trong trường hợp này là hàng trăm triệu bit). Các chức năng ghi đè khác dựa vào chức năng này, vì vậy nó là một cổ chai lớn .

Cuối cùng, tôi đã đi đến bảng vẽ và tìm ra cách để điều khiển cấu trúc cơ bản của nó BitSet, đó là một long[]. Tôi đã thiết kế thuật toán, hỏi các đồng nghiệp về đầu vào của họ và sau đó tôi bắt đầu viết mã. Sau đó, tôi chạy thử nghiệm đơn vị. Một số trong số chúng đã bị hỏng, và những cái đã chỉ cho tôi chính xác nơi tôi cần tìm trong thuật toán của mình để sửa nó. Sau khi sửa tất cả các lỗi từ các bài kiểm tra đơn vị, tôi có thể nói rằng hàm này hoạt động như bình thường. Ít nhất, tôi có thể tự tin rằng thuật toán mới này hoạt động tốt như thuật toán trước đó.

Tất nhiên, đây không phải là bằng chứng đạn. Nếu có lỗi trong mã của tôi mà đơn vị kiểm tra không kiểm tra, thì tôi sẽ không biết. Nhưng tất nhiên, lỗi chính xác đó cũng có thể có trong thuật toán chậm hơn của tôi. Tuy nhiên , tôi có thể nói với một mức độ tin cậy cao rằng tôi không phải lo lắng về đầu ra sai từ chức năng cụ thể đó. Các thử nghiệm đơn vị có sẵn đã giúp tôi tiết kiệm hàng giờ, có lẽ là vài ngày, khi thử kiểm tra thuật toán mới để đảm bảo nó chính xác.

Đó là điểm có các bài kiểm tra đơn vị bất kể TDD - có nghĩa là, các bài kiểm tra đơn vị sẽ làm điều này cho bạn trong TDD và bên ngoài TDD đều giống nhau, khi bạn kết thúc việc tái cấu trúc / duy trì mã. Tất nhiên, điều này sẽ được kết hợp với kiểm tra thường xuyên hồi quy, kiểm tra khói, thử nghiệm mờ, vv, nhưng đơn vị thử nghiệm, như các tiểu bang tên, kiểm tra những thứ trên, mức độ nguyên tử nhỏ nhất có thể, mang đến cho bạn hướng vào nơi lỗi đã xuất hiện bất ngờ.

Trong trường hợp của tôi, nếu không có các bài kiểm tra đơn vị hiện có, bằng cách nào đó tôi sẽ phải đưa ra một phương pháp đảm bảo thuật toán hoạt động mọi lúc. Cuối cùng ... nghe có vẻ giống như thử nghiệm đơn vị , phải không?

Bạn có thể chia mã khoảng 4 loại:

1. Đơn giản và hiếm khi thay đổi.
2. Thay đổi đơn giản và thường xuyên.
3. Phức tạp và hiếm khi thay đổi.
4. Thay đổi phức tạp và thường xuyên.

Các bài kiểm tra đơn vị trở nên có giá trị hơn (có khả năng bắt được các lỗi quan trọng) càng đi sâu vào danh sách bạn đi. Trong các dự án cá nhân của tôi, tôi hầu như luôn làm TDD ở loại 4. Ở loại 3 tôi thường làm TDD trừ khi thử nghiệm thủ công đơn giản và nhanh hơn. Ví dụ, mã khử răng cưa sẽ phức tạp để viết, nhưng dễ xác minh trực quan hơn nhiều so với viết thử nghiệm đơn vị, vì vậy thử nghiệm đơn vị sẽ chỉ có giá trị với tôi nếu mã đó thay đổi thường xuyên. Phần còn lại của mã tôi chỉ đặt dưới kiểm tra đơn vị sau khi tôi tìm thấy một lỗi trong chức năng đó.

Đôi khi rất khó để biết trước loại nào mà một khối mã nhất định phù hợp. Giá trị của TDD là bạn không vô tình bỏ lỡ bất kỳ bài kiểm tra đơn vị phức tạp nào. Chi phí của TDD là tất cả thời gian bạn dành để viết các bài kiểm tra đơn vị đơn giản. Tuy nhiên, thông thường những người có kinh nghiệm với một dự án biết với mức độ chắc chắn hợp lý về loại phần khác nhau của mã phù hợp. Nếu bạn không làm TDD, ít nhất bạn nên cố gắng viết các bài kiểm tra có giá trị nhất.

Cho dù đó là bài kiểm tra đơn vị, thành phần, tích hợp hoặc chấp nhận, phần quan trọng là nó phải được tự động hóa. Không có kiểm tra tự động là một sai lầm nghiêm trọng đối với bất kỳ loại phần mềm nào, từ CRUD đơn giản đến các phép tính phức tạp nhất. Lý do là việc viết các bài kiểm tra tự động sẽ luôn có chi phí thấp hơn nhu cầu liên tục để chạy tất cả các bài kiểm tra theo cách thủ công khi bạn không thực hiện theo đơn đặt hàng lớn. Sau khi bạn viết chúng, bạn chỉ cần nhấn một nút để xem chúng có vượt qua hay thất bại. Các bài kiểm tra thủ công sẽ luôn mất nhiều thời gian để chạy và phụ thuộc vào con người (sinh vật sống chán, có thể thiếu chú ý và vân vân) để có thể kiểm tra xem các bài kiểm tra vượt qua hay thất bại. Tóm lại, luôn luôn viết bài kiểm tra tự động.

Bây giờ, về lý do tại sao đồng nghiệp của bạn có thể chống lại việc thực hiện bất kỳ loại thử nghiệm đơn vị nào mà không có TDD: Có lẽ vì khó tin tưởng các thử nghiệm được viết sau mã sản xuất. Và nếu bạn không thể tin tưởng vào các bài kiểm tra tự động của mình, chúng không có giá trị gì . Theo chu trình TDD, trước tiên bạn phải thực hiện một thử nghiệm thất bại (vì lý do đúng) để được phép viết mã sản xuất để vượt qua (và không còn nữa). Quá trình này về cơ bản là kiểm tra các bài kiểm tra của bạn, vì vậy bạn có thể tin tưởng chúng. Chưa kể đến việc viết các bài kiểm tra trước khi mã thực tế thúc đẩy bạn thiết kế các đơn vị và các thành phần của mình để dễ kiểm tra hơn (mức độ tách rời cao, áp dụng SRP, v.v ...). Mặc dù, tất nhiên, làm TDD có kỷ luật .

Thay vào đó, nếu bạn viết tất cả mã sản xuất trước, khi bạn viết các bài kiểm tra cho nó, bạn sẽ mong chúng vượt qua ở lần chạy đầu tiên. Điều này rất có vấn đề, bởi vì bạn có thể đã tạo một thử nghiệm bao gồm 100% mã sản xuất của bạn, mà không xác nhận hành vi chính xác (thậm chí có thể không thực hiện bất kỳ xác nhận nào! Tôi đã thấy điều này xảy ra ), vì bạn không thể thấy nó thất bại đầu tiên để kiểm tra nếu nó không đúng lý do. Vì vậy, bạn có thể có dương tính giả. Kết quả dương tính giả cuối cùng sẽ phá vỡ niềm tin vào bộ thử nghiệm của bạn, về cơ bản buộc mọi người phải dùng đến thử nghiệm thủ công một lần nữa, do đó bạn có chi phí cho cả hai quy trình (viết thử nghiệm + kiểm tra thủ công).

Điều này có nghĩa là bạn phải tìm một cách khác để kiểm tra các bài kiểm tra của mình , giống như TDD. Vì vậy, bạn dùng đến việc gỡ lỗi, bình luận các phần của mã sản xuất, v.v., để có thể tin tưởng vào các bài kiểm tra. Vấn đề là quá trình "kiểm tra bài kiểm tra của bạn" chậm hơn nhiều theo cách này. Thêm thời gian này vào thời gian bạn sẽ sử dụng để chạy thử nghiệm đặc biệt theo cách thủ công (vì bạn không có kiểm tra tự động trong khi bạn đang mã hóa mã sản xuất), theo kinh nghiệm của tôi, kết quả là một quá trình tổng thể chậm hơn nhiều so với thực hành TDD "theo cuốn sách" (Kent Beck - TDD bằng ví dụ). Ngoài ra, tôi sẵn sàng đặt cược ở đây và nói rằng thực sự "kiểm tra bài kiểm tra của bạn" sau khi chúng được viết cần nhiều kỷ luật hơn TDD.

Vì vậy, có thể nhóm của bạn có thể xem xét lại "lý do kinh doanh và phi kinh doanh" vì không làm TDD. Theo kinh nghiệm của tôi, mọi người có xu hướng nghĩ TDD chậm hơn so với việc chỉ viết các bài kiểm tra đơn vị sau khi mã được thực hiện. Giả định này là thiếu sót, như bạn đã đọc ở trên.

Thông thường chất lượng của các xét nghiệm phụ thuộc vào xuất xứ của họ. Tôi thường xuyên phạm tội vì không thực hiện TDD 'thực' - Tôi viết một số mã để chứng minh rằng chiến lược tôi muốn sử dụng thực sự có hiệu quả, sau đó đề cập đến từng trường hợp mã có nghĩa là hỗ trợ cho các thử nghiệm sau đó. Thông thường đơn vị mã là một lớp, để cung cấp cho bạn một ý tưởng chung về số lượng công việc tôi sẽ vui vẻ làm mà không có phạm vi kiểm tra - có nghĩa là, không phải là một số tiền lớn. Điều này có nghĩa là ý nghĩa ngữ nghĩa của các bài kiểm tra phù hợp độc đáo với hệ thống được kiểm tra ở trạng thái 'hoàn thành' - bởi vì tôi đã viết cho họ biết những trường hợp nào mà SUT đáp ứng và cách nó hoàn thành chúng.

Ngược lại, TDD với chính sách tái cấu trúc mạnh mẽ có xu hướng lỗi thời các bài kiểm tra ít nhất là nhanh như bạn có thể viết chúng dưới dạng giao diện chung của hệ thống khi thay đổi kiểm tra. Cá nhân tôi thấy khối lượng công việc tinh thần của cả việc thiết kế các đơn vị chức năng của ứng dụng và giữ cho ngữ nghĩa của các bài kiểm tra bao gồm nó quá cao để duy trì sự tập trung của tôi và bảo trì kiểm tra thường xuyên bị trượt. Các cơ sở mã kết thúc với các thử nghiệm treo xung quanh mà không kiểm tra bất cứ thứ gì có giá trị hoặc hoàn toàn sai. Nếu bạn có kỷ luật và năng lực tinh thần để luôn cập nhật bộ kiểm tra, hãy luyện tập TDD một cách nghiêm ngặt như bạn muốn. Tôi không, vì vậy tôi thấy nó ít thành công hơn vì lý do đó.

Thật ra chú Bob đã đề cập đến một điểm rất thú vị trong một trong những video Clean Coders của mình. Ông nói rằng chu trình Red-Green-Refactor có thể được áp dụng theo 2 cách.

1 là cách TDD thông thường. Viết một bài kiểm tra thất bại sau đó thực hiện bài kiểm tra vượt qua và cuối cùng là cấu trúc lại.

Cách thứ 2 là viết một đoạn mã sản xuất rất nhỏ và ngay lập tức làm theo bằng cách kiểm tra đơn vị của nó sau đó tái cấu trúc.

Ý tưởng là đi trong các bước rất nhỏ . Tất nhiên bạn mất xác minh từ mã sản xuất rằng thử nghiệm của bạn chuyển từ màu đỏ sang màu xanh lá cây, nhưng trong một số trường hợp tôi làm việc chủ yếu với các nhà phát triển cơ sở, những người đã từ chối thậm chí cố gắng hiểu TDD, điều đó tỏ ra có hiệu quả.

Một lần nữa tôi nhắc lại (và điều này đã được chú Bob nhấn mạnh) ý tưởng là đi theo những bước rất nhỏ và ngay lập tức kiểm tra đoạn mã sản xuất vừa được thêm vào.