Có thực sự đáng để kiểm tra đơn vị một ứng dụng API không?


38

Đây là một cái gì đó đã gây phiền toái cho tôi trong một thời gian. Có thực sự đáng để kiểm tra đơn vị một ứng dụng API không?

Giả sử bạn đang tạo một lớp nhỏ để loại bỏ các cuộc gọi đến API REST của pethop. Pethop là một API rất đơn giản và nó có một bộ phương thức cơ bản:

  • listProducts()
  • getProductDetails(ProductID)
  • addProduct(...)
  • removeProduct(ProductID)

Để kiểm tra điều này, chúng tôi phải tạo ra một dịch vụ giả hoặc giả các câu trả lời. Nhưng điều đó dường như quá mức cần thiết; Tôi hiểu rằng chúng tôi muốn đảm bảo rằng các phương thức của chúng tôi không ngừng hoạt động thông qua lỗi chính tả / cú pháp, nhưng vì chúng tôi đang viết các hàm gọi các phương thức từ xa và sau đó chúng tôi đang tạo phản hồi giả từ các phương thức từ xa đó, có vẻ như lãng phí công sức và chúng tôi đang thử nghiệm thứ gì đó thực sự không thể thất bại. Tệ hơn, nếu phương thức từ xa thay đổi, các bài kiểm tra đơn vị của chúng tôi sẽ vượt qua trong khi việc sử dụng sản xuất không thành công.

Tôi khá chắc chắn rằng tôi đang thiếu một cái gì đó, hoặc tôi đã kết thúc sai cây gậy, hoặc tôi không nhìn thấy gỗ cho cây. Ai đó có thể đặt tôi đi đúng hướng?


1
Nếu đây không phải là một API đơn giản như vậy với các phương thức cơ bản, bạn có cảm thấy khác không? Ngay cả một nhà kho phải đứng lên tuyết.
JeffO

Câu trả lời:


31

Công việc của máy khách API từ xa là đưa ra các cuộc gọi nhất định - không hơn, không kém. Do đó, thử nghiệm của nó nên xác minh rằng nó phát hành các cuộc gọi đó - không hơn, không kém.

Chắc chắn, nếu nhà cung cấp API thay đổi ngữ nghĩa của các phản hồi của họ, thì hệ thống của bạn sẽ thất bại trong sản xuất. Nhưng đó không phải là lỗi của lớp khách hàng của bạn; đó là thứ chỉ có thể bắt gặp trong các bài kiểm tra tích hợp. Bằng cách dựa vào mã không thuộc quyền kiểm soát của bạn, bạn đã từ bỏ khả năng xác minh tính chính xác thông qua thử nghiệm nội bộ - đó là một sự đánh đổi và đây là giá.

Điều đó nói rằng, kiểm tra một lớp chỉ bao gồm các phái đoàn đến một lớp khác có thể có mức độ ưu tiên thấp, bởi vì có rất ít rủi ro về các lỗi phức tạp. Nhưng điều đó đúng với bất kỳ lớp nào chỉ bao gồm các lớp lót đồng nhất, nó không liên quan gì đến việc gọi ra mã của nhà cung cấp khác.


Mmm, không chắc chắn tôi đồng ý. Bạn có thể kiểm tra cái foo()được gọi trước đó bar(), nhưng điều đó không có nghĩa là gọi foo()trước bar()là điều nên làm; một bài kiểm tra đơn vị như thế sẽ vượt qua ngay cả khi mã sai. Và nếu đó là tất cả các ứng dụng khách đang thực hiện, việc thiết lập các giả lập để kiểm tra xem có foo()được gọi trước hay không bar()tương đối rắc rối đối với một cái gì đó có thể được xác minh bằng một cái nhìn lướt qua mã máy khách.
Doval

1
Bạn có thể kiểm tra rằng một add()phương thức thêm hai số chính xác, nhưng điều đó không có nghĩa là thêm vào là điều đúng đắn tại thời điểm này trong thuật toán - add()kiểm tra đơn vị sẽ thành công mặc dù chương trình của bạn sai. Nếu đó điều sai, thì levenshteinDistance()phương pháp của bạn là đổ lỗi, không phải add()phương pháp. Điều này là hoàn toàn giống nhau. Điểm có mã được phân tách thành các phương thức luôn là mỗi phương thức chỉ phải quan tâm đến việc lấy một thứ đúng.
Kilian Foth

3
Bây giờ tôi thấy nơi chúng tôi không đồng ý! Nếu bạn dựa vào một cửa hàng thú cưng bên ngoài, với tôi điều này có nghĩa là hệ thống của bạn kết thúc ở ranh giới HTTP, do đó các lệnh gọi REST được phát hành đầu ra và phải thử nghiệm. Nếu bạn xem xét phần cửa hàng thú cưng của mô-đun này, thì có, mẫu cuộc gọi được phát hành là một chi tiết triển khai và thử nghiệm đơn vị không có doanh nghiệp quy định bất cứ điều gì về chúng.
Kilian Foth

2
"Do đó, thử nghiệm của nó sẽ xác minh rằng nó đưa ra các cuộc gọi đó" Tôi nghĩ đó là viễn cảnh mà tôi đã không nhìn thấy. Cảm ơn!
Phillip B Oldham

1
Vì vậy, ví dụ kiểm tra đơn vị của tôi có thể kiểm tra xem, với các tham số nhất định, phần thân của yêu cầu mà nó thực hiện có đúng không?
Maria Ines Parnisari

9

Câu trả lời ngắn:

Tất cả các phương pháp nên được kiểm tra đơn vị.

Câu trả lời dài:

Vâng. Đó là giá trị nó.

Đây là một số điều kiểm tra đơn vị trên các phương thức gọi API đó nên kiểm tra:

  • Rằng bạn đang chuyển các tham số được định dạng đúng hoặc chính xác cho các lệnh gọi API.
  • Rằng bạn đang phản hồi tương ứng với một số loại dữ liệu được API trả về (giả định hoặc không), ví dụ có thể khi API trả về một chuỗi trống, phương thức của bạn sẽ trả về giá trị mặc định (chỉ là một ví dụ)
  • Phương thức người gọi hành xử đúng khi các lệnh gọi API tạo ra lỗi

Đó là những điều mà phương thức được gọi có thể tách rời khỏi việc tôi chế nhạo dịch vụ API và bằng cách kiểm tra chúng tốt, đảm bảo với bạn rằng các lỗi không bắt nguồn từ lỗi trong mã máy khách gọi API.


Bạn nói "bị chế giễu hay không" ... vậy có ổn không khi kiểm tra API thực sự? Tôi có thể gọi nó là một bài kiểm tra tích hợp mặc dù nó trông giống như Bài kiểm tra đơn vị không? Hoặc có một điều khác để gọi này? Tôi muốn kiểm tra xem trình bao bọc API của tôi có thực hiện những gì nó nói hay không, bằng cách nào đó ...
Dan Rosenstark

1
@DanRosenstark Tôi đoán trong trường hợp dịch vụ API không bị chế giễu, đó là một thử nghiệm tích hợp.
Tulains Córdova

Bạn có biết sau 5 giây nếu bạn nhận được dữ liệu đúng khi bạn thực hiện cuộc gọi thực tế tới API không? Vì các giả lập API không phải là cuộc gọi thực, cách duy nhất chúng sẽ thất bại là nếu chúng thay đổi API ... trong trường hợp đó, các thử nghiệm giả của bạn sẽ vượt qua nhưng các cuộc gọi thực sẽ thất bại. Có vẻ vô nghĩa
MattE

5

Đây không phải là kiểm tra đơn vị vì bạn đang kiểm tra đầu vào và đầu ra của hệ thống, giống như các thử nghiệm tích hợp hạn chế.

Hãy thận trọng khi bạn nói "có vẻ như lãng phí công sức và chúng tôi đang thử nghiệm thứ gì đó không thể thực sự thất bại" - nó có thể thất bại, nó sẽ thất bại, nó có thể thất bại theo những cách mà bạn không thể lường trước được, thất bại sẽ tồi tệ hơn nếu bạn không có bài kiểm tra tại chỗ.

Sai lầm bạn đang mắc phải ở đây là phát minh ra các bánh xe: Thực hiện cuộc gọi đến các dịch vụ và API từ xa là một tình huống rất phổ biến vì vậy có một số công cụ khá tốt để giúp bạn kiểm tra điều đó. Lần trước tôi đang làm việc trên một ứng dụng kết nối với các dịch vụ từ xa, tôi đã sử dụng SoapUIcó thể xem xét một dịch vụ và thực hiện các cuộc gọi giả đến dịch vụ đó hoặc hoạt động như một bản sao cục bộ của máy chủ mà bạn có thể thực hiện các cuộc gọi thử nghiệm và theo dõi các yêu cầu và phản hồi. Phải mất vài phút để thiết lập và tương tự như vậy là rất nhanh để cập nhật nếu giao diện từ xa thay đổi. Tôi đã không sử dụng nó trong kịch bản REST, nhưng ngay cả khi nó không hoạt động tốt cho điều đó (hoặc có lẽ ai đó đang đọc câu trả lời này trong tương lai khi có công cụ tốt hơn), bạn vẫn có thể tìm thấy một công cụ có thể giả lập một dịch vụ cho bạn và khi đến lúc triển khai mã của bạn, bạn sẽ rất vui vì bạn đã làm.

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.