Bỏ qua điều hướng

Prompt miễn phí

Sinh bộ test cho ứng dụng phụ thuộc API bên ngoài không ổn định

Tạo bộ test mô phỏng API chậm, lỗi ngẫu nhiên, timeout và retry để kiểm tra độ bền của luồng tích hợp.

Onter AdminCập nhật 26/09/2026 Mới · Chưa có đánh giá 0 lượt copy
CodingChatGPTCodex

Prompt dùng để làm gì?

Tạo bộ test mô phỏng API chậm, lỗi ngẫu nhiên, timeout và retry để kiểm tra độ bền của luồng tích hợp.

Điền thông tin của bạn

Prompt

Bạn là kỹ sư kiểm thử tự động và chuyên gia mô phỏng hệ thống phụ thuộc bên ngoài. Hãy phân tích luồng gọi API mà tôi cung cấp và thiết kế bộ test phù hợp cho một ứng dụng phụ thuộc vào dịch vụ bên ngoài có độ trễ thay đổi, lỗi ngẫu nhiên, phản hồi không nhất quán và khả năng timeout. Nhiệm vụ của bạn là: 1) xác định các điểm rủi ro trong luồng gọi; 2) đề xuất hoặc viết mock/stub/fake cho API bên ngoài để mô phỏng các trạng thái thành công, chậm phản hồi, lỗi 4xx/5xx, timeout và lỗi mạng; 3) tạo test cho retry, backoff, circuit breaker nếu phù hợp; 4) kiểm tra rằng application xử lý đúng khi phản hồi trễ hoặc lỗi lặp lại; 5) nêu rõ những gì cần assert trong từng test để chứng minh hành vi ổn định. Nếu đầu vào có framework test, hãy ưu tiên dùng đúng framework đó; nếu chưa có, hãy chọn cách viết test dễ đọc và dễ bảo trì. Tránh phụ thuộc vào dữ liệu thật hoặc gọi mạng thật trong test. Cuối cùng, hãy đưa ra khuyến nghị về cách tổ chức test để giảm flaky test và cách đặt timeout hợp lý cho từng nhóm kịch bản. Đầu ra phải theo cấu trúc rõ ràng: phân tích rủi ro, danh sách test case, mã test/mock minh họa, và lưu ý triển khai. Dữ liệu đầu vào: - Luồng gọi API: {{luong_goi_api}} - Framework test mong muốn: {{framework_test}} - Ngôn ngữ hoặc môi trường chạy: {{ngon_ngu}}
Xem đã lưu

Input mẫu

luong_goi_api: Hàm syncOrder gọi GET /inventory, rồi POST /reserve, nếu thất bại thì retry tối đa 2 lần.
framework_test: Jest
ngon_ngu: TypeScript

Output mẫu

Phân tích rủi ro: GET /inventory có thể trễ, POST /reserve có thể trả 500 hoặc timeout.
Test case: 1) thành công ngay; 2) inventory chậm nhưng vẫn trong ngưỡng; 3) reserve lỗi 500 lần đầu rồi thành công ở lần retry; 4) timeout sau 2 lần retry thì trả lỗi cho caller.
Mock minh họa: giả lập response sequence [200, 500, 200] và một case timeout.
Assert: số lần gọi, thông báo lỗi, trạng thái cuối của syncOrder.

Cách sử dụng

Dán luồng gọi API và nếu có thì nêu luôn framework test đang dùng, ngôn ngữ chạy, các endpoint liên quan. Sau đó chạy prompt trong công cụ phù hợp để nhận bộ test và mock hoàn chỉnh. Kiểm tra lại từng test có mô phỏng đúng lỗi, timeout, retry và không gọi mạng thật trước khi áp dụng.

Giải thích cấu trúc

Role
Đóng vai kỹ sư kiểm thử tự động để thiết kế test và mock cho hệ thống phụ thuộc API ngoài.
Context
Ứng dụng có thể gặp độ trễ, lỗi ngẫu nhiên và timeout, nên cần giảm flaky test và không dùng mạng thật.
Task
Phân tích rủi ro, tạo test case, viết mock/stub/fake và chỉ rõ assert cho retry, timeout, lỗi mạng.
Constraints
Không gọi API thật, ưu tiên framework được cung cấp, mô phỏng nhiều trạng thái lỗi khác nhau và giữ test dễ bảo trì.
Output
Trả về phân tích rủi ro, danh sách test case, mã test/mock minh họa và khuyến nghị tổ chức test.

Mẹo sử dụng

  • Nếu có retry, hãy kiểm tra số lần gọi và khoảng chờ giữa các lần thử.
  • Nên tách test nhanh cho logic và test tích hợp cho mock phức tạp.
  • Mỗi case chỉ nên kiểm tra một hành vi chính để dễ đọc và dễ sửa.

Nguồn và giấy phép

ONTER biên tập · original

Đánh giá prompt

Chọn số sao theo trải nghiệm của bạn. Bạn có thể sửa đánh giá sau một phút.

Prompt liên quan

Tài khoản Onter

Đăng nhập rồi tiếp tục việc đang làm.

Mở trang đăng nhập riêng nếu trình duyệt chưa hiển thị biểu mẫu.

Contact Me on Zalo