API giả lập là một API giả hoạt động giống như một API thật. Nó chấp nhận các yêu cầu tương tự, trả về phản hồi với cấu trúc giống hệt và tồn tại ở một URL mà bạn có thể gọi. Tuy nhiên, đằng sau URL đó không có cơ sở dữ liệu thực, không có logic nghiệp vụ và không có dịch vụ thực sự. Phản hồi là thứ bạn đã định nghĩa trước.
Nghe có vẻ tầm thường, và ý tưởng này đúng là như vậy. Giá trị đến từ những gì nó cho phép bạn làm: xây dựng và thử nghiệm dựa trên một giao diện trước khi thứ đằng sau nó tồn tại, hoặc khi thứ thật quá chậm, quá tốn kém hoặc quá không đáng tin cậy để gọi. Bài giải thích này định nghĩa chính xác thuật ngữ, phân biệt API giả lập với những thứ thường bị nhầm lẫn, và trình bày sự khác biệt tĩnh-động quyết định cách API giả lập hoạt động.
API giả lập thực sự là gì
Về cơ bản, một API giả lập là một ánh xạ yêu cầu-phản hồi. Một yêu cầu đến. API giả lập so khớp nó với các quy tắc bạn đã đặt, chọn một phản hồi và gửi lại. Không có tính toán nào ở giữa trừ khi bạn yêu cầu.
Một API giả lập có ba phần. Đó là giao diện: các tuyến đường (routes), phương thức và tham số mà nó chấp nhận, phải khớp chính xác với API thật. Đó là định nghĩa phản hồi: các nội dung (bodies), mã trạng thái và tiêu đề mà nó trả về. Và đó là logic so khớp: cách API giả lập quyết định yêu cầu đã cho nhận được phản hồi nào, từ một so khớp đường dẫn đơn giản đến các quy tắc phân nhánh dựa trên tham số truy vấn hoặc tiêu đề.
Vì giao diện khớp với API thật, mã gọi API giả lập không biết rằng đó là giả. Chỉ cần đổi URL cơ sở là cùng một client có thể nói chuyện với dịch vụ thật. Khả năng hoán đổi đó chính là mục đích. Để xem hướng dẫn thực hành xây dựng một API giả lập, hãy xem hướng dẫn này về giả lập API để kiểm thử.
Việc hiểu rõ API giả lập *không phải là gì* cũng rất hữu ích. Nó không phải là bộ nhớ đệm (cache), vì bộ nhớ đệm lưu trữ các phản hồi thực còn API giả lập tự tạo ra chúng. Nó không phải là môi trường sandbox, vì sandbox của nhà cung cấp chạy logic thực, đơn giản hóa trong khi API giả lập không chạy bất kỳ logic nào. Và nó không phải là môi trường staging, vì staging là một triển khai đầy đủ của hệ thống thật. Một API giả lập nhẹ hơn cả ba: nó chỉ là cánh cửa phía trước của một API với các câu trả lời được định nghĩa trước đằng sau, và không có gì khác.
Mock và stub
Mọi người thường dùng “mock” và “stub” thay thế cho nhau, nhưng trong kiểm thử chúng có nghĩa khác nhau.
Stub là một ý tưởng đơn giản hơn. Nó trả về một câu trả lời đã được định sẵn cho một lời gọi và không làm gì khác. Hỏi nó về một người dùng, nó trả về một người dùng cố định. Stub không quan tâm đến cách nó được gọi.
Mock, theo nghĩa kiểm thử nghiêm ngặt, còn xác minh tương tác. Nó có thể xác nhận rằng nó đã được gọi, bao nhiêu lần và với những đối số nào. Mock có thể làm bài kiểm thử của bạn thất bại vì lời gọi sai, không chỉ đơn thuần là cung cấp một giá trị.
Trong công việc API hàng ngày, ranh giới này mờ nhạt, và "mock API" thường bao gồm cả hai. Điểm mấu chốt hữu ích: stub trả lời, mock vừa trả lời vừa quan sát. Khi kiểm thử của bạn chỉ quan tâm đến dữ liệu mà mã của bạn nhận được, một phản hồi kiểu stub là đủ. Khi nó quan tâm đến việc mã của bạn đã thực hiện lời gọi đúng cách hay không, bạn cần sự xác minh mà một mock thực sự mang lại. Để biết thêm từ vựng rộng hơn, hãy xem sự khác biệt giữa validation và verification.
Hai thuật ngữ nữa cũng gần gũi. Fake là một triển khai hoạt động nhưng được đơn giản hóa, giống như một cơ sở dữ liệu trong bộ nhớ được sử dụng thay cho một cơ sở dữ liệu thực; nó có logic, nhưng ít hơn. Spy bao bọc một đối tượng thực và ghi lại cách nó được gọi mà không thay đổi hành vi của nó. Một mock API, theo cách sử dụng thuật ngữ này trong phát triển API, gần giống nhất với một stub có xác minh tùy chọn, được phục vụ qua HTTP tại một URL thực. Bạn không cần phải quá cứng nhắc về thuật ngữ, nhưng việc biết được phổ rộng này giúp bạn đọc tài liệu kiểm thử mà không bị lạc.
API giả lập so với máy chủ thật
Một máy chủ thật và một máy chủ giả lập có thể nằm ở cùng một URL và trả về cùng một JSON, vì vậy sự khác biệt nằm ở những gì xảy ra đằng sau điểm cuối.
| API giả lập | Máy chủ thật | |
|---|---|---|
| Đằng sau điểm cuối | Phản hồi được định nghĩa trước | Logic sống và cơ sở dữ liệu |
| Nguồn phản hồi | Các quy tắc bạn đã viết | Tính toán theo từng yêu cầu |
| Dữ liệu | Cố định hoặc được tạo | Thật, bền vững |
| Tác dụng phụ | Không có | Ghi, tính phí, gửi email |
| Tốc độ | Nhanh và ổn định | Thay đổi theo tải |
| Tính đúng đắn | Khớp với những gì bạn đã định nghĩa | Khớp với hành vi thực tế |
Một máy chủ thật cho bạn biết sự thật: nó chạy mã thực và chứng minh hệ thống hoạt động. Nó cũng chậm, có trạng thái và có khả năng gây ra các tác dụng phụ thực, vì vậy một bài kiểm thử chống lại nó có thể tính phí thẻ hoặc gửi email.
Một máy chủ giả lập chỉ cho bạn biết những gì bạn đã nói với nó. Nó nhanh, không có tác dụng phụ và hoàn toàn có thể dự đoán được, điều này khiến nó lý tưởng cho việc phát triển và hầu hết các hoạt động kiểm thử. Nhưng một API giả lập có thể sai mà không hề biết, bởi vì nó không chạy logic thực. Đó là lý do tại sao bạn giữ một số bài kiểm thử trên máy chủ thật. Sự đánh đổi này được trình bày chi tiết trong bài viết máy chủ giả lập so với máy chủ thật.
Mock tĩnh và động
Một mock trả về phản hồi theo một trong hai cách, và sự lựa chọn này định hình cảm giác khi sử dụng mock.
Một mock tĩnh trả về một payload cố định. Bạn viết chính xác JSON một lần, và mọi yêu cầu khớp sẽ nhận được cùng một nội dung đó. Mock tĩnh có thể dự đoán được, giúp dễ dàng kiểm chứng. Điểm yếu của chúng là tính thực tế: một payload được mã hóa cứng duy nhất sẽ không làm lộ lỗi trong mã bị lỗi với chuỗi dài, mảng trống hoặc giá trị null không mong muốn.
Một mock động tạo ra phản hồi theo từng yêu cầu. Thay vì một giá trị cố định "id": "user_1001", nó tạo ra một UUID mới cho mỗi lần gọi. Thay vì một tên, nó trả về một tên thực tế khác mỗi lần. Mock động thường sử dụng ngữ pháp tạo dữ liệu như Faker.js để làm điều này, vì vậy một trường có tên email sẽ tạo ra một email và created_at sẽ tạo ra một ngày. Chúng thực tế hơn và tốt hơn trong việc phát hiện các trường hợp ngoại lệ, với chi phí là khó kiểm chứng chính xác hơn.
Hầu hết các nhóm đều sử dụng cả hai. Mock tĩnh cho các bài kiểm thử đơn vị nặng về kiểm chứng, nơi bạn cần một giá trị biết trước. Mock động cho việc phát triển, trình diễn và kiểm thử bao phủ kiểu fuzzing, nơi sự đa dạng quan trọng hơn một câu trả lời cố định.
Một mock động cũng có thể có điều kiện, đây là một bước tiến xa hơn so với việc tạo đơn giản. Một mock có điều kiện sẽ phân nhánh dựa trên yêu cầu: một yêu cầu cho /orders/404 trả về 404, một yêu cầu với token xấu trả về 401, và mọi thứ khác trả về 200 bình thường. Một điểm cuối mock duy nhất sau đó bao gồm cả trường hợp thành công và một số trường hợp lỗi cùng một lúc. Đây là điều khiến mock thực sự hữu ích cho việc kiểm thử, vì nó có thể tái tạo các phản hồi lỗi mà một máy chủ thật khỏe mạnh sẽ không tạo ra theo yêu cầu.
Vị trí của API giả lập trong phát triển
API giả lập hữu ích ở ba thời điểm. Ban đầu, nó cho phép các đội frontend và backend thống nhất về một hợp đồng và xây dựng song song, nhờ đó không bên nào phải chờ bên kia. Trong quá trình kiểm thử, nó tách biệt mã của bạn khỏi sự không ổn định của mạng và cho phép bạn kích hoạt các phản hồi lỗi mà một máy chủ thật sẽ không tạo ra theo yêu cầu. Và đối với các bản trình diễn và nguyên mẫu, nó cung cấp dữ liệu được kiểm soát, có thể dự đoán mà không có sự phụ thuộc trực tiếp nào có thể thất bại giữa chừng. Các kịch bản đó được khám phá thêm trong hướng dẫn này về các trường hợp sử dụng giả lập API.
Rủi ro lặp lại là sự sai lệch. Một mock là một ảnh chụp nhanh của một giao diện, và các giao diện thay đổi. Khi API thật thêm một trường hoặc đổi tên một trường, một mock không được kết nối sẽ tiếp tục phục vụ hình dạng cũ và các bài kiểm thử của bạn vẫn vượt qua dựa trên một hợp đồng không còn tồn tại.
Cách khắc phục là coi mock là được tạo ra, chứ không phải được viết thủ công. Tạo nó từ cùng một lược đồ mà API thật công bố, để khi hợp đồng thay đổi thì mock cũng được tạo lại. Một mock bạn tự gõ bằng tay là một bản sao sẽ nhanh chóng trở nên lỗi thời; một mock được tạo từ đặc tả luôn là một ảnh chụp nhanh hiện tại. Sự khác biệt này không thể hiện ngay từ ngày đầu, nhưng nó quyết định liệu mock có còn đáng tin cậy sau sáu tháng hay không. Apidog hoạt động theo cách này: bạn thiết kế API một lần, và điểm cuối mock được tạo từ thiết kế đó với dữ liệu thực tế được suy ra từ tên trường. Mock, tài liệu và kiểm thử hợp đồng API đều đọc từ một nguồn duy nhất, vì vậy chúng luôn đồng bộ. Để xem quy trình thiết kế-đến-mock từ đầu đến cuối, hãy Tải Apidog.
Các câu hỏi thường gặp
API giả lập là gì một cách đơn giản?
API giả lập là một API giả mạo một API thật. Nó hiển thị các tuyến đường tương tự và trả về các phản hồi có cấu trúc giống nhau, nhưng không có logic thực hay cơ sở dữ liệu đằng sau nó. Các phản hồi được định nghĩa trước, cho phép bạn xây dựng và kiểm thử dựa trên giao diện trước khi dịch vụ thực sự tồn tại.
Sự khác biệt giữa mock và stub là gì?
Stub chỉ trả về một phản hồi đã được định sẵn và không làm gì khác. Mock, theo nghĩa kiểm thử nghiêm ngặt, còn xác minh tương tác, vì vậy nó có thể kiểm tra xem nó đã được gọi đúng số lần với đúng đối số chưa. Stub trả lời; mock vừa trả lời vừa quan sát.
API giả lập khác với máy chủ thật như thế nào?
Một mock trả về các phản hồi được định nghĩa trước mà không có tính toán thực, vì vậy nó nhanh, dễ dự đoán và không có tác dụng phụ. Một máy chủ thật chạy logic thực tế trên một cơ sở dữ liệu thật, vì vậy nó chậm hơn và có trạng thái nhưng chứng minh hệ thống thực sự hoạt động. Sử dụng mock để phát triển, và máy chủ thật cho kiểm thử hợp đồng và kiểm thử đầu cuối.
Tôi nên sử dụng mock tĩnh hay mock động?
Sử dụng mock tĩnh khi bạn cần một giá trị có thể dự đoán để kiểm chứng, phù hợp với các bài kiểm thử đơn vị. Sử dụng mock động khi bạn muốn dữ liệu thực tế, đa dạng để bắt các trường hợp ngoại lệ, phù hợp với việc phát triển và trình diễn. Nhiều nhóm sử dụng cả hai.
Làm thế nào để ngăn API giả lập trở nên không chính xác?
Tạo mock từ cùng lược đồ mà API thật công bố thay vì viết thủ công. Khi hợp đồng thay đổi, mock sẽ được tạo lại. Việc hỗ trợ bằng các bài kiểm thử hợp đồng định kỳ với API thật sẽ giúp phát hiện sớm mọi sự sai lệch còn lại.