API टेस्ट ऑटोमेशन

यह क्यों ज़रूरी है

APIs अक्सर बदलते हैं, और हर बदलाव कहीं न कहीं किसी client को तोड़ सकता है: rename हुआ field, काम करना बंद कर चुका validation rule, या जहाँ 201 का वादा था वहाँ 200। हर merge के बाद दर्जनों request checks हाथ से दोहराना धीमा है, और practice में ऐसा होता ही नहीं। Automated regression suite इन्हें हर change पर दोहराता है, इसलिए defect उसी pipeline run में मिल जाता है जो उसे लाने वाले commit के साथ चला, जब change developer के दिमाग़ में अभी ताज़ा होता है।

API tests सबसे उपयोगी automated tests में से भी हैं। वे user interface को छोड़ देते हैं, इसलिए UI tests से तेज़ चलते हैं और कम टूटते हैं, और ऐसे business rules और error paths तक पहुँचते हैं जिन्हें कोई screen trigger नहीं कर सकती। Tester के लिए automation मेहनत को checks दोबारा चलाने से हटाकर उन्हें design करने पर लगाता है। लेकिन यह तभी काम करता है जब team suite पर भरोसा करे: product से असंबंधित वजहों से fail होने वाले tests, जैसे shared data या code में लिखा URL, जल्द ही नज़रअंदाज़ होने लगते हैं।

Frameworks: क्या देते हैं और कैसे चुनें

हर API automation framework, किसी भी language में हो, यही हिस्से जोड़ता है: test runner जो tests ढूँढता है, उन्हें अक्सर parallel में चलाता है और results बताता है; HTTP client जो requests भेजता है और status, headers और body दिखाता है; assertions; hooks या fixtures जो tests से पहले तैयारी और बाद में cleanup करते हैं; और reporters, जिनमें JUnit XML भी है, वह result format जिसे ज़्यादातर CI systems पढ़ सकते हैं। Frameworks में मुख्य फ़र्क tests लिखने के तरीके का है, और कोई भी framework आपके लिए tests design नहीं करता: techniques और expected results अब भी पिछले lessons से आते हैं।

• Code-based: tests किसी programming language की files होते हैं। उदाहरण: Playwright Test अपने request fixture के साथ (TypeScript या JavaScript), REST Assured, JUnit या TestNG के साथ (Java), और pytest, requests library के साथ (Python)। इनसे data, reuse और structure पर पूरा control मिलता है, और tests का review बाकी code की तरह होता है।
• Collection-based: API client में saved requests, test scripts के साथ, जैसे Postman collection। वही collection command line से Newman या Postman CLI से चलता है, और इसी तरह CI तक पहुँचता है। शुरुआत जल्दी होती है; collection बढ़ने पर helpers share करना और changes review करना मुश्किल होता जाता है।
• वही चुनें जो आपकी team के developers पहले से इस्तेमाल करते हैं, ताकि tests उसी repository में रहें और कोई भी उन्हें चला और ठीक कर सके। इस lesson के concepts एक framework से दूसरे में साथ चलते हैं।

आज़माएँ: REST रिक्वेस्ट जनरेटर

API tests के लिए code का छोटा primer

Simple API tests पढ़ने और लिखने के लिए developer होना ज़रूरी नहीं। आपको "टेस्टर्स के लिए कोड पढ़ना" वाले lesson की values, objects, loops और functions चाहिए, और कुछ और features जो हर API test इस्तेमाल करता है। इस section के आख़िर का code Playwright Test के लिए TypeScript में एक पूरी test file है, अभी बिना layers के: POST /api/v1/orders के लिए एक positive test और दो data-driven negative tests; यह endpoint 1 से 99 तक की qty स्वीकार करता है। नीचे के notes इसे हिस्सा-हिस्सा पढ़ते हैं। यह file अपने बनाए orders delete नहीं करती; layers और cleanup आगे के sections जोड़ते हैं। आगे गहराई के लिए "टेस्ट ऑटोमेशन के लिए प्रोग्रामिंग" वाला बाद का lesson modules, classes और asynchronous code विस्तार से समझाता है; वह further reading है, इस lesson की शर्त नहीं।

• Test file structure: test file एक module है। import { test, expect } from '@playwright/test' framework package से दो functions लेता है: test एक test declare करता है और expect एक assertion लिखता है। कोई file अपने functions export से दूसरों के साथ share करती है, और दूसरी files उन्हें import से लेती हैं, जैसा नीचे की layers करती हैं। Runner test folder में उन files को ढूँढता है जिनके नाम .spec.ts या .test.ts पर ख़त्म होते हैं, और उनके हर test को चलाता है।
• Test: test('creates a pending order', async ({ request }) => { … }) test को एक title देता है, जो report में दिखता है, और एक function जिसे runner call करता है। => function लिखने का छोटा तरीका (arrow function) है, और { request } वह request fixture लेता है जो runner देता है: configuration के base URL और headers के साथ पहले से set up HTTP client।
• async और await: request में समय लगता है, इसलिए request.post(…) एक promise लौटाता है, यानी ऐसी value जो बाद में आती है। await अगली line चलने से पहले उसका इंतज़ार करता है, और await सिर्फ़ async marked function में इस्तेमाल हो सकता है। await भूलना beginners का सबसे आम bug है: अगली line response की जगह अधूरे promise के साथ काम करती है, और test उलझाने वाले message के साथ fail होता है या request पूरी होने से पहले ख़त्म हो जाता है।
• Request call: request.post(path, { data }) path पर POST भेजता है, और path base URL के हिसाब से resolve होता है। Playwright data object को JSON body में बदलता है और Content-Type: application/json set करता है, जब तक आपने उसे खुद set न किया हो। request.get, put, patch और delete भी इसी तरह काम करते हैं।
• Status, headers और body पर assertions: expect(actual).toBe(expected) exact तुलना करता है। res.status() status code है, res.headers() lower-case names वाले headers लौटाता है, और await res.json() body parse करता है, जिसके बाद fields किसी भी object की तरह पढ़े जाते हैं (order.status)। toContain text का कोई हिस्सा जाँचता है, toHaveLength list की length। पहला fail हुआ expect test रोक देता है और expected और actual value दिखाता है।
• Data-driven rows: for (const qty of [0, 100]) हर value के लिए एक test register करता है। Title एक template literal है, यानी back-quote characters के बीच का text, जिसमें ${qty} value डालता है, इसलिए report में "rejects qty 0" और "rejects qty 100" दो अलग tests दिखते हैं।
• Environment configuration: file में न कोई host name है, न कोई key। Base URL और token environment variables से आते हैं: code के बाहर terminal या CI job में set की गई named values, जिन्हें code में process.env.API_BASE_URL की तरह पढ़ा जाता है। नीचे environments वाले section की configuration file इन्हें एक बार पढ़ती है, इसलिए वही test local, test या staging पर चलता है और कोई secret commit नहीं होता।

// tests/orders/first.spec.ts
import { test, expect } from '@playwright/test';

test('creates a pending order', async ({ request }) => {
  const res = await request.post('/api/v1/orders', {
    data: { customerId: 7, items: [{ sku: 'A-100', qty: 2 }] },
  });

  expect(res.status()).toBe(201);
  expect(res.headers()['content-type']).toContain('application/json');
  const order = await res.json();
  expect(order.status).toBe('pending');
  expect(order.items).toHaveLength(1);
});

for (const qty of [0, 100]) {
  test(`rejects qty ${qty}`, async ({ request }) => {
    const res = await request.post('/api/v1/orders', {
      data: { customerId: 7, items: [{ sku: 'A-100', qty: qty }] },
    });
    expect(res.status()).toBe(422);
  });
}

आज़माएँ: REST API टेस्टर

Layers में suite की बनावट

पाँच tests एक file में रह सकते हैं, पाँच सौ नहीं: अगर हर test अपने URLs, tokens और JSON खुद बनाता है, तो एक path rename करने का मतलब है उसे call करने वाला हर test बदलना। Maintainable suite काम को layers में बाँटता है, हर layer के बदलने की एक ही वजह होती है, और tests API तक सिर्फ़ नीचे की layers के ज़रिए पहुँचते हैं। कुछ teams client layer को service layer कहती हैं।

• Tests (tests/): हर test में एक behaviour, test का नाम उसी behaviour पर, और tests resource के हिसाब से grouped। Test अपना input तैयार करता है, client को call करता है और result assert करता है। उसमें कोई URL, token या raw request नहीं होती।
• API client (api/): हर endpoint के लिए एक function, जैसे orders के लिए create() या get(id)। Paths, methods और default headers सिर्फ़ यहीं रहते हैं, इसलिए बदला हुआ path एक ही बार ठीक होता है। Client response लौटाता है और assert नहीं करता; क्या सही है यह test तय करता है।
• Configuration (config/): जिस environment पर run चल रहा है उसका base URL, credentials, timeouts और logging, जो environment variables से पढ़े जाते हैं, और framework का HTTP client इन्हीं से एक बार set up होता है।
• Test data (data/): builders जो default रूप से valid payload लौटाते हैं, जिसमें test सिर्फ़ ज़रूरी हिस्सा बदलता है, साथ में उन records के लिए setup और cleanup hooks जिनकी test को ज़रूरत है।
• Shared checks (schemas/): JSON Schemas और reusable assertions, ताकि order पाने वाला हर test उसका shape एक ही तरह जाँचे।

tests/
  orders/
    create-order.spec.ts       one behaviour per test
    order-validation.spec.ts   data-driven invalid orders
  customers/
api/
  orders-client.ts             create(), get(), remove(): paths live here
data/
  order-builder.ts             newOrder(): valid defaults, change what matters
schemas/
  order.schema.json            the shape of an order, shared by tests
config/
  env.ts                       required(): stops when a variable is missing
playwright.config.ts           runner, reporters, HTTP defaults
.github/workflows/api-tests.yml

आज़माएँ: OpenAPI → टेस्ट केस

Assertions, test data और environments

तीन फ़ैसले तय करते हैं कि team suite पर भरोसा करेगी या उसे नज़रअंदाज़ करेगी। हर एक वही लागू करता है जो आप manual API testing से जानते हैं, ऐसे नियमों के साथ जो तब मायने रखते हैं जब run को कोई देख नहीं रहा:

• Assertions: सबसे पहले exact status assert करें और failure message में response body जोड़ें, ताकि report खुद सब समझा दे। फिर वह assert करें जिसके लिए test बना है: आपके भेजे data के लिए exact values, id और createdAt जैसी generated values के लिए type और format, और business rule। Structure को हर test में field checks दोहराने के बजाय एक shared JSON Schema से जाँचें।
• पूरे response की stored copy से तुलना करने से बचें: हर harmless नया field test तोड़ देता है, और copy में record होते समय जो defect था वह उसमें बना रहता है।
• Data: हर test अपनी ज़रूरत का data खुद बनाता है, API या seed script से, unique values के साथ जैसे names और codes में run id, ताकि tests अकेले, किसी भी order में और parallel में चल सकें। Read-only reference data, जैसे पहले से seeded test customer, share हो सकता है; जिस data को कोई test बदलता है वह नहीं।
• Cleanup: test ने जो बनाया उसे ऐसे after-hook में delete करें जो test fail होने पर भी चलता है, या ऐसे environment पर चलाएँ जो हर run के लिए दोबारा बनता है।
• Data-driven tests: negative API testing वाले lesson की invalid classes और boundary values एक table की rows बन जाती हैं, हर row अपने input और expected result के साथ, और एक ही test body उन्हें चलाती है।
• Environments: base URL, credentials और timeouts configuration से आते हैं, test code से कभी नहीं, ताकि वही suite laptop पर, CI में और staging के सामने चल सके। Secrets CI के secret store से या ऐसी local file से आते हैं जो कभी commit नहीं होती। Data बनाने या delete करने वाले tests production के सामने कभी नहीं चलते। नीचे का code configuration layer दिखाता है: एक helper जो कोई variable missing होने पर run रोक देता है, और Playwright configuration जो उसे इस्तेमाल करती है।

// config/env.ts: stop at once when the environment is not configured
export function required(name: string): string {
  const value = process.env[name];
  if (!value) throw new Error(`Missing environment variable ${name}`);
  return value;
}

// playwright.config.ts
import { defineConfig } from '@playwright/test';
import { required } from './config/env';

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  reporter: [['list'], ['junit', { outputFile: 'results/api-junit.xml' }]],
  use: {
    baseURL: required('API_BASE_URL'),        // local, test or staging
    extraHTTPHeaders: { Authorization: `Bearer ${required('API_TOKEN')}` },
  },
});

आज़माएँ: API स्कीमा वैलिडेटर आज़माएँ: API टेस्ट डेटा जेनरेटर

Worked example: नए order के checks को automate करना

POST /api/v1/orders का contract वही है जो API response validation वाले lesson में था: 201 Created, order के path वाला Location header, status pending, और total बराबर qty × unitPrice का जोड़। Contract validation rules भी जोड़ता है: order में कम से कम एक item हो, qty 1 से 99 तक का integer हो और हर sku मौजूद हो; invalid order 422 लौटाता है, एक errors array के साथ जिसकी field values हर invalid field का नाम बताती हैं, जैसे items[0].qty। ऊपर की layers के साथ Playwright Test में लिखा गया, इस section के आख़िर का code orders client, data builder और दो test files दिखाता है, जिनमें एक positive test और पाँच data-driven negative tests हैं। नीचे के notes बताते हैं कि यह code क्या करता है:

• हर test एक behaviour जाँचता है और उसका title वही बताता है, इसलिए report में ही टूटे हुए rule का नाम आ जाता है। expect(res.status(), await res.text()) का दूसरा argument failure message है, इसलिए गलत status response body के साथ report होता है। toMatchObject तब pass होता है जब order में बताए गए fields इन्हीं values के साथ हों, और बाकी fields को वह नज़रअंदाज़ करता है।
• Generated values relationship से जाँची जाती हैं: Location को नए id से बने order path के बराबर होना चाहिए, और expected total response के items से calculate होकर number के रूप में दो decimal places तक compare होता है।
• GET से order दोबारा पढ़ना साबित करता है कि वह store हुआ, सिर्फ़ echo नहीं हुआ।
• Negative rows एक ही test body share करती हैं; नई boundary value जोड़ना बस एक line है, और हर row report में अलग test के रूप में दिखती है। qty 0 और qty 100 वाली rows 1 से 99 के ठीक बाहर हैं। errors.map(…) error objects की list को उनकी field values की list में बदलता है, और toContain जाँचता है कि expected field उनमें है।
• Layers: OrdersApi एक class है, यानी objects बनाने का template। new OrdersApi(request) एक orders client बनाता है जो request fixture अपने पास रखता है; उसके create(), get() और remove() में paths रहते हैं और वे बिना assert किए response लौटाते हैं। newOrder() customer 7 के लिए valid order लौटाता है, जो एक seeded customer है जिसे कोई test नहीं बदलता, और ...changes test के दिए fields को इन default values के ऊपर copy करता है।
• Cleanup: हर test अपने बनाए orders के ids दर्ज करता है, और test.afterEach उन्हें delete करता है। यह एक hook है जो file के हर test के बाद चलता है, test fail होने पर भी, इसलिए tests अकेले, किसी भी order में और parallel में चल सकते हैं। बड़ा suite ऐसे hooks को data/ में builders के पास ले जाता है, ताकि हर test file उन्हें share करे।

// api/orders-client.ts: the only file that knows the order paths
import type { APIRequestContext } from '@playwright/test';

export class OrdersApi {
  constructor(private request: APIRequestContext) {}
  create(order: object) { return this.request.post('/api/v1/orders', { data: order }); }
  get(id: number) { return this.request.get(`/api/v1/orders/${id}`); }
  remove(id: number) { return this.request.delete(`/api/v1/orders/${id}`); }
}

// data/order-builder.ts: a valid order; a test changes only what it is about
export function newOrder(changes: object = {}) {
  return { customerId: 7, items: [{ sku: 'A-100', qty: 1 }], ...changes };
}

// tests/orders/create-order.spec.ts
import { test, expect } from '@playwright/test';
import { OrdersApi } from '../../api/orders-client';
import { newOrder } from '../../data/order-builder';

let created: number[] = [];                // ids of the orders this test created
test.afterEach(async ({ request }) => {    // runs after every test, even a failed one
  for (const id of created) await new OrdersApi(request).remove(id);
  created = [];
});

test('creates a pending order with the correct total', async ({ request }) => {
  const orders = new OrdersApi(request);
  const input = newOrder({
    items: [{ sku: 'A-100', qty: 2 }, { sku: 'B-200', qty: 1 }],
  });

  const res = await orders.create(input);
  expect(res.status(), await res.text()).toBe(201);  // body shown on failure
  const order = await res.json();
  created.push(order.id);                           // for the after-hook
  expect(res.headers()['location']).toBe(`/api/v1/orders/${order.id}`);
  expect(order).toMatchObject({ customerId: input.customerId, status: 'pending' });
  let sum = 0;
  for (const item of order.items) sum = sum + item.qty * item.unitPrice;
  expect(order.total).toBeCloseTo(sum, 2);

  const stored = await orders.get(order.id);         // stored, not only echoed
  expect(stored.status()).toBe(200);
  expect(await stored.json()).toMatchObject({ id: order.id, total: order.total });
});

// tests/orders/order-validation.spec.ts (same imports)
const invalid = [
  { name: 'qty 0', items: [{ sku: 'A-100', qty: 0 }], field: 'items[0].qty' },
  { name: 'qty 100', items: [{ sku: 'A-100', qty: 100 }], field: 'items[0].qty' },
  { name: 'qty as text', items: [{ sku: 'A-100', qty: '2' }], field: 'items[0].qty' },
  { name: 'unknown sku', items: [{ sku: 'Z-999', qty: 1 }], field: 'items[0].sku' },
  { name: 'no items', items: [], field: 'items' },
];

for (const row of invalid) {
  test(`rejects an order with ${row.name}`, async ({ request }) => {
    const res = await new OrdersApi(request).create(newOrder({ items: row.items }));
    expect(res.status(), await res.text()).toBe(422);
    const fields = (await res.json()).errors.map((e: { field: string }) => e.field);
    expect(fields).toContain(row.field);
  });
}

आज़माएँ: REST API टेस्टर

CI में suite चलाना

Automated suite का फ़ायदा तब मिलता है जब वह किसी के शुरू किए बिना चलता है। CI pipeline में API tests एक job होते हैं: code checkout करना, dependencies install करना, variables और secrets के ज़रिए suite को किसी environment की ओर point करना, उसे चलाना, results publish करना और कोई test fail हो तो pipeline को fail करना। नीचे का workflow यह job GitHub Actions syntax में दिखाता है; GitLab CI और Jenkins वही steps अपनी files में लिखते हैं। ज़्यादातर teams API tests कई जगह चलाती हैं:

• हर pull request पर: suite का तेज़ core हिस्सा, किसी test environment या job के अंदर शुरू की गई service के सामने, ताकि author merge से पहले failure देख ले।
• Main branch में merge के बाद: shared test environment के सामने पूरा regression suite।
• हर deployment के बाद: deployed environment के सामने छोटा read-only smoke set, जैसे health, authentication और हर मुख्य resource का एक read।
• Schedule पर, जैसे हर रात: धीमे tests और third-party sandboxes के सामने चलने वाले tests, जिन्हें हर merge को नहीं रोकना चाहिए।
• हर run JUnit report upload करता है, tests fail होने पर भी (if: always()), और logs job के साथ रहते हैं, ताकि failure को दोबारा चलाए बिना diagnose किया जा सके।
• Red run merge या deployment रोक देता है; GitHub पर इसके लिए job को किसी branch protection rule या ruleset में required status check बनाना होता है। Flaky test को एक owner मिलता है और वह ठीक या quarantine किया जाता है, green होने तक retry नहीं।

# .github/workflows/api-tests.yml
name: api-tests
on:
  pull_request:
  push:
    branches: [main]
jobs:
  api-tests:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      - run: npx playwright test
        env:
          API_BASE_URL: ${{ vars.API_BASE_URL }}   # configuration variable
          API_TOKEN: ${{ secrets.API_TOKEN }}      # from the secret store
      - uses: actions/upload-artifact@v7
        if: always()                               # failures need evidence
        with:
          name: api-test-results
          path: results/

आज़माएँ: YAML फ़ॉर्मेटर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024टेस्ट ऑटोमेशन समाधान और उनकी आर्किटेक्चर के डिज़ाइन, कार्यान्वयन और रखरखाव पर ISTQB का advanced पाठ्यक्रम।
• The Practical Test Pyramid (Ham Vocke)martinfowler.com · 2018ऑटोमेटेड टेस्ट पोर्टफ़ोलियो में unit, integration, contract और UI टेस्ट का संतुलन कैसे रखें — व्यापक रूप से उद्धृत व्याख्या।
• Playwright DocumentationMicrosoft (Playwright)Playwright का आधिकारिक दस्तावेज़ — Chromium, WebKit और Firefox चलाने वाला end-to-end टेस्ट फ़्रेमवर्क।
• GitHub Actions documentationGitHubGitHub Actions में workflows, jobs, runners और artifacts कैसे परिभाषित होते हैं — जहाँ हर push या pull request पर ऑटोमेटेड टेस्ट चलते हैं।