Hầu hết các đội đều biết cách mock một API. Ít đội nào có câu trả lời rõ ràng về thời điểm thực sự hữu ích và khi nào nó chỉ thêm một lớp cần duy trì. Một mock bạn sử dụng đúng lúc sẽ loại bỏ một nút thắt cổ chai thực sự. Một mock bạn tạo ra theo thói quen trở thành một thứ khác lệch lạc so với thực tế và âm thầm lừa dối bạn.
Bài viết này bỏ qua phần cách thực hiện và tập trung vào thời điểm. Mỗi phần là một tình huống cụ thể mà việc mocking thể hiện giá trị của nó: xây dựng với backend chưa hoàn thiện, kiểm thử các luồng lỗi, thay thế một dịch vụ bên thứ ba không ổn định, chạy demo và ổn định CI. Hãy đọc nó như một công cụ hỗ trợ ra quyết định, không phải một hướng dẫn.
Phát triển song song frontend và backend
Đây là trường hợp kinh điển. Nhóm frontend cần một endpoint mà nhóm backend chưa xây dựng. Nếu không có mock, frontend hoặc là phải chờ đợi, hoặc là phải code dựa trên những giả định có thể hỏng ngay khi tiếp xúc với dịch vụ thật.
Một mock phá vỡ sự phụ thuộc này. Cả hai đội thống nhất hợp đồng trước tiên, thường là tài liệu OpenAPI. Frontend xây dựng dựa trên một mock được tạo ra từ hợp đồng đó trong khi backend triển khai dịch vụ thật. Khi backend hoàn thành, frontend chỉ cần thay đổi URL cơ sở và, nếu cả hai bên đều tuân thủ hợp đồng, không có gì khác cần thay đổi.
Sự thống nhất là phần cốt lõi. Một mock do chỉ frontend tạo ra chỉ mã hóa các giả định của một nhóm. Một mock được tạo ra từ một đặc tả chung giúp cả hai nhóm đồng bộ, đây cũng là nguyên tắc đằng sau kiểm thử hợp đồng API. Mock để mở khóa công việc song song, nhưng chỉ khi có một hợp đồng được cả hai bên ký duyệt.
Lợi ích tích lũy trong suốt dự án. Một nhóm frontend không bao giờ bị chặn bởi backend có thể triển khai tính năng theo lịch trình của riêng mình. Một nhóm backend không bị làm phiền bởi các endpoint chưa hoàn chỉnh sẽ tập trung hơn. Các nhà thiết kế và quản lý sản phẩm có thể có một bản dựng có thể nhấp được để phản ứng sớm hơn vài tuần. Không điều nào trong số đó yêu cầu dịch vụ thật phải tồn tại. Chi phí duy nhất là giữ mock đồng bộ với hợp đồng khi hợp đồng phát triển, điều này khá rẻ khi mock được tạo ra từ đặc tả chứ không phải viết tay.
Kiểm thử các luồng lỗi bạn không thể kích hoạt theo yêu cầu
Một API khỏe mạnh trả về 200. Đó chính là vấn đề. Mã client của bạn cũng phải xử lý 429, 500, 503, các nội dung không đúng định dạng và thời gian chờ, và một máy chủ đang hoạt động sẽ không tạo ra những lỗi đó khi bạn yêu cầu kiểm thử.
Một mock tạo ra những lỗi đó theo lệnh. Bạn cấu hình nó để trả về 500 cho một yêu cầu, 429 với tiêu đề Retry-After cho yêu cầu khác, và một nội dung đến sau một độ trễ cố ý cho yêu cầu thứ ba. Sau đó, bạn khẳng định rằng logic thử lại, lùi thời gian (backoff) và xử lý thời gian chờ của bạn đều hoạt động đúng.
| Lỗi cần kiểm thử | Thiết lập Mock | Điều nó chứng minh |
|---|---|---|
| Lỗi máy chủ | Trả về 500 |
Client thử lại, sau đó giảm chức năng một cách duyên dáng |
| Giới hạn tần suất | 429 với Retry-After |
Client chờ đúng khoảng thời gian |
| Mạng chậm | Trì hoãn phản hồi 5 giây | Client hết thời gian chờ một cách sạch sẽ |
| Payload lỗi | Trả về JSON bị lỗi | Trình phân tích cú pháp thất bại mà không bị treo |
Đây là trường hợp sử dụng mà các nhóm thường bỏ qua nhất và hối tiếc nhất. Xử lý lỗi chưa bao giờ được thực hiện là xử lý lỗi mà bạn không có. Kết hợp mock với các khẳng định API kỹ lưỡng để mỗi đường dẫn lỗi được xác minh, không phải giả định.
Có một loại lỗi thứ hai đáng để mock: các phản hồi HTTP hợp lệ nhưng sai đối với miền của bạn. Một 200 với giá âm, một đơn hàng với trạng thái không có trong enum của bạn, một danh sách phân trang mà con trỏ next không trỏ đến đâu. Một máy chủ thật, nếu đúng, không bao giờ gửi những thứ này. Một mock có thể làm được, và việc cung cấp cho client của bạn dữ liệu cố ý không đúng định dạng nhưng vẫn hợp lệ là cách bạn tìm ra những giả định mà mã phân tích cú pháp của bạn âm thầm đưa ra.
Thay thế cho một API của bên thứ ba
Việc gọi một bộ xử lý thanh toán thật, một dịch vụ bản đồ hoặc một API vận chuyển trong các bài kiểm thử của bạn rất chậm, đôi khi tốn tiền cho mỗi lần gọi và phụ thuộc vào một dịch vụ mà bạn không kiểm soát. Nếu sandbox của họ gặp sự cố, bộ kiểm thử của bạn cũng gặp sự cố.
Hãy mock bên thứ ba. Bạn ghi lại các phản hồi thật của họ một lần, hoặc xây dựng các mock từ lược đồ đã công bố của họ, sau đó chạy các bài kiểm thử của bạn dựa trên mock. Các bài kiểm thử sẽ trở nên nhanh, miễn phí và mang tính xác định. Chúng cũng tiếp tục hoạt động khi nhà cung cấp gặp sự cố.
Có một chi phí bảo trì. Bên thứ ba có thể thay đổi API của họ mà không thông báo cho bạn, và mock của bạn sẽ không biết. Giải pháp là một công việc nhỏ được lên lịch để gọi dịch vụ thật và xác nhận phản hồi vẫn khớp với hình dạng của mock. Việc kiểm tra hợp đồng đó là nơi duy nhất bạn chạm vào bên thứ ba trực tiếp, và nó bắt lỗi sai lệch trước khi người dùng của bạn nhận ra. Cũng nên đăng ký nhận thông báo thay đổi (changelog) của nhà cung cấp, để một thay đổi đã được lên kế hoạch đến với bạn trước khi một bài kiểm thử hợp đồng thất bại.
Cung cấp sức mạnh cho các bản demo và prototype
Một bản demo gọi các dịch vụ trực tiếp trước mặt khách hàng là một sự đánh cược. Một truy vấn chậm, một tập kết quả trống rỗng hoặc một sự cố không may có thể biến một bài thuyết trình bóng bẩy thành một lời xin lỗi.
Một mock làm cho bản demo trở nên xác định. Bạn lập kịch bản chính xác dữ liệu mà bản demo cần: đơn hàng được giao đúng hạn, bảng điều khiển với các số liệu tốt, tìm kiếm trả về kết quả rõ ràng. Điều tương tự cũng áp dụng cho các prototype. Bạn có thể xác thực một luồng UI hoặc giới thiệu một tính năng rất lâu trước khi bất kỳ backend nào tồn tại, bởi vì mock cung cấp mọi phản hồi mà prototype mong đợi.
Điểm ở đây không phải là kiểm thử, mà là kiểm soát. Bạn quyết định khán giả nhìn thấy gì, và không có yếu tố bên ngoài nào có thể làm hỏng nó. Đối với công việc giai đoạn đầu, mock thường là cách nhanh nhất để có một thứ gì đó có thể nhấp được hiển thị trước mặt mọi người. Các công cụ so sánh trong cùng thể loại được đề cập trong bài viết này về các công cụ mock API trực tuyến.
Một mock prototype cũng đóng vai trò như một tài liệu thiết kế. Khi mock trả về các hình dạng chính xác mà API cuối cùng sẽ phục vụ, mã frontend bạn viết dựa trên nó là mã thật, không phải là scaffolding dùng một lần. Nếu backend sau này tuân thủ cùng một hợp đồng, prototype sẽ trở thành sản phẩm chỉ với một thay đổi URL cơ sở. Đó là sự khác biệt giữa một mock được sử dụng như một cái nạng và một mock được sử dụng như một khởi đầu thuận lợi.
Giữ CI nhanh và ổn định
Một bộ kiểm thử gọi các dịch vụ bên ngoài trong CI sẽ kế thừa mọi vấn đề mà các dịch vụ đó có. Các sự cố mạng, giới hạn tần suất, dữ liệu staging được chia sẻ mà một bản dựng khác vừa thay đổi: mỗi điều này biến thành một lỗi không ổn định (flaky failure) không liên quan gì đến mã đang được xem xét.
Các bài kiểm thử không ổn định (flaky tests) khiến mọi người bỏ qua các lỗi, điều này làm mất đi ý nghĩa của CI. Mocking các phụ thuộc bên ngoài làm cho bộ kiểm thử trở nên khép kín (hermetic). Mỗi lần chạy bắt đầu từ cùng một trạng thái đã biết, hoàn thành nhanh hơn vì không có chuyến đi khứ hồi qua mạng, và chỉ thất bại khi mã thực sự bị lỗi.
Giữ lại một ngoại lệ. Chạy một lớp kiểm thử hợp đồng mỏng chống lại API thật theo lịch trình, tách biệt khỏi bộ kiểm thử theo từng commit. Những kiểm thử này xác nhận rằng các mock vẫn khớp với sản phẩm thực tế. Bộ kiểm thử theo từng commit vẫn nhanh và được mock; công việc theo lịch trình sẽ phát hiện sự sai lệch. Sự phân chia này là trọng tâm của một quy trình kiểm thử CI/CD lành mạnh.
Việc tăng tốc độ không phải là một tiện ích nhỏ. Một bộ kiểm thử giảm từ mười hai phút xuống còn chín mươi giây sẽ thay đổi cách một nhóm làm việc. Các nhà phát triển chạy nó trước mỗi lần đẩy mã thay vì hy vọng. Người đánh giá thấy kết quả trong khoảng thời gian đọc sự khác biệt. Một bộ kiểm thử nhanh, khép kín là thứ mà mọi người thực sự tin tưởng, và niềm tin là toàn bộ lợi tức đầu tư của việc kiểm thử tự động.
Khi nào không nên mock
Mocking có một chế độ lỗi: một mock không còn khớp với thực tế. Các bài kiểm thử vẫn xanh trong khi sản xuất gặp sự cố, bởi vì chúng đang xác thực một hư cấu.
Không nên mock khi điều đang được kiểm thử là bản thân sự tích hợp. Kiểm thử hợp đồng và kiểm thử đầu cuối tồn tại để xác minh ranh giới thực tế, vì vậy việc mock chúng sẽ loại bỏ lý do tồn tại của chúng. Không nên mock một phụ thuộc mà bạn không bao giờ xác minh với thực tế, bởi vì một mock không được xác minh sẽ lệch lạc. Và đừng sử dụng mock khi dịch vụ thật nhanh, miễn phí và đáng tin cậy trong môi trường kiểm thử của bạn; mock khi đó sẽ chỉ là chi phí phát sinh.
Quy tắc chung: mock để tăng tốc độ, cô lập và kiểm soát, và giữ một tập hợp nhỏ, chân thật các bài kiểm thử chạm vào thực tế để xác nhận rằng các mock vẫn đúng. Nếu bạn muốn mock và kiểm tra hợp đồng cùng tồn tại ở một nơi, Apidog tạo mock từ thiết kế API của bạn và chạy kiểm thử đối với cả mock và endpoint thực tế. Để thiết lập điều đó, Tải Apidog và bắt đầu từ đặc tả hiện có của bạn. Để hiểu rõ cơ sở khái niệm, hãy xem mock API thực sự là gì.
Các câu hỏi thường gặp
Khi nào tôi nên mock một API thay vì gọi API thật?
Mock khi bạn cần tốc độ, sự cô lập hoặc kiểm soát: phát triển song song với backend chưa hoàn thiện, kiểm thử các luồng lỗi mà máy chủ thật sẽ không tạo ra, thay thế một dịch vụ bên thứ ba chậm hoặc có phí, chạy demo và giữ CI ổn định. Gọi API thật cho kiểm thử hợp đồng và kiểm thử đầu cuối.
Mocking có thay thế kiểm thử tích hợp không?
Không. Mocking dùng cho kiểm thử đơn vị và thành phần nơi bạn kiểm tra mã của chính mình. Kiểm thử tích hợp và hợp đồng phải chạm vào ranh giới thực tế, vì nhiệm vụ của chúng là xác nhận dịch vụ thực tế khớp với hợp đồng. Mock những điều đó sẽ loại bỏ mục đích của chúng.
Làm thế nào để tôi giữ một mock không bị lỗi thời?
Tạo mock từ một lược đồ chia sẻ, lý tưởng là OpenAPI, để một thay đổi hợp đồng sẽ cập nhật nó. Sau đó chạy các kiểm thử hợp đồng theo lịch trình đối với API thật để xác nhận phản hồi trực tiếp vẫn khớp với lược đồ đó. Sự sai lệch sẽ được phát hiện trước khi đến tay người dùng.
Tôi có thể mock một API của bên thứ ba mà tôi không kiểm soát không?
Có, và đó là một trong những trường hợp sử dụng mạnh mẽ nhất. Ghi lại các phản hồi thật của bên thứ ba hoặc xây dựng các mock từ lược đồ đã công bố của họ, sau đó kiểm thử với mock để đạt tốc độ và độ tin cậy. Thêm một kiểm tra theo lịch trình đối với dịch vụ trực tiếp để bạn nhận ra khi nhà cung cấp thay đổi API của họ.
Mocking có hữu ích cho các bản demo và prototype không?
Rất hữu ích. Một mock làm cho bản demo trở nên xác định bằng cách lập kịch bản chính xác dữ liệu bạn muốn khán giả xem, không có rủi ro từ sự cố trực tiếp hoặc dữ liệu không may mắn. Đối với các prototype, mock cho phép bạn xây dựng và xác thực một luồng UI trước khi bất kỳ backend nào tồn tại.