Automated API Testing: Mảnh ghép lớn trong bức tranh Automated End-to-End Testing

1. API là gì? Vì sao cần Automated API testing?

API là viết tắt của của cụm từ Application Programing Interface. Trước khi định nghĩa chúng ta làm rõ thêm ngữ nghĩa từ API ở bối cảnh computer science

1. A: Viết tắt của từ Application tiếng Việt là ứng dụng. Ví dụ: Zalo ứng dụng, Zalo web-app
2. P: Viết tắt của từ Programing tiếng Việt là lập trình
3. I: Viết tắt của từ Interface. Từ “interface” không thể hiểu theo cách thông thường là “giao diện” mà muốn đề cập những điều khoản/URIs công bố ra bên ngoài.

Vậy theo tôi, API là một thuật ngữ trong lĩnh vực khoa học máy tính mà nó mô tả một hình thức lập trình ứng dụng sử dụng những điều khoản (URIs) đã công bố của bên cung cấp Endpoint mà không quan tâm Endpoints làm gì bên trong, dựa trên những tiêu chuẩn đã được công nhận trước

Còn theo định nghĩa tại wikipedia

Ví dụ: Chúng ta sử dụng Zing mp3 API (được cấp phép) để viết một ứng dụng nghe nhạc cho riêng mình. Như vậy tôi sử dụng Zing mp3 API cung cấp và công bố (URI) để phát triển ứng dụng mà chúng ta không bao giờ biết Zing mp3 APIs làm gì, làm như thế nào bên trong.

Hình 1.0: Tổng quan hoạt động APIs

Automated API testing là chúng ta implement mã nguồn để kiểm thử giúp đảm bảo API Endpoints cung cấp ra bên ngoài hoạt động chính xác thay vì chúng ta sử dụng manual testing để thực hiện.

2. Vì sao phải automated API testing?

Một điểm thú vị là API testing thuộc về end-to-end testing (e2e) khi automated API testing chúng sẽ có 3 điểm nổi trội so với automated các loại test khác trong danh mục e2e: (1) Ổn định hơn hẳn UI testing, (2) thời gian thực thi testing ngắn, (3) triển khai đơn giản.
Ngoài lý do kể trên, theo sơ đồ Pyramid testing thì cũng khuyến cáo chúng ta gia tăng automated API testing test case càng nhiều càng tốt nói chung số test case đã implemented phải lớn hơn UI testing. Chúng ta nên ưu tiên triển khai API testing hơn so với UI testing.

Hơn nữa, thông thường một tính năng sản phẩm phần mềm: Phần UI (sử dụng bởi end-user) và URI của API cũng chung một logic (business/controller layer) xử lý. Nên 1 URI triển khai automated testing sẽ giúp giảm thiểu 80% test case cần automated của tính năng đó ở UI testing. Điều này giúp giảm cost trong quá trình implement acceptance testing rất nhiều.

Hình 2.0: Mô hình Pyramid testing

3. Điểm khác biệt chính giữa UI testing và API testing

Ở phần này chúng ta điểm qua một số điểm khác biệt chính của UI testing và API testing để làm tiền đề cho lý do vì sao nên automated API testing. Và các điểm liệt kê ở đây cũng chỉ mang tính chất tương đối

1. API testing có ưu điểm chạy nhanh, ổn định hơn UI testing. Thí dụ: 57 test case của Garoon REST API chạy chỉ mất 2 phút 28 giây trong khi một acceptance testing test case trung bình là 60 giây
2. UI testing end-user tương tác với ứng dụng ở mức độ client (Cài đặt và sử dụng ứng dụng) thông qua GUI với một kịch bản được xác định trước.
   API testing end-user tương tác với ứng dụng ở mức độ server (Gửi request lên API server) thông qua công cụ hỗ trợ như Postman để gửi request hoặc test code.
3. API testing ít phụ thuộc lẫn nhau giữa các thành phần. Vì mỗi URI xử lý đúng một việc duy nhất do đó không phụ thuộc với bất kỳ URI nào.
   UI testing phụ thuộc cao giữa các thành phần của ứng dụng. Vì UI test case hoạt động theo kịch bản end-user do đó trong kịch bản có sự tham gia của nhiều thành phần do đó nó phụ thuộc lẫn nhau.
   
   Ví dụ: Test case thêm mới một đối tượng appointment của module Schedule trong ứng dụng Garoon có hai thành phần: Facility, và appointment. –> chỉ cần facility không thêm thành công lúc test dẫn đến không thể thêm Appointment.
4. API testing ít tốn cost hơn so với UI testing
   Ít tốn cost hơn bao nhiêu? Để có con số chính xác hơn 50%, 70%, v.v. Nó phụ thuộc vào mỗi tổ chức, cá nhân cũng như thời gian trải nghiệm trên project. Cá nhân tôi từng đo lường thông thường implemented API testing ít cost hơn 70% cost so với UI testing.
5. API testing chạy ổn định hơn so với UI testing
   Lý do là gì? Chắc là bản chất của UI testing, xem thêm bài flaky test để có thể có nhiều thông tin hơn.

4. Cách tổ chức source code cho phù hợp với API testing

Trong bài này chúng ta sẽ mô tả automated testing Rest API với WebdriverIO testing framework. URI của REST API được cung cấp bởi Garoon’s REST API

Sơ đồ tổng quan E2E automated project

Hình 3.0: Tổ chức REST API trong e2e project

Nếu chúng ta một khi đã quyết tâm đeo đuổi automated E2E testing một cách nghiêm túc thì việc tìm hiểu và sử dụng một “right structure” source code phù hợp là điều xứng đáng đầu tư 🙂

Như Hình 3.0 ở trên, REST API sử dụng tài nguyên của E2E core lẫn tài nguyên của các loại test khác như Acceptance testing SOAP API, lẫn Cybozu’s JS API . Tổ chức đúng và nguyên lý chia sẻ tài nguyên có thể giúp việc triển khai REST API trở nên đơn giản hơn, ổn định, giảm cost.

Lưu ý thêm: REST API không làm việc trực tiếp với các loại test khác mà phải thông qua một facade pattern

Cấu trúc E2E và tổ chức source code

Trong loạt bài trước cũng từng đề cập về E2E project. Trong bài này chúng ta tập trung mô tả REST API là chính. Bên dưới REST API testing tổng thể như sau:

Copy

e2e
|---e2e-core
|   |---src
|   |   |---scheduler
|   |   |---mail
|   |   |---//...
|   |---.babelrc
|   |---mobile-view
|   |   |---src
|---rest-api
|   |---src
|   |   |---rest-core
|   |   |---shared
|   |   |   |---external-service
|   |   |   |   |---index.js // This file import and re-export other service for the rest api uses
|   |   |---schedule
|   |   |   |---event
|   |   |   |   |---POST
|   |   |   |   |   |---typical-regular-event
|   |   |   |   |   |   |---typical-regular.request.data.js|.expected.data.js|.spec.js
|   |   |   |   |   |   |---helper.js
|   |   |   |   |   |---private-regular-event
|   |   |   |   |   |   |---private-regular.request.data.js|.expected.data.js|.spec.js|.helper.js
|   |   |   |   |   |   |---helper.js
|   |   |   |   |   |---// ...
|   |   |   |   |---GET
|   |   |   |   |   |---typical-regular-event
|   |   |   |   |   |   |---typical-regular.request.data.js|.expected.data.js|.spec.js|.helper.js
|   |   |   |   |   |---// ...
|   |   |   |   |---DELETE
|   |   |   |   |   |---typical-regular-event
|   |   |   |   |   |   |---typical-regular.request.data.js|.expected.data.js|.spec.js|.helper.js
|   |   |   |   |   |---// ...
|   |---.babelrc
|   |---wdio.conf.js|.prepared.conf.js
|   |---setting.global.js
|---acceptance
|   |---schedule
|   |   |---test-specs
|   |   |   |---added-new-appoiment
|   |   |   |   |---added-new-appointment.spec.js|.data.js
|---package.json
|---wdio.conf.js
|---webpack.config.js
|---.gitignore
// ...

https://tech.cybozu.vn/automated-api-testing-manh-ghep-lon-trong-buc-tranh-automated-end-to-end-testing-7b9a2/

You need to login in order to like this post: click here