Test API loại PUT & PATCH — phân biệt rõ, không gộp chung
🎯 Mục tiêu học: phân biệt rõ PUT (thay toàn bộ, bắt buộc idempotent) và PATCH (cập nhật một phần) — 2 khái niệm rất hay bị test giống hệt nhau dù bản chất khác nhau.
Ví dụ minh hoạ
PUT https://api.example.com/v1/orders/ORD1003
Body: { "customerId": "CUS1001", "items": [{ "sku": "SKU002", "qty": 1 }], "note": "Đổi lại địa chỉ giao" }
Response 200 OK — toàn bộ đơn hàng được thay bằng dữ liệu mới.
PATCH https://api.example.com/v1/orders/ORD1003
Body: { "status": "CANCELLED" }
Response 200 OK — chỉ field status đổi, các field khác (customerId, items, note) giữ nguyên.
Checklist test cho PUT — nhóm theo 7 kịch bản (xem Mục 2.1)
1. Happy path
Mã TC
Nội dung
Kỳ vọng
TC-PUT-01
Gửi đủ body hợp lệ (customerId, items, note)
Toàn bộ đơn hàng được thay bằng dữ liệu mới, trả 200
2. Dữ liệu bắt buộc
Mã TC
Nội dung
Kỳ vọng
TC-PUT-02
Body PUT thiếu field 'note'
Xác nhận field này bị xoá về rỗng hay giữ nguyên giá trị cũ — điểm hay gây tranh cãi, phải hỏi dev
3. Định dạng & kiểu dữ liệu
Mã TC
Nội dung
Kỳ vọng
TC-PUT-03
items chứa qty là chuỗi thay vì số
Trả lỗi validate rõ ràng
4. Quy tắc nghiệp vụ & dữ liệu tham chiếu
Mã TC
Nội dung
Kỳ vọng
TC-PUT-04
Gọi PUT với orderId không tồn tại
Trả 404, không được tạo mới nhầm (khác với 1 số API cho phép PUT tạo mới nếu ID chưa có — cần xác nhận rule)
TC-PUT-05
items chứa sku không tồn tại trong kho
Trả lỗi nghiệp vụ, không cập nhật đơn với sản phẩm không có thật
5. Đặc thù PUT (bắt buộc idempotent)
Mã TC
Nội dung
Kỳ vọng
TC-PUT-06
Gọi 2 lần liên tiếp cùng body
Kết quả lần 2 giống hệt lần 1, không phát sinh thêm thay đổi
6. Bảo mật & phân quyền
Mã TC
Nội dung
Kỳ vọng
TC-PUT-07
PUT vào orderId thuộc khách hàng khác
Bị từ chối, đơn hàng của khách khác không bị thay đổi
7. Response contract
Mã TC
Nội dung
Kỳ vọng
TC-PUT-08
Kiểm tra response khi cập nhật thành công
Trả 200, body trả về đúng dữ liệu đã cập nhật đầy đủ (không thiếu field)
Checklist test cho PATCH — nhóm theo 7 kịch bản
1. Happy path
Mã TC
Nội dung
Kỳ vọng
TC-PATCH-01
Chỉ gửi field status
Đúng field status đổi, trả 200
2. Dữ liệu bắt buộc
Mã TC
Nội dung
Kỳ vọng
TC-PATCH-02
Gửi body rỗng {}
Trả lỗi hoặc không làm gì — cần xác nhận hành vi mong muốn với dev, không để mặc định lỗi 500
3. Định dạng & kiểu dữ liệu
Mã TC
Nội dung
Kỳ vọng
TC-PATCH-03
Gửi status với giá trị không nằm trong enum hợp lệ (vd 'HELLO')
Trả lỗi validate rõ ràng, không lưu giá trị rác vào DB
4. Quy tắc nghiệp vụ & dữ liệu tham chiếu
Mã TC
Nội dung
Kỳ vọng
TC-PATCH-04
Gọi với orderId không tồn tại
Trả 404
TC-PATCH-05
Đổi status từ COMPLETED ngược về PENDING
Nếu vi phạm state machine nghiệp vụ, phải trả lỗi 409 Conflict, không cho đổi tuỳ tiện
5. Đặc thù PATCH (chỉ đổi phần được gửi)
Mã TC
Nội dung
Kỳ vọng
TC-PATCH-06
Sau khi PATCH chỉ status, kiểm tra lại các field khác
customerId, items, note phải giữ nguyên như trước, không bị null hoá
6. Bảo mật & phân quyền
Mã TC
Nội dung
Kỳ vọng
TC-PATCH-07
PATCH vào orderId thuộc khách hàng khác
Bị từ chối, đơn hàng của khách khác không bị thay đổi
7. Response contract
Mã TC
Nội dung
Kỳ vọng
TC-PATCH-08
Kiểm tra response khi cập nhật thành công
Xác nhận trả về toàn bộ object hay chỉ field vừa đổi — cần nhất quán và khớp tài liệu, không đổi qua lại giữa các lần deploy
📌 Ghi nhớ
PUT = thay toàn bộ, bắt buộc idempotent. PATCH = chỉ đổi phần được gửi, các field khác phải giữ nguyên.
📖 Thuật ngữ Anh–Việt (mục này)
Đề thi dùng thuật ngữ tiếng Anh — nhớ đúng cụm bên trái. Bấm 🔊 để nghe từng từ, hoặc "Đọc tất cả" để nghe lần lượt Anh → (vài giây) → Việt.
Thuật ngữ (EN)
Nghĩa & ghi nhớ nhanh
Full replacement
Thay toàn bộ tài nguyên bằng dữ liệu mới (hành vi chuẩn của PUT)
Partial update
Cập nhật một phần dữ liệu (hành vi chuẩn của PATCH)
Idempotent
Bất biến khi lặp — gọi nhiều lần cho cùng 1 kết quả cuối
📎 Nội dung do maiqai.com biên soạn — endpoint và dữ liệu trong ví dụ chỉ mang tính minh hoạ, không thuộc hệ thống thật nào.