Selenium để kiểm thử API: Có thể không, và Có nên không?

Selenium là một framework tự động hóa trình duyệt. Nó điều khiển Chrome, Firefox và các trình duyệt khác theo cách mà một người bình thường làm: nhấp vào nút, điền vào biểu mẫu, đọc trang được hiển thị. Đây là công cụ tiêu chuẩn để kiểm thử UI từ đầu đến cuối và nó thực hiện công việc đó rất tốt.

Mọi người vẫn hỏi liệu Selenium có thể kiểm thử API hay không. Câu trả lời thật lòng là bạn có thể bắt nó thực hiện các cuộc gọi HTTP, nhưng đó là công cụ sai cho công việc này. Hướng dẫn này giải thích chính xác lý do tại sao, cho thấy việc kiểm thử API thông qua Selenium thực sự trông như thế nào và chỉ cho bạn các công cụ được xây dựng cho công việc đó. Mục tiêu là giúp bạn tránh một thiết lập sẽ khiến bạn thất vọng sau này.

Tại sao Selenium và kiểm thử API không phù hợp

Một bài kiểm thử API gửi yêu cầu HTTP trực tiếp đến máy chủ và kiểm tra phản hồi: mã trạng thái, tiêu đề, nội dung, thời gian. Không có giao diện người dùng nào liên quan. Bài kiểm thử nên nhanh chóng, độc lập và chi phí thấp để chạy hàng nghìn lần.

Selenium làm ngược lại theo thiết kế. Nó khởi chạy một trình duyệt thực, tải các trang và chờ JavaScript hiển thị. Trình duyệt đó là toàn bộ mục đích khi bạn kiểm thử UI, và nó là sự tốn kém không cần thiết khi bạn kiểm thử API. Một yêu cầu mà một client chuyên dụng gửi trong hàng chục mili giây sẽ trở thành một công việc kéo dài nhiều giây một khi bạn liên quan đến một tiến trình trình duyệt, một phiên WebDriver và quá trình hiển thị trang.

Ngoài ra còn có một sự không phù hợp sâu sắc hơn. Toàn bộ API của Selenium xoay quanh các phần tử trên một trang: tìm nút này, đọc văn bản này, chờ phần tử này. Một phản hồi HTTP không phải là một trang. Nó không có DOM. Vì vậy, Selenium không cung cấp cho bạn bất cứ thứ gì hữu ích để kiểm tra nội dung JSON, khẳng định một tiêu đề hoặc kiểm tra mã trạng thái. Cuối cùng bạn sẽ phải làm việc vòng quanh công cụ thay vì làm việc với nó.

Chi phí không chỉ là tốc độ. Các bài kiểm thử dựa trên trình duyệt nổi tiếng là không ổn định (flaky). Chúng thất bại vì một trang mất nhiều thời gian hơn để hiển thị, vì một phiên WebDriver bị ngắt, hoặc vì một bản cập nhật trình duyệt làm thay đổi một số thời gian. Một bài kiểm thử API phải mang tính xác định: cùng một yêu cầu tạo ra cùng một phản hồi, và một thất bại có nghĩa là có điều gì đó thực sự bị hỏng. Định tuyến các kiểm tra API thông qua Selenium mang tất cả sự không ổn định của trình duyệt đó vào một lớp mà hoàn toàn không có lý do gì để không ổn định. Theo thời gian, một bộ kiểm thử không ổn định sẽ khiến nhóm bỏ qua các bản build màu đỏ, điều này làm mất đi mục đích của việc kiểm thử. Sự khác biệt giữa kiểm định (validation) và xác minh (verification) là một góc nhìn tốt ở đây: Selenium xác minh trải nghiệm được hiển thị, trong khi kiểm thử API xác thực hợp đồng bên dưới nó.

“Kiểm thử API với Selenium” thực sự có nghĩa là gì

Khi các bài viết khẳng định Selenium có thể kiểm thử API, họ thường đề cập đến một trong hai cách giải quyết. Cả hai đều không biến Selenium thành một công cụ kiểm thử API. Chúng chỉ định tuyến HTTP thông qua hoặc cùng với nó.

Tùy chọn một: sử dụng trình thực thi JavaScript của Selenium. Selenium có thể chạy bất kỳ JavaScript nào trong trình duyệt mà nó kiểm soát. Các trình duyệt hiện đại có API fetch, vì vậy bạn có thể yêu cầu trình duyệt thực hiện một yêu cầu và trả lại kết quả cho mã kiểm thử của bạn:

JavascriptExecutor js = (JavascriptExecutor) driver;
Object status = js.executeAsyncScript(
    "const callback = arguments[arguments.length - 1];" +
    "fetch('https://jsonplaceholder.typicode.com/users/1')" +
    "  .then(r => callback(r.status))" +
    "  .catch(e => callback('error: ' + e));"
);
System.out.println("Status code: " + status);

Điều này hoạt động. Nó cũng có nghĩa là bạn đã khởi động một trình duyệt, một WebDriver và một cầu nối JavaScript chỉ để thực hiện một cuộc gọi HTTP mà một client HTTP thông thường sẽ thực hiện trực tiếp. Bạn cũng thừa hưởng các ràng buộc của trình duyệt như CORS, điều mà một bài kiểm thử API từ máy chủ đến máy chủ không bao giờ phải nghĩ đến.

Tùy chọn hai: bỏ qua Selenium và sử dụng một thư viện HTTP thực sự bên cạnh nó. Trong một dự án Java, điều này có nghĩa là kết hợp Selenium với REST Assured cho các phần API:

import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;

given()
    .when()
    .get("https://jsonplaceholder.typicode.com/users/1")
    .then()
    .statusCode(200)
    .body("email", equalTo("Sincere@april.biz"));

Lưu ý rằng việc kiểm thử API thực tế ở đây được thực hiện hoàn toàn bởi REST Assured. Selenium không đóng góp gì. Hai thư viện này chỉ tình cờ cùng tồn tại trong một dự án. Điều đó không sao cả, nhưng đó không phải là “kiểm thử API với Selenium”. Đó là kiểm thử API với một thư viện kiểm thử API thích hợp, với Selenium hiện diện cho các bài kiểm thử UI không liên quan.

Khi việc kết hợp chúng là hợp lý

Có một trường hợp hợp lý để thực hiện công việc HTTP bên trong một bộ kiểm thử Selenium, và điều này đáng được làm rõ. Các bài kiểm thử UI của Selenium thường cần thiết lập hoặc dọn dẹp nhanh hơn khi thực hiện qua API hơn là thông qua trình duyệt.

Giả sử bạn có một bài kiểm thử UI kiểm tra trang lịch sử đơn hàng. Để kiểm thử nó, một đơn hàng phải tồn tại. Việc nhấp qua toàn bộ quy trình thanh toán trong trình duyệt chỉ để tạo đơn hàng đó là chậm và dễ hỏng. Thay vào đó, bài kiểm thử của bạn thực hiện một cuộc gọi API trực tiếp để tạo đơn hàng, sau đó chỉ sử dụng Selenium cho phần thực sự cần trình duyệt: tải trang lịch sử và xác minh đơn hàng hiển thị.

Đó là một thực hành tốt. Cuộc gọi API là phương tiện để đạt được mục đích, chứ không phải là thứ đang được kiểm thử. Cuộc gọi API vẫn nên thông qua một client HTTP thực sự, chứ không phải trình thực thi JavaScript. Vì vậy, ngay cả trong trường hợp này, Selenium không thực hiện kiểm thử API. Nó đang thực hiện kiểm thử UI, và một client HTTP thích hợp sẽ xử lý phía API.

Mô hình thiết lập qua API này đủ phổ biến đến mức hầu hết các bộ kiểm thử trưởng thành đều chủ động áp dụng nó. Nó giữ cho phần chậm, dựa trên trình duyệt của bộ kiểm thử càng nhỏ càng tốt, dành riêng cho một số ít hành trình thực sự cần một trang được hiển thị. Mọi thứ khác, bao gồm tất cả việc chuẩn bị dữ liệu và hầu hết việc xác minh, đều diễn ra thông qua các cuộc gọi HTTP nhanh chóng. Kết quả là một bộ kiểm thử chạy trong vài phút thay vì hàng giờ và thất bại vì những lý do thực sự. Để có cái nhìn rộng hơn về cách các lớp UI và tự động hóa kết hợp với nhau, hãy xem kiểm thử chức năng so với kiểm thử tự động.

Sử dụng một công cụ được xây dựng để kiểm thử API

Nếu mục tiêu của bạn là kiểm thử API, hãy sử dụng một công cụ được thiết kế cho mục đích đó. Sự khác biệt không hề nhỏ. Một công cụ kiểm thử API thực sự cung cấp cho bạn khả năng xây dựng yêu cầu, quản lý môi trường, khẳng định về trạng thái, tiêu đề và nội dung, chuỗi yêu cầu, chạy theo hướng dữ liệu và tích hợp CI, mà không cần khởi chạy trình duyệt.

Các lựa chọn của bạn thuộc về một vài nhóm:

Nếu bạn ưu tiên mã, một thư viện HTTP như REST Assured trong Java, requests trong Python, hoặc supertest trong Node là lựa chọn đúng đắn. Các thư viện này thực hiện yêu cầu và trả lại phản hồi trực tiếp cho bạn, với các trình trợ giúp khẳng định được xây dựng cho mã trạng thái và nội dung JSON. Không có trình duyệt, không có WebDriver và không có quá trình hiển thị, vì vậy một bộ kiểm thử đầy đủ chạy nhanh và chỉ thất bại khi chính API thay đổi.

Nếu bạn muốn một không gian làm việc trực quan, Apidog là một nền tảng API tất cả trong một bao gồm thiết kế API, gỡ lỗi yêu cầu, giả lập các endpoint, xây dựng các kịch bản kiểm thử tự động và tạo tài liệu, tất cả trong một dự án. Bạn xây dựng các khẳng định trực quan hoặc bằng kịch bản, chuỗi các yêu cầu thành các luồng nhiều bước, chạy các lần lặp theo hướng dữ liệu và thực thi mọi thứ trong CI. Nó cũng nhập các tệp OpenAPI và Postman, vì vậy một API hiện có có thể được tích hợp nhanh chóng. Không có bất kỳ phần nào trong số đó liên quan đến trình duyệt, bởi vì không có phần nào trong số đó nên liên quan đến trình duyệt. Bạn có thể tải Apidog để thử nghiệm với một API thực.

Đối với các nhóm muốn một framework ưu tiên mã, các hướng dẫn về Robot Framework cho tự động hóa API và xây dựng một framework kiểm thử tự động hóa API bao gồm các phương pháp tiếp cận mà, không giống như Selenium, thực sự phù hợp với kiểm thử HTTP.

Điểm mấu chốt thẳng thắn

Selenium là một phần mềm tuyệt vời cho mục đích nó được xây dựng, đó là tự động hóa trình duyệt. Kiểm thử API không phải là mục đích đó. Về mặt kỹ thuật, bạn có thể đẩy HTTP thông qua trình thực thi JavaScript của Selenium, và bạn có thể giữ một thư viện HTTP trong cùng dự án với Selenium, nhưng trong cả hai trường hợp, Selenium đều không mang lại giá trị cho việc kiểm thử API.

Việc chọn sai công cụ không phải là một quyết định trung lập. Nó làm cho các bài kiểm thử của bạn chậm hơn, khó bảo trì hơn và dễ gặp lỗi không liên quan gì đến API của bạn. Hãy tìm một công cụ được xây dựng cho công việc đó. Bộ kiểm thử của bạn sẽ nhanh hơn, đáng tin cậy hơn và dễ hiểu hơn nhiều. Tổng hợp các nền tảng kiểm thử tự động tốt nhất là một nơi tốt để so sánh các lựa chọn được xây dựng có mục đích.

Các câu hỏi thường gặp

Liệu Selenium có thể kiểm thử API REST không?

Nó có thể phát hành các yêu cầu HTTP thông qua trình thực thi JavaScript của trình duyệt, vì vậy theo nghĩa kỹ thuật hẹp thì có. Nhưng Selenium không có các tính năng để kiểm tra phản hồi, khẳng định JSON, hoặc kiểm tra tiêu đề, và nó mang theo toàn bộ chi phí không cần thiết của một trình duyệt. Nó không phải là công cụ kiểm thử API REST, và việc sử dụng nó như vậy sẽ tạo ra các bài kiểm thử chậm và dễ vỡ.

Tại sao một số hướng dẫn lại hiển thị Selenium với REST Assured?

Bởi vì việc kiểm thử API trong các hướng dẫn đó được thực hiện hoàn toàn bởi REST Assured, một thư viện kiểm thử HTTP thực sự. Selenium chỉ có mặt trong cùng dự án cho các bài kiểm thử UI không liên quan. Việc kết hợp này không sao cả, nhưng nó không có nghĩa là Selenium đang kiểm thử API. REST Assured mới là công cụ thực hiện.

Liệu có ổn không khi thực hiện các cuộc gọi API trong một bài kiểm thử Selenium?

Có, cho việc thiết lập và dọn dẹp. Việc tạo dữ liệu kiểm thử qua API nhanh hơn và đáng tin cậy hơn so với việc nhấp qua UI để tạo ra nó. Cuộc gọi API hỗ trợ bài kiểm thử UI chứ không phải là thứ đang được kiểm thử, và nó vẫn nên sử dụng một client HTTP thích hợp, chứ không phải trình thực thi JavaScript của Selenium.

Tôi nên sử dụng công cụ nào thay thế Selenium để kiểm thử API?

Đối với kiểm thử ưu tiên mã, một thư viện HTTP như REST Assured, requests của Python, hoặc supertest cho Node. Đối với không gian làm việc trực quan, một nền tảng API chuyên dụng như Apidog, hoặc các client như Postman, Insomnia, và Talend API Tester. Tất cả những công cụ này đều được xây dựng cho HTTP và tránh chi phí trình duyệt mà Selenium áp đặt.

Việc sử dụng Selenium cho các bài kiểm thử API có làm chậm quy trình CI của tôi không?

Đáng kể. Mỗi cuộc gọi API dựa trên Selenium khởi động một tiến trình trình duyệt và một phiên WebDriver, biến một yêu cầu HTTP dưới một giây thành một thao tác kéo dài nhiều giây. Trong toàn bộ một bộ kiểm thử, điều đó dẫn đến các quy trình pipeline dài và không ổn định. Một công cụ kiểm thử API chuyên dụng chạy cùng các kiểm tra đó nhanh hơn nhiều vì nó không bao giờ khởi chạy trình duyệt.