Sáu chữ cái giúp FDE thăm dò API của khách trước khi tích hợp

Ngày đầu ở chỗ khách, thứ bạn thường nhận được là một base URL, một token và một tài liệu API đã lỗi thời. Chưa ai nói cho bạn biết khi truyền sai tham số thì hệ thống trả về gì.

Khoá Exploring Service APIs through Test Automation của Amber Race trên Test Automation University (Applitools) bàn về lý do kiểm thử service API quan trọng, và dạy qua ví dụ minh hoạ trong từng bài. Dù đi từ góc nhìn kiểm thử, khoá dạy đúng kỹ năng bạn cần trong những ngày đầu đó: tìm hiểu một API lạ một cách có hệ thống.

Race là Senior Software Development Engineer in Test ở Big Fish Games, với hơn 15 năm kiểm thử ở Big Fish và Microsoft. Trang khoá học không ghi năm phát hành hay thời lượng.

Nội dung chia làm bốn phần: nhập môn kiểm thử API, thăm dò API bằng Postman, chiến lược POISED trong sáu chương 3.1–3.6, và phần viết test, gồm test đầu tiên, test data-driven, kỹ thuật nâng cao và Newman.

Với một FDE, giá trị của khoá không nằm ở Postman. Nó nằm ở cách nghĩ: trước khi viết dòng tích hợp đầu tiên, hãy biết hệ thống của khách phản ứng ra sao khi nhận đầu vào sai, token hết hạn hay dữ liệu lạ.

Vì sao nên coi API là một bản hợp đồng?

Chương 1 mở đầu bằng một định nghĩa rất mộc: API là một đoạn code nói chuyện với một đoạn code khác. Từ đó Race đi tới ý chính: API là những bản hợp đồng cho phép các chương trình giao tiếp với nhau. Vì thế kiểm thử API là kiểm tra xem những gì hai bên đã thoả thuận có còn đúng không.

Cách nhìn này đổi câu hỏi bạn mang vào buổi customer discovery. Thay vì hỏi “API này làm gì”, bạn hỏi “API này hứa gì, và hứa với ai”. Nếu khách không trả lời được, đó là rủi ro đầu tiên bạn cần ghi vào kế hoạch deployment.

Ý thứ hai của chương này còn sắc hơn. Race cảnh báo rằng bạn không thể mặc định API lúc nào cũng được gọi qua giao diện người dùng như dự kiến.

Ở môi trường doanh nghiệp, đây là chuyện xảy ra hằng ngày: một script cron cũ, một hệ thống ERP hay chính agent bạn sắp dựng sẽ gọi thẳng vào API, bỏ qua mọi bước kiểm tra mà UI vẫn làm hộ.

POISED biến việc thăm dò thành một danh sách kiểm tra

Trong khoá, POISED là heuristic để phủ test, gồm sáu mục: Parameters, Output, Interop, Security, Errors, Data. Một bài viết độc lập trên blog của Abstracta ghi nhận Race là người xây dựng heuristic này. Bài đó mô tả POISED là sáu khía cạnh cần xét khi đánh giá chất lượng và khả năng chịu lỗi của hệ thống.

Thử hình dung bạn tích hợp với một công ty logistics qua endpoint giả định GET /shipments?from=&to=&page=. Bảng dưới đây là một ví dụ minh hoạ, không lấy từ khoá học. Nó cho thấy sáu mục đó trở thành phép thử cụ thể như thế nào.

Mục	Phép thử trên endpoint giả định	Điều bạn muốn biết
Parameters	Bỏ from, đặt page=0, page=-1, ngày sai định dạng	API có kiểm tra đầu vào hay chỉ trông vào UI
Output	So từng trường với tài liệu, tìm trường có thể null	Những trường code của bạn sẽ dựa vào
Interop	Gọi trực tiếp, không qua UI, như một hệ thống khác sẽ gọi	Hành vi khi không có lớp UI che chắn
Security	Dùng token hết hạn, token của một tenant khác	Có lộ dữ liệu ngoài phạm vi được phép không
Errors	Ép ra lỗi 4xx và 5xx, đọc thông báo lỗi	Lỗi có rõ ràng hay làm lộ stack trace
Data	Dùng bản ghi thật có ký tự đặc biệt, múi giờ khác nhau	Dữ liệu thật có khớp với mẫu trong tài liệu không

Cột cuối cùng là thứ đáng mang đi họp với khách. Mỗi ô trống ở đó là một câu hỏi cần ai đó bên khách trả lời trước khi bạn lên production.

Học theo thứ tự nào thì không phí thời gian?

Nếu bạn đã là software engineer vài năm và quen Postman, hãy đọc nhanh chương 1 để nắm khái niệm hợp đồng, bỏ qua phần lớn chương 2, rồi dành thời gian cho sáu chương POISED. Sau đó làm chương 4, nhất là phần test data-driven, vì đó là cách bạn phủ được các biến thể dữ liệu thật của khách mà không phải viết tay từng request.

Nếu bạn chưa từng viết test API, hãy đi theo thứ tự của khoá. Chương 2 cho bạn đủ kỹ năng Postman để các ví dụ phía sau không trở thành rào cản.

Trong một podcast của TestGuild năm 2016, Race đưa ra lời khuyên đơn giản để làm quen một API lạ: cứ nghịch với nó. POISED là cách làm cho việc nghịch đó có chủ đích.

Từ thăm dò đến lưới an toàn cho deployment

Chương cuối dạy Newman, công cụ chạy collection Postman từ dòng lệnh và cần Node.js. Race kết thúc khoá bằng việc đưa các collection vào môi trường CI như Jenkins, để kiểm tra API trở thành một phần của quy trình build.

Với FDE, đây là bước chuyển quan trọng nhất. Những phép thử bạn viết trong tuần đầu để hiểu hệ thống của khách cũng chính là thứ báo động khi khách âm thầm đổi API sau ba tháng. Khi khách đã trả lời một câu hỏi trong cột cuối của bảng, câu trả lời đó nên trở thành một assertion trong collection chạy ở CI.

Về mặt nghề nghiệp, bạn có thể biến khoá học thành bằng chứng. Hãy dựng một repo nhỏ: chọn một API công khai, viết collection theo đủ sáu mục POISED, rồi chạy Newman trong GitHub Actions.

Trong CV, hãy mô tả việc bạn thăm dò hành vi của một API lạ rồi giám sát nó bằng test tự động. Khi đọc một tin tuyển dụng FDE, hãy tìm những dòng nói về việc tích hợp với hệ thống của khách: đó là chỗ để kể về repo này trong buổi phỏng vấn.

Tích hợp mà bỏ qua bước thăm dò là đặt cược vào tài liệu của khách. Sáu chữ cái của Race giúp bạn biết rõ API thật sự làm gì trước khi phải đặt cược.