Tôi có nên kiểm tra đơn vị


8

Hầu hết logic cho dịch vụ web của tôi liên quan đến việc nói chuyện với dịch vụ web của nhà cung cấp của chúng tôi (kiểm tra tính khả dụng, đặt hàng, v.v.) Họ không có môi trường thử nghiệm và phần lớn các cuộc gọi không thể được chạy tùy ý (ví dụ: ngừng hoạt động sẽ được chạy một lần và sẽ thực sự dừng một dịch vụ).

Có khả thi để chạy thử nghiệm đơn vị trong môi trường này? Tôi có thể mô phỏng các phản hồi điển hình nhưng tôi lo lắng rằng các phản hồi của nhà cung cấp mã hóa cứng sẽ làm suy yếu điểm kiểm tra đơn vị.

Câu trả lời:


30

Không, nó sẽ không. Điểm của các bài kiểm tra đơn vị là chính xác để kiểm tra mã của bạn một cách độc lập, độc lập với thế giới bên ngoài.

Kiểm tra toàn bộ hệ thống của bạn tương tác với các bên ngoài như dịch vụ web, v.v. là kiểm tra tích hợp / hệ thống . Điều này cũng cần thiết trong hầu hết các dự án trong thế giới thực, nhưng nó là một cấp độ khác với các bài kiểm tra đơn vị. Trên thực tế có vẻ như trong tình huống của bạn, vì bạn gặp khó khăn trong kiểm tra tích hợp, bạn cần kiểm tra đơn vị thậm chí nhiều hơn bình thường .

Vì mục tiêu dài hạn, bạn có thể xem xét việc giáo dục và / hoặc làm phiền các nhà cung cấp cho biết để thiết lập môi trường thử nghiệm cho chính họ và khách hàng của họ. Mặc dù vậy, bạn có thể cần phải hỗ trợ quản lý của mình để thành công, vì vậy hãy chuẩn bị những thông tin và số liệu khó để thuyết phục họ về giá trị kinh doanh của môi trường thử nghiệm.


12
+1: "bạn cần kiểm tra đơn vị thậm chí nhiều hơn bình thường". Và bạn cần phải chế giễu chính xác yêu cầu / phản hồi của nhà cung cấp, thời gian chờ, lỗi, thông tin xấu và tất cả những điều nhỏ nhặt khác gây ra "vấn đề" trong một ứng dụng như thế này.
S.Lott

1

Kiểm tra đơn vị cũng sẽ cung cấp cho bạn một đặc tả rõ ràng, có thể thực hiện được về hành vi mà bạn mong đợi từ các nhà cung cấp của mình. Điều này có thể sẽ làm cho việc giao tiếp với họ dễ dàng hơn nhiều.

Nếu có một số vấn đề trong tương tác giữa bạn và họ, bạn có thể cung cấp cho họ các bài kiểm tra đơn vị của bạn để nêu rõ hành vi mà mã của bạn mong đợi. Nếu mã của họ không hoạt động giống như cách kiểm tra đơn vị của bạn, thì sự khác biệt thường dễ dàng nhận ra.


Các thử nghiệm như vậy thực sự hữu ích, nhưng thuật ngữ được sử dụng rộng rãi cho các thử nghiệm nàycác thử nghiệm hệ thống / chấp nhận thay vì thử nghiệm đơn vị.
Péter Török

@Josh Peterson Tôi đã có khiếu nại từ "nhà phát triển" của họ trước đây vì tôi chỉ gửi cho họ xml thay vì khám phá nội dung xml. Tôi nghĩ các bài kiểm tra đơn vị sẽ giúp tôi đi rất xa :)
Tom Squires

0

ROI

Đây thực sự là một câu hỏi hoàn vốn đầu tư. Bạn có cảm thấy rằng đầu tư vào các bài kiểm tra đơn vị là giá trị những gì bạn sẽ nhận lại. Cụ thể, mã của bạn được kiểm tra trong sự cô lập . Cũng như tất cả các lợi ích khác của thử nghiệm đơn vị.

Bạn có thể đối chiếu điều này với cách tiếp cận kiểm tra chấp nhận tự động trong đó bạn sẽ nhận được tài khoản kiểm tra từ nhà cung cấp của mình thực sự kiểm tra hệ thống tích hợp với các bài kiểm tra. Là chi phí để làm ATDD có giá trị những gì bạn nhận lại. Cụ thể, thử nghiệm hệ thống nói chung.

Tùy thuộc vào bạn để thực hiện phân tích và tìm hiểu xem bạn có nên thực hiện kiểm tra đơn vị, kiểm tra chấp nhận tự động, cả hai, không, hoặc điều gì khác.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.