Là một nhà phát triển chuyên nghiệp, có thể chấp nhận không viết bài kiểm tra đơn vị không? [đóng cửa]

Chỉ cần tự hỏi về những ưu và nhược điểm của TDD / thử nghiệm đơn vị tự động và tìm kiếm quan điểm của cộng đồng về việc liệu các nhà phát triển chuyên nghiệp có thể viết ứng dụng mà không cần hỗ trợ thử nghiệm đơn vị không?

Để kiểm tra cái gì?

Nếu bạn đang nói về bảo hiểm mã 100%, nó cực kỳ hiếm, không hữu ích và thường là không thể. Theo cách tương tự, kiểm tra mã liên quan đến CRUD là một sự lãng phí thời gian và sẽ rất không chuyên nghiệp khi dành hàng giờ để viết mã mà bạn không cần thay vì làm điều gì đó thực sự hữu ích.

Bây giờ, là một nhà phát triển, bạn phải biết cách viết bài kiểm tra đơn vị và bạn cần chúng ở đâu.

Học thuyết

Có một quan niệm sai lầm phổ biến rằng các bài kiểm tra đơn vị là để kiểm tra "đơn vị" .
Kiểm tra đơn vị, tương tự như tất cả các kiểm tra khác, chức năng kiểm tra . Đơn giản là không có gì khác có thể được kiểm tra.

Tuy nhiên, chức năng của một hệ thống phức tạp thường không thể được kiểm tra một cách hiệu quả.
Giả sử, người dùng nhấn nút "Xóa" và không có gì xảy ra. Tại sao? Một lỗi có thể nằm trong cơ sở dữ liệu, kết nối có thể bị hỏng, logic lõi có thể bị trục trặc hoặc thậm chí một thao tác có thể thành công nhưng giao diện không được cập nhật đúng. Mỗi lớp có thể chứa nhiều hàm gọi nhau và không phải lúc nào cũng rõ lỗi ở đâu.
Các thử nghiệm đơn vị dựa trên mô hình tách các thành phần và thử nghiệm chúng riêng lẻ.

Một lần nữa, nó không đảm bảo toàn bộ hệ thống sẽ hoạt động, nhưng nó đơn giản hóa việc kiểm tra.

TDD không phải là một yêu cầu của chính nó. Nó đơn giản hóa mã hóa bằng cách buộc một nhà phát triển trả lời trước, "tôi thực sự sẽ viết mã gì?".

Chi phí

Nhiều người nghĩ rằng bằng cách không viết bài kiểm tra, họ tiết kiệm thời gian của họ. Sai lầm. Suy nghĩ chiến lược, chi phí của một lỗi tăng theo cấp số nhân theo thời gian kể từ khi xuất hiện cho đến khi phát hiện.

Giả sử bạn mắc lỗi trong mã của mình và phát hiện và sửa nó cùng ngày. Chi phí là $ X .
Giả sử lỗi vẫn không bị phát hiện và chuyển sang xây dựng nội bộ hàng tuần. May mắn thay, QA đã phát hiện ra nó, đưa ra một lỗi trong trình theo dõi lỗi, vấn đề là một chủ đề thảo luận dài 5 phút trong cuộc họp của 5 người, v.v ... Cuối cùng, bạn đã sửa nó. Chi phí là tổng số nhân lực mà mọi người bỏ ra và có thể là $ 3 * X trong trường hợp này.
Điều gì xảy ra nếu lỗi đã đến bản thử nghiệm beta và liên quan đến nhiều người hơn? Hãy nói rằng, $ 10 * X .
Nếu nó không bị phát hiện trong một thời gian dài, đã có tới 1.000 khách hàng (hy vọng, không đến một triệu!), 10 người trong số họ đã phát hiện ra, họ đã thảo luận với nhân viên hỗ trợ của bạn, một số người có thể gọi cho sếp của bạn, đồng đội của bạn cố gắng tái tạo nó , v.v. Cuối cùng, lỗi trở lại với bạn và bạn sửa nó. Bao nhiêu, tổng cộng? Vâng hơn $ 50 * X .

Như bạn thấy, một lỗi sẽ sớm trở lại với bạn (hoặc đồng nghiệp của bạn). Sự khác biệt duy nhất là khi nó xảy ra và nó sẽ có giá bao nhiêu.
Các thử nghiệm đơn vị rút ngắn vòng đời của các lỗi và do đó giảm chi phí.

Chuyên nghiệp

• Kiểm tra đơn vị cho phép các nhà phát triển để mã tốt hơn . Đơn giản vậy thôi.
• Họ để tiết kiệm thời gian của bạn;
• Họ giảm chi phí;
• Các bài kiểm tra đơn vị sống cùng với mã họ kiểm tra. Theo bất kỳ yêu cầu thay đổi nào (xảy ra mọi lúc), các bài kiểm tra sẽ thích nghi.

Con

Tôi có thể thấy một lý do duy nhất để không viết bài kiểm tra. Nếu bạn đang viết một nguyên mẫu, ví dụ như một cái gì đó sẽ không bao giờ đi đến những người khác. Hoặc có thể bạn đang viết một cái gì đó cho một lần sử dụng.

Chắc chắn, không thể chấp nhận viết các bài kiểm tra đơn vị cho các tiện ích trợ giúp nội bộ nhỏ, hoặc các công cụ kiểm tra hoặc các tình huống trong đó doanh nghiệp thực sự cần những thứ khác ngoài chất lượng và bạn là nhà phát triển chuyên nghiệp thấy rằng bạn có thể hoàn thành và làm việc nhanh chóng không có.

Theo kinh nghiệm của tôi, 95% lỗi có thể bị bắt bởi các bài kiểm tra đơn vị đến từ các cuộc gọi đến lớp dữ liệu, đặc biệt là sau khi thay đổi thiết kế cơ sở dữ liệu. Nếu bạn đang sử dụng cơ sở dữ liệu, chỉ cần kiểm tra mọi phương pháp bạn sử dụng để truy cập cơ sở dữ liệu. Các xét nghiệm thậm chí không cần phải xây dựng, chỉ cần kiểm tra độ tỉnh táo.

Để trả lời câu hỏi của bạn - nếu bạn truy cập cơ sở dữ liệu và bạn là nhà phát triển chuyên nghiệp, bạn nên sử dụng các bài kiểm tra đơn vị. Nếu không, nó phụ thuộc.

Nó thực sự phụ thuộc vào cách ứng dụng sẽ được sử dụng. Đây có phải là một ứng dụng quan trọng? Hoặc nó là một ứng dụng xác minh đơn giản chỉ được sử dụng bởi các nhà phát triển nội bộ? Khi làm việc trên các ứng dụng cốt lõi cho công ty của bạn, cần có càng nhiều bài kiểm tra đơn vị càng cần thiết để đảm bảo các quyết định kinh doanh được bảo hiểm. Tùy thuộc vào công ty của bạn, đó là những ứng dụng khách hàng nhìn thấy và lỗi có thể làm mất tiền. Khi được thực hiện tốt, các bài kiểm tra đơn vị có thể là một trợ giúp lớn để đảm bảo các ứng dụng của bạn sẽ hoạt động khi được triển khai. Nhưng nó không phải là một phương pháp chữa bệnh tất cả và thử nghiệm của con người vẫn nên được thực hiện. Các ứng dụng nội bộ đơn giản (hoặc phụ trợ) không cần kiểm tra đơn vị, nhưng vẫn nên được viết tốt.

TDD không chỉ là về viết bài kiểm tra đầu tiên. Đó là về việc đảm bảo mã của bạn có thể dễ dàng kiểm tra. Và thường xuyên hơn không dễ kiểm tra mã cũng dễ đọc / gỡ lỗi / bảo trì hơn. Mã thường xuyên hơn không dễ kiểm tra cũng tuân theo các mẫu và nguyên tắc OO như RẮN. Tôi sẽ tranh luận như là một nhà phát triển chuyên nghiệp, mã của bạn phải luôn được viết theo cách đó.

Bạn chắc chắn không muốn "không thử nghiệm". Nếu bạn viết bài kiểm tra đơn vị, bạn đã đảm bảo ít nhất một số đảm bảo rằng mã của bạn khớp với các bài kiểm tra của bạn (mặc dù bạn cần đảm bảo rằng các bài kiểm tra của mình phù hợp với đặc điểm kỹ thuật của bạn).

Bạn chưa hoàn thành nếu tất cả những gì bạn có là bài kiểm tra đơn vị. Bạn có thể vẫn cần thực hiện các bài kiểm tra tích hợp và kiểm tra đầu cuối (và theo thời gian tích lũy các trường hợp kiểm tra để bắt hồi quy lỗi).

Tôi sẽ đi ra ngoài ở đây và nói rằng nó chủ yếu là chủ quan và phụ thuộc vào mục tiêu của bạn. tl; dnr: Thật tốt khi làm điều đó, nhưng việc giáo điều về nó sẽ dẫn đến nhiều vấn đề hơn.

Các bài kiểm tra TDD / Đơn vị sẽ cải thiện tính ổn định của mã của bạn. Chúng giúp thực hiện các thay đổi dễ dàng hơn mà không cần biết cơ sở mã thực sự tốt, chúng cho phép bạn cấu trúc lại nhanh hơn, chúng cho bạn chắc chắn rằng bạn không làm điều gì ngớ ngẩn. Kiểm tra đơn vị cũng có thể là một sự lãng phí thời gian. Thời gian có thể được dành để viết mã. Nó cũng có thể cho phép bạn tự lừa mình khi nghĩ rằng mã của bạn hoạt động khi nó không hoạt động nếu bạn theo dõi chúng một cách mù quáng.

Nếu bạn đang làm việc cho một công ty hỗ trợ thực tiễn tốt nhất và cho bạn thời gian để thực hiện chúng và bạn muốn một ứng dụng sẽ tồn tại, thì thực sự tốt nhất cho mọi người sử dụng và thực hành kiểm tra đơn vị và đánh giá mã. Có một nhóm QA có thể là một sự thay thế chấp nhận được nếu các nhà phát triển không lạm dụng nó. Nếu bạn đang viết một nguyên mẫu (thậm chí là sản xuất), có thể nhanh hơn chỉ cần thực hiện các thử nghiệm khói.

Nếu bạn đang làm việc trên một cái gì đó mà một mớ hỗn độn sẽ không thể kết thúc trên thế giới, thì phạm vi bảo hiểm ít hơn có lẽ là tốt. Giao dịch tài chính? Rất nhiều. Nếu bạn có một nhóm các nhà phát triển mạnh, biết codebase, làm việc tốt với nhau và không có doanh thu, thì có lẽ bạn cần bảo hiểm ít hơn. Vân vân.

Vì vậy, nó có thể sẽ là một số chức năng của

• Quy mô đội / doanh thu
• Thời hạn sử dụng mong muốn của ứng dụng
• Ứng dụng và sự thất bại nghiêm trọng như thế nào
• Thời gian cung cấp để thực hiện các thực tiễn tốt nhất liên quan đến lịch trình phát triển
• Năng khiếu nhóm (điều này không có nghĩa là trở thành một lập trình viên giỏi có nghĩa là bạn không nên viết bài kiểm tra đơn vị, nhưng một nhóm không có nhà phát triển cơ sở có thể bay qua chỗ ngồi của quần với nhiều thành công hơn)

Có rất nhiều tình huống mà không viết bài kiểm tra đơn vị sẽ được chấp nhận. TDD là 'trong' ngay bây giờ, nhưng nó không phải là một viên đạn bạc.

Thật là chuyên nghiệp khi viết các bài kiểm tra đơn vị duy trì sẽ giúp bạn tiết kiệm thời gian và nước mắt!

Có một misconception that Unit test finds bugs. Vâng, điều đó chỉ đơn giản là KHÔNG đúng với mọi trường hợp. Kiểm thử đơn vị không phải là tìm lỗi hoặc phát hiện hồi quy. Đó là theo định nghĩa examine each unit of your code separately,. Nhưng khi ứng dụng của bạn chạy thực sự, tất cả các đơn vị đó phải làm việc cùng nhau, và toàn bộ phức tạp và tinh tế hơn so với tổng số các phần được kiểm tra độc lập.

Do đó, mục tiêu của kiểm thử đơn vị (trong quy trình TDD) là thiết kế mạnh mẽ các thành phần phần mềm.

Chỉnh sửa: Có một ngoại lệ trong đó các bài kiểm tra đơn vị thực sự phát hiện lỗi. Đó là khi bạn tái cấu trúc hoặc tái cấu trúc mã của một đơn vị nhưng không có ý nghĩa thay đổi hành vi của đơn vị đó. Trong trường hợp này, kiểm tra đơn vị thường có thể cho bạn biết nếu hành vi của đơn vị đã thay đổi.

Là một nhà phát triển chuyên nghiệp, có thể chấp nhận không viết bài kiểm tra đơn vị không?

Không.

Không có câu hỏi - Đây phải là một trong những bài học đầu tiên mà một người mới học được. Bạn phải phát triển các thử nghiệm đơn vị để chứng minh rằng mã của bạn hoạt động trước khi bạn nói với QA rằng mã của bạn đã sẵn sàng để thử nghiệm. Một thất bại để làm như vậy sẽ làm tăng chi phí cho dự án và làm giảm tinh thần nhóm.

Làm thế nào triệt để các bài kiểm tra đơn vị nên được?

Dưới đây là bài kiểm tra litmus: Nếu QA phát hiện ra lỗi trong mã của bạn, bạn có cảm thấy thoải mái khi sử dụng (các) bài kiểm tra đơn vị của mình để chứng minh sự siêng năng của mình với sếp không?

Nếu câu trả lời của bạn là 'Không', thì bạn nên tạo một bài kiểm tra đơn vị tốt hơn (hoặc bài kiểm tra).
Nếu câu trả lời của bạn là 'Có', thì mã của bạn đã sẵn sàng để xác minh.

Là một nhà phát triển chuyên nghiệp, có thể chấp nhận không viết các bài kiểm tra đơn vị tự động không?

Đúng.

Đặc biệt nếu thời gian và công sức dành cho việc viết bài kiểm tra đơn vị tự động sẽ lớn hơn lợi ích đạt được từ bài kiểm tra. Điều này bao gồm, nhưng không bị giới hạn, mã UI có thể khó giả định.

Nhấn mạnh: Tôi không nói rằng không thể viết các bài kiểm tra đơn vị tự động cho mã UI. Tôi chỉ nói rằng, theo kinh nghiệm của tôi, đôi khi rất khó để viết các bài kiểm tra đơn vị tự động cho một số mã UI.