Postman Collection နှင့် Test Case များ

နားလည်ထားရမယ့် အချက်

"Users API" collection တစ်ခုမှာ List, Get, Create, Update, Delete request တွေ ဘေးချင်းယှဉ်ရှိနေသလို — tab ငါးခု ကွဲနေသည့်အစား Postman collection က ဆက်စပ်နေတဲ့ request များကို အစုတစ်ခုတည်းအဖြစ် စုစည်းပေးပါတယ်။ API တစ်ခုလုံးကို လုပ်ဖော်ကိုင်ဖက်ကို လွှဲပေးဖို့ ဒါမှမဟုတ် လအတော်ကြာမှ ပြန်ကြည့်ဖို့ လွယ်ကူစေပါတယ်။

တစ်ကြိမ် အောင်မြင်တဲ့ ခေါ်ဆိုမှုတစ်ခုက happy path တစ်ခုတည်းကိုသာ သက်သေပြပါတယ်။ တကယ့် testing ဆိုတာ တမင်တကာ API ကို ချိုးဖျက်ကြည့်မယ့်သူတစ်ဦးလို စဉ်းစားရမှာဖြစ်ပြီး၊ တစ်ကြိမ် အလုပ်ဖြစ်တာကို အတည်ပြုရုံ မဟုတ်ပါဘူး။

လိုအပ်သော input ချန်ထားခြင်း — ဥပမာ လိုအပ်သော "name" field မပါဘဲ user ဖန်တီးခြင်း။
token မမှန်ကန်ခြင်း/သက်တမ်းကုန်ခြင်း — ဥပမာ ပုံစံမမှန်တဲ့ token သို့မဟုတ် သက်တမ်းကုန်နေတဲ့ token ပို့ခြင်း။
Forbidden access — ဥပမာ login ဝင်ထားသော်လည်း ခွင့်ပြုချက်မရှိသော user က admin-only endpoint ကို ခေါ်ခြင်း။
မတွေ့ရှိသော resource — ဥပမာ တစ်ခါမှ မဖန်တီးခဲ့သော ဒါမှမဟုတ် ဖျက်ပြီးသား user ID ကို တောင်းဆိုခြင်း။
ထပ်နေသော data — ဥပမာ အသုံးပြုပြီးသား email address နဲ့ account တစ်ခု ဖန်တီးခြင်း။
Rate limited — ဥပမာ API ခွင့်ပြုထားတာထက် တစ်မိနစ်အတွင်း request ပိုပို့ခြင်း။
Server failure — ဥပမာ API ကိုယ်တိုင် internal error ကြောင့် 500 ပြန်ခြင်း။

request တစ်ခုမှာ ဒီ test case များစွာကို ချိတ်ဆက်ထားနိုင်ပါတယ် — တစ်ခုက success ကို၊ ကျန်တာတွေက failure များကို status code သို့မဟုတ် response ပုံစံ တိကျစွာ စစ်ဆေးပြီး အတည်ပြုပါတယ်။ "အလုပ်ဖြစ်လား" ဆိုတဲ့ မေးခွန်းကို "အရေးကြီးတဲ့ အခြေအနေတိုင်းမှာ မှန်ကန်စွာ fail ဖြစ်ရဲ့လား" ဆိုတဲ့ ပိုအသုံးဝင်တဲ့ မေးခွန်းအဖြစ် ပြောင်းပေးပါတယ်။

text

USERS API COLLECTION TREE
-------------------------
USERS API COLLECTION
  |-- List Users     GET    /users
  |-- Get User       GET    /users/:id
  |-- Create User    POST   /users
  |     +-- test: valid data       -> 201 Created
  |     +-- test: missing name     -> 400 Bad Request
  |     +-- test: invalid token    -> 401 Unauthorized
  |     +-- test: duplicate email  -> 409 Conflict
  |-- Update User    PUT    /users/:id
  +-- Delete User    DELETE /users/:id

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Users API collection မှာ request ငါးခု ရှိတယ်ဆိုပါစို့ — List, Get, Create, Update, Delete။ Create အောက်မှာ happy-path case က data မှန်ရင် 201 ဖြစ်ကြောင်း အတည်ပြုပြီး failure case များပါ — body ဗလာဆိုရင် 400၊ token မရှိရင် 401၊ email ထပ်ရင် account ထပ်မဖန်တီးဘဲ 409 ပြန်ရမယ်။

Get အောက်မှာ မရှိတဲ့ user ID ဆိုရင် 200 ဒေတာဗလာမဟုတ်ဘဲ 404 ပြန်ရမယ်။ Delete အောက်မှာ ID တစ်ခုတည်းကို ထပ်ခေါ်ရင် ခန့်မှန်းနိုင်တဲ့ အလုပ်လုပ်ရမယ်၊ မပြိုကျရပါ။ ဒါတွေက ထူးဆန်းတာ မဟုတ်ပါဘူး — client စစ်စစ်တွေ အမြဲကြုံနေရတာပါ။

အောက်က code လုပ်ဆောင်ချက်

ဒီလို rules အလိုက် အလုပ်လုပ်တဲ့ mock "server" ငယ်တစ်ခုနဲ့ test case အစု — အများစု pass၊ တစ်ခု တမင်မှား — ကို run ကြည့်ရင် pass/fail report ထွက်လာမယ်၊ တကယ့် Postman test run ပုံစံအတိုင်းပါပဲ။

Collection တစ်ခုက ဆက်စပ်နေသော request များကို စုစည်းပေးလို့ API surface တစ်ခုလုံးကို စနစ်တကျ စုစည်း၊ share လုပ်၊ အတူတကွ run နိုင်ပါတယ်။
ကောင်းတဲ့ testing ဆိုတာ happy path တစ်ခုတည်းမက — input ချန်ထားခြင်း၊ auth မှားခြင်း၊ forbidden၊ not-found၊ duplicate၊ rate limit၊ server error — တမင်တကာ failure case များကိုပါ ဖုံးလွှမ်းရပါတယ်။
test case တစ်ခုက status code အတိအကျ လိုမျိုး တိကျတဲ့ အရာတစ်ခုကို စစ်မှသာ အသုံးဝင်ပါတယ်၊ request ပြီးဆုံးရုံနဲ့ မလုံလောက်ပါ။

အတူတူ စမ်းရေးကြည့်မယ်

javascript

// Mock "Users API" responder — pretends to be the server the
// collection targets.
function mockUsersApi(request) {
  const { method, path, headers = {}, body } = request;

  if (method === "GET" && path === "/users/1") {
    return { status: 200, body: { id: 1, name: "Aye Aye" } };
  }
  if (method === "POST" && path === "/users") {
    if (!body || !body.name) {
      return { status: 400, body: { error: "name is required" } };
    }
    if (headers.Authorization !== "Bearer valid-token") {
      return { status: 401, body: { error: "invalid or missing token" } };
    }
    return { status: 201, body: { id: 99, name: body.name } };
  }
  if (method === "DELETE" && path === "/users/1") {
    return { status: 403, body: { error: "not allowed" } };
  }
  return { status: 404, body: { error: "not found" } };
}

// Each test case: a request plus what we expect back.
const testCases = [
  {
    name: "Get existing user (happy path)",
    request: { method: "GET", path: "/users/1" },
    expectedStatus: 200,
  },
  {
    name: "Create user with missing name",
    request: { method: "POST", path: "/users", body: {} },
    expectedStatus: 400,
  },
  {
    name: "Create user with invalid token",
    request: {
      method: "POST",
      path: "/users",
      headers: { Authorization: "Bearer wrong-token" },
      body: { name: "Su Su" },
    },
    expectedStatus: 401,
  },
  {
    name: "Delete user without permission",
    request: { method: "DELETE", path: "/users/1" },
    expectedStatus: 403,
  },
  {
    name: "Get a user that does not exist",
    request: { method: "GET", path: "/users/404" },
    expectedStatus: 404,
  },
  {
    // Deliberately wrong expectation, to show a realistic failing report.
    name: "Create user with valid token (wrong expectation on purpose)",
    request: {
      method: "POST",
      path: "/users",
      headers: { Authorization: "Bearer valid-token" },
      body: { name: "Zaw Zaw" },
    },
    expectedStatus: 200, // actual API returns 201 Created
  },
];

function runTestCases(cases, responder) {
  const results = cases.map((testCase) => {
    const response = responder(testCase.request);
    const passed = response.status === testCase.expectedStatus;
    return {
      name: testCase.name,
      expectedStatus: testCase.expectedStatus,
      actualStatus: response.status,
      passed,
    };
  });

  const passedCount = results.filter((r) => r.passed).length;
  return {
    results,
    summary: `${passedCount}/${results.length} test cases passed`,
  };
}

const report = runTestCases(testCases, mockUsersApi);
report.results.forEach((r) => {
  const mark = r.passed ? "PASS" : "FAIL";
  console.log(
    `[${mark}] ${r.name} (expected ${r.expectedStatus}, got ${r.actualStatus})`
  );
});
console.log(report.summary);

You should see

Run လုပ်ရင် ရလာမည့် တကယ့် output:

[PASS] Get existing user (happy path) (expected 200, got 200)
[PASS] Create user with missing name (expected 400, got 400)
[PASS] Create user with invalid token (expected 401, got 401)
[PASS] Delete user without permission (expected 403, got 403)
[PASS] Get a user that does not exist (expected 404, got 404)
[FAIL] Create user with valid token (wrong expectation on purpose) (expected 200, got 201)
5/6 test cases passed

FAIL တစ်ခုက တမင်ဖြစ်တာပါ — mock API က user ဖန်တီးအောင်မြင်ရင် 201 Created ကို မှန်ကန်စွာ ပြန်ပေမယ့် test case ကတော့ 200 လို့ မျှော်လင့်ထားလို့ပါ — တကယ့် test suite တစ်ခုက ဖမ်းမိမယ့် mismatch အမျိုးအစားအတိအကျပါပဲ။

၅ မိနစ် စမ်းကြည့်

သင်သုံးဖူးတဲ့ API တစ်ခုက endpoint တစ်ခုကို ရွေးပါ။ အနည်းဆုံး test case လေးခု ချရေးပါ — happy path တစ်ခုနှင့် ဒီသင်ခန်းစာက failure category ခုနစ်ခုထဲက သုံးခု။ test case တစ်ခုစီ pass ဖြစ်တယ်လို့ ယူဆဖို့ ဘယ် status code အတိအကျ မျှော်လင့်မလဲ တိကျစွာ ရေးပါ။

သတိလေးတစ်ချက်

happy path တစ်ခုတည်း စမ်းသပ်ပြီး "test လုပ်ပြီးပြီ" လို့ ခေါ်ခြင်း — တကယ့် bug အများစုက success case တစ်ခုတည်းထက် failure case တွေမှာ ပေါ်လာတတ်ပါတယ်။

request ကို error မတက်ဘူးဆိုတာသာ စစ်ပြီး status code သို့မဟုတ် field အတိအကျ assert မလုပ်ဘဲ test case ရေးခြင်း — ဒါက ဘာမှ ဖမ်းမိနိုင်တာမရှိသလောက်ပါ။

Postman Docs — Collections Overview — API Integration & Webhooks