Automated API Testing — သဘောတရားအရ

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

Postman မှာ လက်ဖြင့် run ခဲ့တဲ့ test case တိုင်းက ပုံစံတူတူပါပဲ — request ပို့ပြီး ပြန်လာတာက မျှော်လင့်ထားတာနဲ့ ကိုက်ညီလား စစ်ပါတယ်။ Automated testing က ဒီပုံစံအတိုင်းပဲယူပြီး script ကို run ခိုင်းတာပါ — Send နှိပ်ဖို့ ဘယ်သူမှ မမှတ်ထားစေဘဲ စစ်ဆေးမှု အတူတူ အကြိမ်တိုင်း ဖြစ်ပါတယ်။

test runner က request ပို့ပြီး response ကို မျှော်လင့်ချက်များနှင့် နှိုင်းယှဉ် စစ်ဆေးပါတယ်။ အသိသာဆုံး စစ်ဆေးမှုက status code ဖြစ်ပေမယ့် status code တစ်ခုတည်းက မှန်ကန်မှုကို ခဲယဉ်းစွာသာ သက်သေပြပါတယ် — runner က body content နဲ့ headers ကိုလည်း စစ်သင့်ပါတယ်။

Schema check က ဖုံးကွယ်နေသော bug ကို ဖမ်းမိသည်

Field ရှိရုံမက type မှန်ကန်ကြောင်း အတည်ပြုခြင်းက 200 ပြန်နေဆဲ endpoint တစ်ခု တိတ်တဆိတ် data ပျက်စလုပ်နေတာကို ဖမ်းမိပါတယ် — status-code-only check လုံးဝ လွတ်သွားနိုင်တာပါ။

ဒါကို နားလည်ဖို့ framework အထူးတစ်ခု မလိုအပ်ပါဘူး။ JavaScript, Python နှစ်ခုစလုံးမှာ ရေပန်းစားတဲ့ library ရှိပေမယ့် concept — ပို့ပြီး status, body, headers, schema စစ်ခြင်း — ကသာ ဘယ် tool သုံးသုံး ကူးပြောင်းအသုံးချနိုင်ပါတယ်။ တကယ့်ကွာခြားချက်က test တွေက browser tab အစား CI ထဲမှာ ကိုယ်တိုင်လုပ်စရာမလိုဘဲ run ခြင်းပါပဲ။

text

AUTOMATED TEST PIPELINE
-----------------------
TEST RUNNER
     |
     v
SEND REQUEST
     |
     v
CHECK RESPONSE
   +-- STATUS    (200? 404? matches expectation?)
   +-- BODY      (right fields, right values?)
   +-- HEADERS   (content-type, rate-limit, etc.)
   +-- SCHEMA    (right fields AND right types?)
     |
     v
PASS / FAIL REPORT   (with a reason for every failure)

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

deploy တိုင်းအပြီး လက်ဖြင့် ပြန် run လေ့ရှိတဲ့ request သုံးခု ရှိတယ်ဆိုပါစို့ — user တစ်ဦး ရယူခြင်း၊ မရှိတဲ့ user ရယူခြင်း၊ order ဖန်တီးခြင်း။ ဒါတွေကို automate လုပ်တာက တစ်ခုစီ ဘာပြန်ရသင့်လဲ တစ်ကြိမ်တည်း ချရေးပြီး runner ကို deploy တိုင်း သုံးခုလုံး စစ်ခိုင်းတာပါပဲ။

အောက်က code က request တစ်ခုစီကို မျှော်လင့်ထားသော status နှင့် လိုအပ်သော field list တို့နှင့် တွဲပေးထားပါတယ်။ runner က request ပို့ပြီး status နှိုင်းယှဉ်ကာ field တစ်ခုစီ ရှိလား စစ်ပါတယ် — ရှုပ်ထွေးတဲ့ pass/fail အစား တိကျတဲ့ failure အကြောင်းရင်းများ စုစည်းပေးပါတယ်။

တမင်ထည့်ထားသော bug ပါဝင်သည်

ဥပမာကို run ကြည့်ရင် တကယ့် bug တစ်ခု တွေ့ရမှာပါ — order-creation endpoint မှာ ၎င်းရဲ့ test မျှော်လင့်ထားတဲ့ "total" field ပျောက်နေလို့ ဒီ test က တိကျတဲ့ အကြောင်းရင်းနဲ့ fail ဖြစ်ပြီး ကျန်နှစ်ခုက pass ဖြစ်ပါတယ်။

test runner တစ်ခုက Postman မှာ manual လုပ်ခဲ့တဲ့ ပို့ပြီး-စစ် ပုံစံအတိုင်းကို automate လုပ်ပေးတာပါပဲ။
status code တစ်ခုတည်းထက် ပိုစစ်ပါ — body content, headers, schema (field မှန်ကန်, type မှန်ကန်) တို့က status check တစ်ခုတည်း လွတ်သွားနိုင်တဲ့ bug ကို ဖမ်းမိပါတယ်။
automation ရဲ့ တန်ဖိုးက tool အသစ်တစ်ခု သင်စရာ မဟုတ်ဘဲ code ပြောင်းတိုင်း CI ထဲမှာ check အတူတူ ကိုယ်တိုင်လုပ်စရာမလိုဘဲ run ခြင်းပါပဲ။

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

javascript

// Mock responder standing in for a real HTTP call.
function mockApi(request) {
  if (request.method === "GET" && request.path === "/users/1") {
    return {
      status: 200,
      headers: { "content-type": "application/json" },
      body: { id: 1, name: "Aye Aye", email: "aye@example.com" },
    };
  }
  if (request.method === "GET" && request.path === "/users/999") {
    return { status: 404, headers: {}, body: { error: "not found" } };
  }
  if (request.method === "POST" && request.path === "/orders") {
    // Bug on purpose: forgets to include "total" in the response.
    return {
      status: 201,
      headers: { "content-type": "application/json" },
      body: { id: 55, status: "created" },
    };
  }
  return { status: 500, headers: {}, body: {} };
}

// A minimal automated test runner: checks status, body fields, and
// header presence for a batch of test definitions against a responder.
function runAutomatedTests(testDefs, responder) {
  return testDefs.map((def) => {
    const response = responder(def.request);
    const failures = [];

    if (response.status !== def.expectedStatus) {
      failures.push(
        `expected status ${def.expectedStatus}, got ${response.status}`
      );
    }

    for (const field of def.expectedFields || []) {
      if (!(field in (response.body || {}))) {
        failures.push(`missing expected field "${field}" in response body`);
      }
    }

    if (def.expectedHeader && !(def.expectedHeader in response.headers)) {
      failures.push(`missing expected header "${def.expectedHeader}"`);
    }

    return {
      name: def.name,
      passed: failures.length === 0,
      failures,
    };
  });
}

const testDefs = [
  {
    name: "GET /users/1 returns a full user schema",
    request: { method: "GET", path: "/users/1" },
    expectedStatus: 200,
    expectedFields: ["id", "name", "email"],
    expectedHeader: "content-type",
  },
  {
    name: "GET /users/999 returns 404 for a missing user",
    request: { method: "GET", path: "/users/999" },
    expectedStatus: 404,
    expectedFields: ["error"],
  },
  {
    name: "POST /orders returns the created order with its total",
    request: { method: "POST", path: "/orders" },
    expectedStatus: 201,
    expectedFields: ["id", "status", "total"],
  },
];

const report = runAutomatedTests(testDefs, mockApi);
let passCount = 0;
report.forEach((r) => {
  console.log(`[${r.passed ? "PASS" : "FAIL"}] ${r.name}`);
  r.failures.forEach((f) => console.log(`    - ${f}`));
  if (r.passed) passCount++;
});
console.log(`${passCount}/${report.length} tests passed`);

You should see

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

[PASS] GET /users/1 returns a full user schema
[PASS] GET /users/999 returns 404 for a missing user
[FAIL] POST /orders returns the created order with its total
    - missing expected field "total" in response body
2/3 tests passed

failure က တိကျပြီး ဆောင်ရွက်နိုင်ပါတယ် — "test failed" လို့ပဲ ပြောမည့်အစား ပျောက်နေတဲ့ field ကို အမည်တပ် ပြောပါတယ်၊ ဒါက automated check တွေ တည်ဆောက်တန်ကြောင်း သက်သေပြပါတယ်။

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

အထက်ပါ code ထဲကို သင်ရွေးချယ်တဲ့ endpoint (စစ်စစ်ဖြစ်ဖြစ် ကိုယ်တိုင်တီထွင်ဖြစ်ဖြစ်) အတွက် status၊ field အနည်းဆုံးနှစ်ခု၊ header တစ်ခုကို စစ်မယ့် စတုတ္ထ test definition တစ်ခု ထပ်ထည့်ပါ။ run ကြည့်ပြီး ဘာကြောင့် pass/fail ဖြစ်တယ်ဆိုတာ report က တိကျစွာ ရှင်းပြလား စစ်ပါ။

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

automated test မှာ status code တစ်ခုတည်း စစ်ပြီး body/schema check ကျော်လိုက်ခြင်း — "total" field ပျောက်နေတာကို လွတ်သွားစေတဲ့ ကွက်လပ်အတိအကျပါပဲ။

"test failed" လို့ပဲ ပြောတဲ့ failure message ရေးခြင်း၊ ဘာမျှော်လင့်ထားတယ် ဘာတွေ့ခဲ့တယ်ဆိုတာ အမည်မတပ်ခြင်း — failure ကို ရှာဖွေရခက်စေပါတယ်။

Martin Fowler — The Practical Test Pyramid — API Integration & Webhooks