Làm thế nào để bạn kiểm tra một chức năng có mục đích duy nhất là truy vấn API bên ngoài, nhưng API sử dụng cú pháp truy vấn phức tạp?


16

Logic thực duy nhất là trong cú pháp truy vấn cho API bên ngoài. Tôi không muốn kiểm tra xem nó có truy vấn api hay không, tôi muốn kiểm tra xem nó có truy vấn nó theo cách mà dữ liệu chính xác sẽ được trả về hay không. Ví dụ: một số mã giả:

function retrieve_related_data(id)
{
  query = "[potentially long, syntactically complex query that
            uses param id to get some data]";
  results = api_wrapper.query(query);
  return results;
}

Một ví dụ cụ thể hơn với API đã tạo:

function retrieveLifeSupportingObjectsWithinRegion(id)
{
  query = "
    within region(" + id + ") as r
    find objects matching hydration>0 and temp_range has 75
    send name, id, relative(position, r)        
  ";
  results = astronomicalObjectApiWrapper.query(query);
  return results;
}

Truy vấn nằm trong một cú pháp tùy chỉnh API và rất phức tạp và có nhiều cách để đạt được kết quả tương tự hoặc tương tự. Mục đích của hàm không phải là lấy dữ liệu được xác định bởi idmà là tìm một tập hợp con của dữ liệu khác dựa trên mối quan hệ mờ với dữ liệu được xác định bởi idđiều đó cũng đáp ứng một vài yêu cầu khác. Các yêu cầu khác luôn giống nhau bất kể idnhưng có thể thay đổi theo thời gian khi hệ thống được sửa đổi. Ví dụ: nếu ví dụ api thêm hỗ trợ cho thông tin trọng lực, chúng tôi có thể muốn thay đổi truy vấn để sử dụng trọng lực để tinh chỉnh kết quả. Hoặc có thể chúng tôi đưa ra một cách hiệu quả hơn để kiểm tra phạm vi tạm thời, nhưng nó không thay đổi kết quả.

Những gì tôi muốn kiểm tra là đối với một đầu vào nhất định id, bộ dữ liệu chính xác được trả về. Tôi muốn kiểm tra điều này để nếu ai đó làm rối truy vấn sao cho nó không còn trả lại dữ liệu chính xác dựa trên idđó sẽ thất bại, nhưng tôi cũng muốn mọi người có thể sửa đổi truy vấn để tinh chỉnh nó mà không cần phải sửa đổi các bài kiểm tra.

Các tùy chọn tôi đã xem xét:

  1. Tôi có thể khai thác api, nhưng điều đó quá đơn giản (kiểm tra xem nó idcó trong truy vấn không và sau đó trả về một tập hợp dữ liệu dự kiến ​​nếu nó là hoặc một tập không mong muốn nếu không), quá dễ vỡ (kiểm tra xem chuỗi truy vấn có chính xác những gì trong hàm) hoặc quá phức tạp (kiểm tra xem truy vấn được sử dụng có đúng về mặt cú pháp không sẽ dẫn đến dữ liệu chính xác được trả về).

  2. Tôi có thể gửi truy vấn đến api thực, nhưng kết quả dự kiến ​​có thể thay đổi theo thời gian khi dữ liệu trong hệ thống bên ngoài thay đổi, nằm ngoài sự kiểm soát của hệ thống kiểm tra.

  3. Tôi có thể xem xét việc thiết lập một bản cài đặt thử nghiệm của api thật để kiểm soát dữ liệu mà nó có, nhưng đó là rất nhiều nỗ lực.

Tôi đang nghiêng về số 2 và làm cho bài kiểm tra tích hợp này không chạy thường xuyên hơn và xem tần suất thay đổi dữ liệu của hệ thống bên ngoài khiến bài kiểm tra bị hỏng. Tôi nghĩ rằng điều đó sẽ đơn giản nhất bây giờ, nhưng tôi tự hỏi liệu có những lựa chọn thay thế mà tôi không nghĩ ra hoặc cách tốt hơn để giải quyết vấn đề này. Lời khuyên nào sẽ được đánh giá cao.


Tôi đã nghĩ về điều này như một bài kiểm tra đơn vị, nhưng có lẽ nó thực sự là một bài kiểm tra tích hợp hoặc một bài kiểm tra chấp nhận cấp thấp?
Joshua Coady

2
Đây có phải là API chỉ đọc không? Hoặc, bạn có thể ghi dữ liệu mà bạn có thể xác minh đáng tin cậy các lần đọc của bạn không?
Svidgen

Câu hỏi này có khác với "cách kiểm tra sql (= cú pháp phức tạp) của tôi trả về dữ liệu Correnct" không? Với cơ sở dữ liệu, bạn thường có một vài bài kiểm tra tích hợp để kiểm tra cú pháp crud-sql và kho lưu trữ bị giả định để xác minh businesslogic
k3b

Câu trả lời:


7

Có vẻ như việc xác thực phản hồi API bên ngoài mà chúng tôi sẽ kiểm tra chức năng của chúng tôi, nhưng điều đó sẽ không hoàn toàn đúng. Bằng cách nào đó, chúng tôi sẽ kiểm tra API bên ngoài và môi trường nơi API đang chạy.

Các thử nghiệm của chúng tôi nên được giải quyết để đảm bảo hành vi dự kiến ​​của mã mà chúng tôi đã viết, chứ không phải do các bên thứ 3 viết.

Ở một mức độ nhất định, chúng tôi phải tin tưởng vào chức năng phù hợp của các API và lib mà chúng tôi dựa vào. Ví dụ: chúng tôi thường không kiểm tra các thành phần khung mà chúng tôi triển khai.

Tại sao tôi nói vậy?

Điều tôi muốn kiểm tra là đối với một id đầu vào đã cho, bộ dữ liệu chính xác được trả về

Điều gì sẽ được thử nghiệm ở đây? Như bạn đã nói, dữ liệu và tính chính xác của nó không nằm trong tầm kiểm soát của chúng tôi, vì vậy chúng tôi sẽ hạn chế sự thành công của giai đoạn thử nghiệm với một tác nhân bên ngoài mà chúng tôi không kiểm soát được. Các thử nghiệm này là một ứng cử viên để trở nên không xác định và dứt khoát, chúng tôi không muốn các loại thử nghiệm này trong đường ống xây dựng của chúng tôi .

Một mối quan tâm khác là xác nhận hợp đồng. Tôi sẽ thấy khá hữu ích khi kiểm tra hợp đồng 1 để đảm bảo rằng việc tích hợp vẫn hoạt động như mong đợi, trước khi phát hành hoặc triển khai.

Tôi muốn kiểm tra điều này để nếu ai đó làm hỏng truy vấn sao cho nó không còn trả lại dữ liệu chính xác dựa trên id thì nó sẽ thất bại

Điều gì xảy ra nếu truy vấn ổn, nhưng dữ liệu bị lỗi do lỗi trong API? Không chỉ dữ liệu nằm ngoài tầm kiểm soát của chúng tôi. Logic cũng vậy.

Thực hiện các thử nghiệm chức năng hoặc thử nghiệm đầu cuối có thể giúp đỡ ở đây. Bạn có thể giải quyết các thử nghiệm này để xác thực các đường dẫn thực thi nhất định để nếu API trả về dữ liệu sai, điều này có thể sẽ gây ra các hành vi và kết quả không mong muốn. Mặt khác, tôi hy vọng API sẽ đưa ra lỗi nếu các truy vấn của tôi có định dạng xấu.

Nhưng tôi cũng muốn mọi người có thể sửa đổi truy vấn để tinh chỉnh nó mà không cần phải sửa đổi thử nghiệm.

Tôi đề nghị thực hiện một công cụ cho mục đích như vậy. Nó có thể đơn giản như:

  • Một lớp chạy như một bài kiểm tra nhưng nó không thuộc về kế hoạch kiểm tra
  • Một kịch bản shell + curl

Hoặc một cái gì đó tinh vi hơn. Ví dụ, một khách hàng độc lập.

Trong mọi trường hợp, chức năng theo câu hỏi, cũng có giá trị hai loại thử nghiệm:

  • Kiểm tra đơn vị. Như bạn đã nói, bạn phải khai thác API bên ngoài, nhưng đó là toàn bộ mục đích của các bài kiểm tra đơn vị. Kiểm tra mã của chúng tôi cô lập các phụ thuộc.

  • Bài kiểm tra tích hợp. Kiểm tra xem mã không chỉ gửi yêu cầu chính xác mà còn xử lý đúng nội dung phản hồi, lỗi, chuyển hướng, v.v. Hãy kiểm tra tất cả các trường hợp này, nhưng không kiểm tra dữ liệu .

Lưu ý bên lề: Câu hỏi của bạn tương tự như - làm thế nào để bạn kiểm tra các câu lệnh SQL của ứng dụng-?

Câu hỏi liên quan :


1: Bạn có thể quan tâm đến câu trả lời của @ DocBrown về chủ đề này


"Vấn đề (IMO) là bạn quá tập trung vào việc kiểm tra API bên ngoài." - Tôi không thấy bất cứ điều gì cho thấy rằng người hỏi quan tâm đến việc thử nghiệm API bên ngoài. Ngoài ra, bạn nói "vẫn còn API bên ngoài", nhưng bạn có bất kỳ đề xuất nào về việc người hỏi có nên sử dụng tùy chọn "quá đơn giản", tùy chọn "quá dễ vỡ", tùy chọn "quá phức tạp" hoặc tùy chọn thứ tư không?
Tanner Swett

Câu hỏi OP đang hỏi làm thế nào để kiểm tra một hàm gọi API bên ngoài. Nhưng đọc những nghi ngờ của anh ấy, dường như với tôi rằng anh ấy quá chú trọng vào việc kiểm tra truy vấn và kết quả của nó. Tôi đã đưa ra 4 gợi ý: (1) không thử nghiệm API. (2) không sử dụng các bài kiểm tra tích hợp làm bàn làm việc để điều chỉnh truy vấn. Làm một công cụ thay thế. (3) trở lại câu hỏi chính, làm bài kiểm tra đơn nhất và Tích hợp. Nhưng không xác nhận nội dung của phản hồi API. (4) Hỏi người quản lý dự án nếu họ nên / có thể tạo một bộ thử nghiệm API bên ngoài như một phần của kế hoạch thử nghiệm của dự án.
Laiv

1
Tôi coi bản thân truy vấn là "mã được viết bởi chúng tôi". Mục tiêu cuối cùng là kiểm tra tự động để cảnh báo chúng tôi nếu chúng tôi giới thiệu một lỗi trong mã của chúng tôi. Đưa nó vào những gì bạn đã nói về các câu lệnh SQL, tôi đoán nó tương tự như vậy - Tôi đoán câu hỏi của tôi giống như cách bạn kiểm tra mã của bạn đang truy vấn API bên ngoài theo cách mà API sẽ phản hồi như dự định (giả sử đáp ứng danh nghĩa). Tôi nghĩ những gì bạn đang nói là loại bỏ các bài kiểm tra đơn vị và tích hợp, nhưng nếu các truy vấn là nhiệm vụ quan trọng, chúng tôi có thể thiết lập một số bài kiểm tra tự động khác để kiểm tra api bên ngoài trực tiếp.
Joshua Coady

1
IMO, cách tốt nhất là thực hiện kiểm tra chức năng, thay đổi mệnh đề where sẽ không bao giờ đúng, sẽ gây ra một hành vi khác nhau trong một hoặc nhiều thử nghiệm chức năng của tôi. UT chỉ là một phần nhỏ trong kế hoạch kiểm tra.
Laiv

2
Cảm ơn vì đã là một ban âm thanh. Tôi đoán cuối cùng, mặc dù truy vấn có logic tùy chỉnh trong đó, nó nằm ngoài miền kiểm tra đơn vị vì truy vấn là mã được "thực thi" bên ngoài hệ thống đang được kiểm tra. Tôi chỉ cần ai đó nói với tôi rằng nhiều lần theo những cách khác nhau trước khi tôi nhìn thấy nó;)
Joshua Coady

2

Tôi đã thấy các kiểm tra đơn vị kiểm tra chuỗi truy vấn được tạo phù hợp với giá trị dự kiến.

Tuy nhiên. Đây là ý kiến ​​của tôi nếu sử dụng hạn chế. Cú pháp truy vấn rất phức tạp, có thể có lỗi, vì vậy A có khả năng vô tận để kiểm tra và B ngay cả khi chuỗi được tạo 'chính xác', kết quả không mong muốn có thể được trả về trong môi trường trực tiếp.

Tôi nghĩ rằng bạn đã đúng khi chọn tùy chọn của mình 2. chạy thử nghiệm tích hợp với phiên bản trực tiếp.

Miễn là chúng không phá hủy, đây là những bài kiểm tra đầu tiên bạn nên viết, vì chúng sẽ nắm bắt, mặc dù không xác định được nguyên nhân của bất kỳ lỗi nào.

Sử dụng tùy chọn 3 'triển khai một ví dụ thử nghiệm với dữ liệu giả' là ưu việt. Nhưng không ảnh hưởng đến việc viết bài kiểm tra của bạn, vì bạn có thể chỉ ra các bài kiểm tra tương tự tại máy chủ kiểm tra nếu và khi nào nó trở thành cách sử dụng tốt thời gian để triển khai một bài kiểm tra.


0

Nó phụ thuộc vào API, nhưng nếu có thể, hãy chọn tùy chọn # 3 (ví dụ thử nghiệm riêng).

Sơ khai API (tùy chọn số 1) là tùy chọn tồi tệ nhất, vì những lý do bạn đã đề cập và đi theo lộ trình này có thể sẽ gây hại nhiều hơn là tốt (rất nhiều thời gian lãng phí).

Chạy theo API thực (tùy chọn # 2) làm cho các bài kiểm tra trở nên không ổn định và không đáng tin cậy, và sau một vài kết quả dương tính, mọi người sẽ ngừng sử dụng chúng. Không chỉ có thể thay đổi dữ liệu, mà dịch vụ cũng có thể bị hỏng. Theo tôi, đây giống như không có bài kiểm tra nào cho các truy vấn và dựa vào các bài kiểm tra tích hợp / hệ thống để tìm ra các vấn đề. Điều đó nói rằng, nếu dữ liệu API hiếm khi thay đổi và bản thân API hầu như luôn luôn cập nhật, thì đây có thể là một lựa chọn khả thi. Hầu hết các API không phù hợp với mô tả này.

Cuối cùng, vấn đề này quan trọng và phức tạp đến mức nào: nếu có nhiều hơn một số ít và một số trong số chúng đủ phức tạp để bạn cảm thấy cần phải kiểm tra chúng, tôi sẽ đầu tư nỗ lực thiết lập một cá thể riêng để thử nghiệm . Nó sẽ tự trả tiền giống như các bài kiểm tra đơn vị khác.


Vì vậy, về cơ bản, bạn đang nói rằng các bài kiểm tra đơn vị (# 1) và kiểm tra tích hợp (# 2) có hại không? Trong khi # 3 có vẻ tốt nhất trong số đó, nó cũng có thể đắt nhất. Nó phải được duy trì mỗi khi API thay đổi. Nếu không có # 2, bạn sẽ không nhận ra các thay đổi có thể có trong API thực cho đến khi ứng dụng của bạn được sản xuất (quá muộn để thực hiện các biện pháp). Ok, # 1 dường như không cần thiết vì không có dòng mã nào để kiểm tra ... hôm nay ... Ngày mai, làm sao biết được ...
Laiv

Tôi đang nói rằng các xét nghiệm xấu là có hại, chắc chắn. Các bài kiểm tra dễ bị lãng phí rất nhiều thời gian và công sức, và khiến mọi người mất niềm tin vào các bài kiểm tra đơn vị nói chung. Các thử nghiệm phá vỡ thay đổi triển khai (# 1) hoặc chỉ ngẫu nhiên khi dữ liệu thay đổi (# 2) không phải là thử nghiệm tốt.
Michal Tenenberg

Kiểm thử tích hợp không kiểm tra dữ liệu. Đó là nó. Họ không thể phá vỡ thử nghiệm, chỉ cần xác nhận tích hợp. Thử nghiệm không phải là vấn đề đức tin là vấn đề có thói quen tốt làm tăng giá trị cho ứng dụng
Laiv
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.