टेस्ट डेटा, फ़िक्स्चर और हुक्स

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

कई unreliable automated suites product की वजह से नहीं, state की वजह से fail होती हैं। एक test अकेले pass होता है और पूरे run में fail, क्योंकि पहले वाले test ने shared account बदल दिया; Monday को run fail होता है क्योंकि test जिस coupon पर निर्भर था वह expire हो गया; हज़ारों runs के बचे हुए orders एक list page को इतना धीमा कर देते हैं कि उसके tests timeout हो जाते हैं। Suite का setup और cleanup तय करता है कि लाल result का मतलब defect है या सिर्फ़ noise, और noise team को लाल results नज़रअंदाज़ करना सिखा देता है।

Setup maintenance की लागत भी तय करता है। Sign-in flow बदले तो fixture एक जगह है जिसे update करना है; copy किए गए बीस setup blocks बीस जगहें हैं। Data-driven tests में नया case एक row जोड़कर जुड़ जाता है, और पढ़ने लायक table reviewer या product owner को code पढ़े बिना cases जाँचने देती है।

Automated test में test data कहाँ रहता है

Test runner tests को बिना निगरानी, किसी भी क्रम में और अक्सर parallel में चलाता है, इसलिए test जिस भी value पर निर्भर है वह ऐसी जगह से आनी चाहिए जिस पर test का नियंत्रण हो। जो test चुपचाप किसी shared environment में हाथ से बनाए गए record पर निर्भर है, वह उस दिन fail होगा जिस दिन वह record बदला या delete हुआ, और वह failure product defect जैसा दिखेगा।

Data कहीं भी रहे, दो नियम लागू होते हैं। Test उस data का मालिक है जिसे वह बदलता है: सिर्फ़ read-only reference data, जैसे countries की list या ऐसा product catalogue जिसे कोई test नहीं बदलता, share किया जा सकता है। और जिस field को unique होना है उसे हर run में unique value मिलती है, जैसे sara+${runId}@example.com, ताकि दूसरा run या parallel worker "already exists" से fail न हो।

Data ख़ुद चार जगह रह सकता है; चुनें इस आधार पर कि test पढ़ने वाले को क्या दिखना चाहिए।

• Test के अंदर inline: वे एक-दो values जो test को समझाती हैं, जैसे "rejects a zero quantity" नाम के test में quantity: 0। जो value मायने रखती है उसे assertion के पास दिखता रखें।
• Builder या factory function: makeCustomer({ country: "JO" }) समझदार defaults के साथ पूरा valid record लौटाता है, और test सिर्फ़ वही field बदलता है जिसके बारे में वह है। कोई नया mandatory field आए तो factory एक बार बदलें।
• Data file: repository में tests के बगल में CSV या JSON table, जब कई cases एक ही test body share करते हों। इसे code की तरह review और version किया जाता है।
• Test से पहले बनाई गई state: वे records जिनका मौजूद होना ज़रूरी है, screens पर click करके नहीं बल्कि API या seed script से बनाए जाते हैं, क्योंकि clicking धीमी है और ऐसी वजहों से fail होती है जिनसे test का कोई लेना-देना नहीं।

आज़माएँ: टेस्ट डेटा फ़ैक्टरी आज़माएँ: UUID जनरेटर

Hooks: वह code जिसे runner tests से पहले और बाद में बुलाता है

ज़्यादातर runners चार hooks देते हैं। beforeAll file या group के पहले test से पहले एक बार चलता है, beforeEach हर test से पहले, afterEach हर test के बाद और afterAll आख़िरी test के बाद एक बार। Jest और Vitest ठीक यही नाम इस्तेमाल करते हैं; Playwright Test इन्हें test.beforeEach वगैरह लिखता है; JUnit 5 annotations @BeforeAll, @BeforeEach, @AfterEach और @AfterAll इस्तेमाल करता है। pytest साधारण setup और teardown functions भी support करता है, लेकिन उसका आम औज़ार fixture है, जो अगले section में समझाया गया है।

हर test के लिए क्रम है: beforeEach hooks, फिर test body, फिर afterEach hooks। Nested groups में बाहरी group का beforeEach अंदर वाले group के beforeEach से पहले चलता है। सबसे ज़रूरी बात यह है कि after-hooks test fail होने पर भी चलते हैं। Fail हुआ assertion test body को उसी line पर रोक देता है, इसलिए body की आख़िरी lines में लिखा cleanup कभी नहीं चलता, जबकि afterEach में रखा cleanup चलता है।

जिस state को tests बदलते हैं उसके लिए beforeEach इस्तेमाल करें, ताकि हर test नए सिरे से शुरू हो। beforeAll सिर्फ़ ऐसे महँगे setup के लिए रखें जिसे tests पढ़ते हैं पर कभी बदलते नहीं, जैसे stub server चालू करना; एक बार बना और कई tests द्वारा बदला गया mutable data result को इस पर निर्भर बना देता है कि tests किस क्रम में चले। Playwright Test में beforeAll हर worker process में एक बार चलता है, और किसी test के fail होने के बाद उसकी जगह आए नए worker में फिर से चलता है, इसलिए उसे दोबारा चलना सुरक्षित होना चाहिए।

import { test, expect } from '@playwright/test';

test.describe('saved addresses', () => {
  const created: string[] = [];              // ids of addresses these tests created

  test.beforeEach(async ({ page }) => {
    await page.goto('/account/addresses');   // every test starts on the same page
  });

  test.afterEach(async ({ request }) => {      // request: an HTTP client for the API
    for (const id of created) {              // runs even when the test failed
      await request.delete(`/api/addresses/${id}`);
    }
    created.length = 0;
  });

  test('lists an address added through the API', async ({ page, request }) => {
    const res = await request.post('/api/addresses', { data: { city: 'Riyadh' } });
    created.push((await res.json()).id);
    await page.reload();
    await expect(page.getByText('Riyadh')).toBeVisible();
  });
});

Fixtures: वह setup जिसे test नाम से माँगता है

Fixture तीन चीज़ें साथ रखता है: setup, वह value जो test को मिलती है, और teardown। Test setup code ख़ुद बुलाने के बजाय fixture को उसके नाम से माँगता है। Playwright Test में page (browser का एक page) और request (API को सीधे call करने वाला HTTP client) built-in fixtures हैं, और अपने fixtures test.extend से जोड़े जाते हैं: await use(value) से पहले का code setup है, test use के दौरान चलता है, और उसके बाद का code teardown है, जो test pass हो या fail, चलता है। pytest में fixture @pytest.fixture से marked function है जिसे test अपने parameter में उसका नाम लिखकर माँगता है; वह value yield से देता है, और yield के बाद का code teardown है।

Hooks की तुलना में fixtures on demand चलते हैं: customer बनाने की लागत सिर्फ़ वे tests चुकाते हैं जो customer माँगते हैं। वे compose होते हैं: order fixture customer fixture माँग सकता है, और teardown उल्टे क्रम में चलता है, तो order अपने customer से पहले delete होता है। उनका scope होता है: default रूप से हर test के लिए, या ज़्यादा व्यापक रूप से shared, Playwright में हर worker के लिए या pytest में हर module या session के लिए, उन महँगी चीज़ों के लिए जिन्हें tests सिर्फ़ पढ़ते हैं। Playwright Test में fixture default रूप से lazily set up होता है, ठीक उस पहले hook या test से पहले जो उसे माँगता है: beforeEach hook जिस page को इस्तेमाल करता है वह उस hook के चलने से पहले तैयार होता है, जबकि जिस customer को सिर्फ़ test body माँगती है वह beforeEach hooks के बाद बनता है। Test-scoped fixtures afterEach hooks के बाद tear down होते हैं।

जो values मायने रखती हैं उन्हें दिखता रखें। Fixture को यह छिपाना चाहिए कि customer कैसे बनता है, यह नहीं कि test को कैसा customer चाहिए; अगर test customer के country जैसी किसी detail पर निर्भर है, तो उसे साफ़-साफ़ pass करें या साफ़ नाम वाला अलग fixture बनाएँ।

// fixtures.ts
import { test as base, expect } from '@playwright/test';
import { randomUUID } from 'node:crypto';

type Customer = { id: string; email: string };

export const test = base.extend<{ customer: Customer }>({
  customer: async ({ request }, use) => {
    // setup: a fresh customer for this test only
    const email = `sara+${randomUUID()}@example.com`;
    const res = await request.post('/api/customers', { data: { email } });
    const customer: Customer = await res.json();

    await use(customer);                     // the test runs here

    // teardown: runs after the test, passed or failed
    await request.delete(`/api/customers/${customer.id}`);
  },
});
export { expect };

// orders.spec.ts
import { test, expect } from './fixtures';

test('a new customer has no orders', async ({ request, customer }) => {
  const res = await request.get(`/api/customers/${customer.id}/orders`);
  expect(await res.json()).toEqual([]);
});

आज़माएँ: फ़ेक यूज़र जनरेटर

Cleanup: environment को वैसा ही छोड़ें जैसा मिला था

बचा हुआ data बेनुकसान नहीं होता। वह उन lists और search results को भर देता है जिन पर दूसरे tests assert करते हैं, unique constraints से टकराता है, और shared test environment में manual testers को उलझाता है। जो भी test कुछ बनाता है उसे उसे हटाने की योजना चाहिए, या ऐसा environment जो इस्तेमाल के बाद फेंक दिया जाए।

• Cleanup को after-hook या fixture teardown में रखें, कभी सिर्फ़ test body के आख़िर में नहीं।
• ठीक वही delete करें जो test ने बनाया, id से। कभी "example.com पर ख़त्म होने वाले email वाले हर customer को delete करो" जैसी broad query से cleanup न करें: shared environment में यह दूसरों का data और parallel runs का data भी मिटा देती है।
• Setup steps अलग-अलग रखें, ताकि एक fail हुआ step उससे पहले वाले steps का teardown न छोड़ दे; pytest documentation इसी वजह से हर fixture में एक ही state बदलने वाला action रखने की सलाह देता है।
• Teardown को पहले से हट चुके record के प्रति सहनशील बनाएँ, जैसे जब test ने ख़ुद उसे delete कर दिया हो, लेकिन cleanup की किसी और failure को दबाने के बजाय report करें।
• जहाँ setup इजाज़त दे, ख़ुद मिटने वाला data चुनें: उन integration tests में जो code under test के साथ एक ही database connection share करते हैं, हर test के बाद rollback होने वाला database transaction; हर run के लिए नया container या reset होने वाला environment; या हर run के लिए अलग tenant।
• बनाए गए data पर run prefix लगाएँ, जैसे AT-20261002-0412-, ताकि एक scheduled job crash हुए runs का छोड़ा हुआ data ढूँढकर हटा सके।

Worked example: एक test, discount codes की एक table

Requirement: "Code SAVE10 200.00 SAR या उससे ज़्यादा के orders पर 10% छूट देता है, और उससे कम पर minimum-order error के साथ reject होता है। Codes case-sensitive नहीं हैं। Expired या unknown code total नहीं बदलता और error दिखाता है।" छह लगभग एक जैसे tests लिखना वही steps छह बार copy करना है। Data-driven test एक test body रखता है और cases को एक table में ले जाता है; ISTQB glossary data-driven testing को ऐसी scripting technique बताती है जिसमें data files test data और expected results रखती हैं।

हर बड़ा runner यह support करता है। Jest और Vitest में test.each(rows)("$case", fn) हर row के लिए एक test बनाता है और case की value उसके title में डालता है। pytest में @pytest.mark.parametrize("row", rows) यही करता है, और pytest.param(row, id=...) हर case को नाम देता है। JUnit 5 में @ParameterizedTest के साथ @CsvFileSource(resources = "/discount-cases.csv", numLinesToSkip = 1) CSV file से rows पढ़ता है और header line छोड़ देता है। Playwright Test में test.each नहीं है; उसकी documentation loop में हर row के लिए एक test() बनाती है, और हर title unique होना चाहिए।

नीचे की table में सिर्फ़ inputs और expected results हैं, और हर expected total requirement से हाथ से निकाला गया है। Test file पढ़ता है और हर row को fixture से मिले नए cart के साथ चलाता है।

• हर row को एक name column दें। तब report "row 5 failed" की जगह "expired code failed" कहती है।
• Values ठीक वैसे लिखें जैसे system दिखाता है: 200.00, 200 नहीं। CSV में जिस value में comma, double quote या line break हो उसे double quotes में रखना चाहिए, और उसके अंदर का double quote दो बार लिखा जाता है (RFC 4180)।
• Pitfall, एक विशाल table: हर feature के columns वाली 200 rows की file review नहीं हो सकती, और हर बदलाव उसे छूता है। हर rule की अपनी table रखें, इतनी छोटी कि एक मिनट में पढ़ी जा सके, और rows का ढेर लगाने के बजाय boundary value analysis जैसी test design techniques से rows चुनें।
• Pitfall, data में छिपा test logic: click_apply_twice या skip_login जैसे columns table को ऐसा program बना देते हैं जिसे कोई test नहीं करता। जिन rows को अलग steps चाहिए, वे अलग tests हैं। यही बात उन expected values पर लागू होती है जिन्हें test product के ही formula से calculate करता है: तब formula का defect दोनों तरफ़ छिप जाता है।

data/discount-cases.csv
case,code,cart_total,expected_total,error
valid code,SAVE10,250.00,225.00,
lower-case code,save10,200.00,180.00,
minimum order exactly,SAVE10,200.00,180.00,
just below minimum,SAVE10,199.99,199.99,MIN_ORDER
expired code,OLD5,200.00,200.00,EXPIRED
unknown code,NOPE10,200.00,200.00,NOT_FOUND

test_discounts.py  (pytest: one test body, six reported tests)
import csv
from decimal import Decimal
import pytest

def load_cases(path):
    with open(path, newline="", encoding="utf-8") as f:
        return [pytest.param(row, id=row["case"]) for row in csv.DictReader(f)]

@pytest.mark.parametrize("row", load_cases("data/discount-cases.csv"))
def test_discount_code(cart, row):           # cart: a fixture, fresh per test
    cart.set_total(Decimal(row["cart_total"]))
    result = cart.apply_code(row["code"])
    assert result.total == Decimal(row["expected_total"])
    assert result.error == (row["error"] or None)

आज़माएँ: CSV डेटासेट जनरेटर आज़माएँ: CSV से JSON

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

संदर्भ

• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
• Playwright DocumentationMicrosoft (Playwright)Playwright का आधिकारिक दस्तावेज़ — Chromium, WebKit और Firefox चलाने वाला end-to-end टेस्ट फ़्रेमवर्क।
• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।
• RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) FilesIETF · 2005CSV के आम नियम: कॉमा सेपरेटर, CRLF लाइन एंड, और कॉमा, कोट या लाइन ब्रेक वाले फ़ील्ड की क्वोटिंग।