Tôi có cần kiểm tra đơn vị nếu tôi đã có kiểm tra tích hợp không?

Nếu tôi đã có bài kiểm tra tích hợp cho chương trình của mình và tất cả đều vượt qua, thì tôi có cảm giác tốt rằng nó sẽ hoạt động. Sau đó, những lý do để viết / thêm bài kiểm tra đơn vị là gì? Vì dù sao tôi cũng đã phải viết các bài kiểm tra tích hợp, tôi chỉ muốn viết bài kiểm tra đơn vị cho các phần không nằm trong các bài kiểm tra tích hợp.

Những gì tôi biết lợi ích của kiểm tra đơn vị so với kiểm tra tích hợp là

• Nhỏ và do đó chạy nhanh (nhưng thêm đơn vị mới để kiểm tra thứ gì đó đã được kiểm tra bằng thử nghiệm tích hợp có nghĩa là tổng số bộ thử nghiệm của tôi sẽ lớn hơn và dài hơn để chạy)
• Xác định vị trí lỗi dễ dàng hơn vì nó chỉ kiểm tra một thứ (nhưng tôi có thể bắt đầu viết kiểm tra đơn vị để xác minh từng phần riêng lẻ khi kiểm tra tích hợp của tôi không thành công)
• Tìm lỗi có thể không bị bắt trong kiểm tra tích hợp. ví dụ: che giấu / bù đắp lỗi. (nhưng nếu tích hợp của tôi kiểm tra tất cả các lần vượt qua, điều đó có nghĩa là chương trình của tôi sẽ hoạt động ngay cả một số lỗi ẩn tồn tại. Vì vậy, tìm / sửa các lỗi này không thực sự ưu tiên cao trừ khi chúng bắt đầu phá vỡ các kiểm tra tích hợp trong tương lai hoặc gây ra vấn đề về hiệu năng)

Và chúng tôi luôn muốn viết ít mã hơn, nhưng viết các bài kiểm tra đơn vị cần nhiều mã hơn (chủ yếu là thiết lập các đối tượng giả). Sự khác biệt giữa một số bài kiểm tra đơn vị của tôi và kiểm tra tích hợp là trong các bài kiểm tra đơn vị, tôi sử dụng đối tượng giả và trong các bài kiểm tra tích hợp, tôi sử dụng đối tượng thực. Có nhiều sự trùng lặp và tôi không thích mã trùng lặp, ngay cả trong các thử nghiệm vì điều này thêm chi phí để thay đổi hành vi mã (công cụ tái cấu trúc không thể làm tất cả công việc mọi lúc).

Bạn đã đưa ra các lập luận tốt cho và chống lại thử nghiệm đơn vị. Vì vậy, bạn phải tự hỏi : " Tôi có thấy giá trị trong các lý lẽ tích cực vượt xa chi phí trong các tiêu cực không? " Tôi chắc chắn làm:

• Nhỏ và nhanh là một khía cạnh tốt đẹp của thử nghiệm đơn vị, mặc dù không có nghĩa là quan trọng nhất.
• Định vị-bug [s] -easier là vô cùng quý giá. Nhiều nghiên cứu về phát triển phần mềm chuyên nghiệp đã chỉ ra rằng chi phí của một lỗi tăng lên nhanh chóng khi nó già đi và chuyển xuống đường ống phân phối phần mềm.
• Tìm kiếm-mặt nạ-lỗi là có giá trị. Khi bạn biết rằng một thành phần cụ thể có tất cả các hành vi của nó được xác minh, bạn có thể sử dụng nó theo cách mà trước đây nó không được sử dụng, với sự tự tin. Nếu xác minh duy nhất là thông qua kiểm tra tích hợp, bạn chỉ biết rằng việc sử dụng hiện tại của nó hoạt động chính xác.
• Mocking là tốn kém trong các trường hợp thực tế, và duy trì giả là gấp đôi như vậy. Trong thực tế, khi chế nhạo các đối tượng hoặc giao diện "thú vị", bạn thậm chí có thể cần các bài kiểm tra xác minh rằng các đối tượng giả của bạn mô hình chính xác các đối tượng thực của bạn!

Trong cuốn sách của tôi, những ưu điểm vượt trội hơn những nhược điểm.

Tôi không thấy nhiều giá trị trong việc thực hiện lại một testcase tích hợp hiện có là không đáng tin cậy.

Các kiểm tra tích hợp thường dễ dàng hơn nhiều để viết cho các ứng dụng kế thừa không phải vì thường các chức năng cần kiểm tra được kết hợp chặt chẽ để các đơn vị kiểm tra cách ly (= không đáng tin) có thể bị phân tán / tốn kém / không thể.

> Then what are the reasons to write/add unit tests?

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.

Kiểm tra tích hợp chỉ nên xác minh rằng một số thành phần đang hoạt động cùng nhau như mong đợi. Việc logic của các thành phần riêng lẻ có chính xác hay không nên được xác minh bằng các thử nghiệm đơn vị.
Hầu hết các phương thức có một số đường dẫn thực thi có thể; nghĩ về if-then-other, các biến đầu vào có giá trị sai bất ngờ hoặc đơn giản, v.v. Thông thường các nhà phát triển có xu hướng chỉ nghĩ về đường dẫn hạnh phúc: đường dẫn bình thường không sai. Nhưng theo như những đường dẫn khác có liên quan, bạn có hai tùy chọn: bạn có thể cho phép người dùng cuối khám phá những đường dẫn đó thông qua các hành động họ thực hiện trong UI và hy vọng họ không làm hỏng ứng dụng của bạn hoặc bạn có thể viết bài kiểm tra đơn vị khẳng định hành vi của những con đường khác và hành động khi cần thiết.

Một số lý do bạn đã chỉ ra trong câu hỏi của mình thực sự quan trọng và bản thân họ rất có thể đưa ra trường hợp có lợi cho thử nghiệm đơn vị, nhưng YMMV. Chẳng hạn, bạn có thường xuyên chạy bộ kiểm thử tích hợp của mình không? Kinh nghiệm của tôi với các bài kiểm tra tích hợp là sớm hay muộn chúng sẽ chậm đến mức bạn sẽ không chạy chúng mỗi khi bạn thực hiện thay đổi và thời gian giữa việc chèn và phát hiện lỗi sẽ tăng lên.

Ngoài ra, một sai lầm lớn bạn có thể mắc phải là tin tưởng rằng

Find bug that may not be caught in integration test. e.g. masking/offsetting bugs.

không quan trọng. Bạn có mong đợi rằng người dùng của bạn tìm thấy các lỗi cho bạn? Theo tôi, bảo hiểm thu được từ các bài kiểm tra tích hợp rất nguy hiểm, bạn có thể dễ dàng nhận được phần trăm bảo hiểm cao nhưng thực tế bạn đang kiểm tra rất ít.

Tôi đoán tài liệu tham khảo chính tắc chống lại các bài kiểm tra tích hợp là bài đăng của JBrains:

http://www.jbrains.ca/permalink/integrated-tests-are-a-scam-part-1

trong trường hợp bạn chưa đọc chúng.

Cuối cùng, IMO phản hồi bạn có thể nhận được từ các bài kiểm tra đơn vị cho thiết kế của bạn là vô giá. Đánh giá một thiết kế bằng cảm giác ruột và dựa vào các bài kiểm tra tích hợp cũng có thể là một sai lầm.

Nếu bạn muốn phải sửa đổi hoặc cấu trúc lại mã của mình, việc kiểm tra đơn vị là điều cần thiết. Các thử nghiệm đơn vị tồn tại không chỉ để chứng minh các lỗi tại thời điểm mã được viết, mà còn hiển thị khi các lỗi mới xuất hiện khi có nhiều mã được viết.

Vâng, tốt hơn hết là viết bài kiểm tra tích hợp và đơn vị của bạn trước, nhưng sẽ có rất nhiều giá trị để có chúng ngay cả khi chúng được viết sau.