Postman đã thay đổi, cải tiến rất nhiều kể từ khi mình viết những bài trước. Bài này sẽ giới thiệu 1 số tips mình sử dụng khi làm auto test API với postman.

I. Postman – Workspace

Trước kia, ta chỉ có 1 workspace và làm nhiều project trên đó nhưng đã có tính năng tách workspace thì ta nên tách mỗi project là 1 workspace, sẽ dễ nhìn hơn rất nhiều, tránh được những nhầm lẫn khi kéo thả các request từ folder này sang folder khác.

Ngoài ra, còn có nhiều tiện ích mà chúng ta ít sử dụng:

Trong số này thì mình hay sử dụng console log nhất vì console log sẽ show toàn bộ thông tin request và response, giúp ích cho việc debug nhiều. Nếu bạn thắc mắc là mỗi khi run Send API thì response sẽ trả về được hiển thị ở phía dưới rồi, cần gì phải console log? Có 2 trường hợp bạn sẽ cần phải sử dụng console log:

1. Bạn test theo Runner. Runner dashboard chỉ lưu full thông tin của 10 request đầu tiên, những request phía sau, nó chỉ lưu thông tin cơ bản, bạn ko xem được full thông tin nếu có request nào đó bị lỗi.
2. Nếu bạn viết các tham số của 1 API dưới dạng biến thì bạn cần có console log thì mới view được giá trị thực các tham số ở mỗi lần run.

II. Test

Ở phần test, mình có nói ở bài 9 rồi nhưng có 1 vài điểm mọi người cần chú ý:

1. Các error code cần được check nếu các error code này được sử dụng đúng như định nghĩa của REST API ví dụ:
   • 200 - success: Dùng cho happly case: nhận request và trả response có data đúng.
   • 400 - bad request: Dùng trong các TH lỗi ở phía client ví dụ: sai data type, missing data parameter.
   • 401 - Unauthorized: Dùng trong việc thiếu token authen
   • 403 - Forbidden: Dùng cho việc access vào những resource không có quyền hạn
   • 500 - Server error: Dùng cho các vấn đề error của server: Thiếu library, disconnect DB…
2. Ngoài error code thì có thể sử dụng response data để verify thêm. Đọc lại bài này để biết cách test API như thế nào.
3. Ngoài ra, các built-in function của Postman đã được thay đổi khá nhiều, các bạn xem ở đây. Link docs

III. Environment

Phần này thì cũng không có nhiều sự thay đổi, nhưng có 1 số lưu ý nhỏ

1. Nên đặt tên biến meaningfull. Ví dụ: ta thực hiện test 1 field là Phone, thì có 2 cases: phone sai và phone đúng, ta không nên đặt tên biến là phone và dùng chung cho cả hai trường hợp, ta nên tách ra thành wrongPhone và rightPhone.
2. Environment có thể lưu được array. Ví dụ: Khi nhận response trả về 1 list các giá trị customerId và bạn muốn lưu list customerId đấy về thành 1 array để request khác bạn có thể lấy random các giá trị đấy.

Muốn biết thêm nhiều kỹ thuật nữa, hãy đăng ký lớp postman script!

IV. Run script

Để đảm bảo rằng test API lúc nào chạy cũng đúng, mình có 2 cách làm:
1. Với TH các API có đủ, “đủ” ở đây có nghĩa là với bất cứ cái dữ liệu, action nào trên UI thì cũng có API tương ứng. –> Mình sẽ tạo test data bằng cách dùng API cần thiết, sau đó mới run API test. Cách làm này sẽ giúp cho các Test case không bị phụ thuộc vào test data ở chỗ nào cả.
Ví dụ: Bạn cần test API update_info_user, bạn sẽ sử dụng API create_user trước, thay vì sử dụng 1 user đã có sẵn trong hệ thống

2. Với TH các API không có đủ, ta nên chuẩn bị sẵn các data test của mình và cả DB test nữa. Cách làm:

1. Bạn tạo ra đủ các master data bằng cách thủ công: các data cần thiết để có thể run được API, ví dụ bạn tạo ra list các sản phẩm trước khi thực hiện mua hàng, đặt số lượng của sản phẩm ở mức cao tương đối, ví dụ đặt số lượng = 100.
2. Chạy thử 1 lượt với tất cả các API bạn có với Runner, nếu có lỗi thì fix.
3. Chạy lại lần 2 để đảm bảo đã hết lỗi. (Lưu ý, nên dynamic parameter nhiều nhất có thể, đừng hard code data)
4. Dump DB ra thành 1 file sql để khi nào mình run lại script thì mình sẽ run lại file sql này trước.

IV. Tổng kết

Đây là những gì mình rút ra được trong 2 tuần viết code test API cho dự án, có thể nó còn sai ở đâu đó nhưng tính đến thời điểm hiện tại vẫn chạy OK. Trong tương lai nếu có thời gian mình sẽ viết chi tiết các case cụ thể như những bài trước để các bạn có thể áp dụng được luôn.