🧭 API Testing · Chương 2 · Mục 2.3

Test API loại POST — validate input, chống tạo trùng

🎯 Mục tiêu học: test đúng trọng tâm của POST — validate dữ liệu đầu vào và hành vi "tạo mới" đặc trưng, vốn không bắt buộc idempotent.

Ví dụ minh hoạ

POST https://api.example.com/v1/orders
Body:
{
  "customerId": "CUS1001",
  "items": [{ "sku": "SKU001", "qty": 2 }],
  "note": "Giao giờ hành chính"
}

Response 201 Created (Location: /v1/orders/ORD1003):
{
  "orderId": "ORD1003",
  "customerId": "CUS1001",
  "status": "PENDING",
  "total": 250000,
  "createdAt": "2026-08-04T10:15:00Z"
}

Checklist test cho POST — 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-POST-01	Tạo thành công với dữ liệu hợp lệ	Trả 201, có orderId và createdAt

2. Dữ liệu bắt buộc

Mã TC	Nội dung	Kỳ vọng
TC-POST-02	Thiếu customerId	Trả lỗi validate rõ ràng
TC-POST-03	items rỗng ([])	Trả lỗi, không tạo đơn hàng 0 sản phẩm

3. Định dạng & kiểu dữ liệu

Mã TC	Nội dung	Kỳ vọng
TC-POST-04	qty là số âm hoặc không phải số nguyên (vd 1.5)	Trả lỗi validate, không tạo đơn với số lượng vô lý
TC-POST-05	customerId sai định dạng (vd không đúng pattern CUSxxxx)	Trả lỗi rõ ràng thay vì lỗi hệ thống chung chung

4. Quy tắc nghiệp vụ & dữ liệu tham chiếu

Mã TC	Nội dung	Kỳ vọng
TC-POST-06	sku không tồn tại trong kho	Trả lỗi nghiệp vụ, không tạo đơn hàng với sản phẩm không có thật
TC-POST-07	customerId không tồn tại trong hệ thống	Trả lỗi rõ ràng (vd 404/422), không tạo đơn 'mồ côi'

5. Đặc thù POST (không bắt buộc idempotent)

Mã TC	Nội dung	Kỳ vọng
TC-POST-08	Gọi lại đúng request giống hệt 2 lần liên tiếp (mô phỏng double-submit)	Xác nhận có tạo ra 2 bản ghi khác nhau, hay hệ thống có cơ chế chặn trùng (idempotency key)

6. Bảo mật & phân quyền

Mã TC	Nội dung	Kỳ vọng
TC-POST-09	Token thuộc khách hàng A nhưng body gửi customerId của khách hàng B	Bị từ chối, hoặc hệ thống tự lấy customerId từ token — không tin theo giá trị client tự khai
TC-POST-10	Payload SQL injection/script trong field note	Dữ liệu được lưu như chuỗi thường hoặc bị từ chối, không thực thi injection

7. Response contract

Mã TC	Nội dung	Kỳ vọng
TC-POST-11	Kiểm tra response khi tạo thành công	Đúng status 201 (không phải 200), có header Location trỏ đúng /v1/orders/{orderId} vừa tạo

📌 Ghi nhớ

Response thành công của POST nên trả đúng mã 201 kèm thông tin tài nguyên vừa tạo (id, thời gian tạo) — nhiều API trả nhầm 200 hoặc thiếu id, gây khó khăn cho phía client khi cần dùng lại id đó ngay sau đó.

📖 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
Double-submit	Gửi trùng request — do người dùng bấm 2 lần hoặc client tự động retry
201 Created	Status code chuẩn cho việc tạo mới thành công
Location header	Header trỏ tới URL của tài nguyên vừa được tạo
Idempotency key	Khoá gửi kèm request để server nhận biết và chặn xử lý trùng lặp

📎 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.