टेस्ट आइसोलेशन और पैरलल एक्ज़ीक्यूशन

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

एक-दूसरे पर निर्भर tests ऐसे results देते हैं जिन पर कोई भरोसा नहीं कर सकता। कोई test पूरे run में सिर्फ़ इसलिए pass होता है क्योंकि पहले वाले test ने वह order बनाया जिसे वह पढ़ता है, और जब कोई उसे अकेले चलाता है या worker बढ़ाता है तो वह fail हो जाता है; दो tests एक ही पल में एक ही user को edit करते हैं और उनमें से एक हर बीस runs में एक बार fail होता है। ऐसे failures product defects जैसे दिखते हैं, जाँच में घंटों खा जाते हैं और team को लाल builds पढ़ने की बजाय दोबारा चलाना सिखा देते हैं। Martin Fowler isolation की कमी को non-deterministic tests का एक आम कारण बताते हैं।

Speed दूसरा पहलू है। एक घंटे वाला suite कम बार चलता है और तब report करता है जब developer किसी और काम पर जा चुका होता है। Parallel execution बढ़ते suite को इतना तेज़ रखता है कि वह हर change पर चल सके, और यह तभी काम करता है जब tests isolated हों। Isolation bug report में भी मदद करता है: जो test अकेले, हर बार, अपने data के साथ fail होता है, वह developer के लिए तैयार reproduction है।

Isolation और shared state की समस्याएँ

Isolated test अपनी शुरुआती state खुद नियंत्रित करता है: वह अपनी ज़रूरत की चीज़ें बनाता है या fixture से पाता है, और सिर्फ़ उसी data पर assert करता है जो उसने बनाया या जिसे कोई test नहीं बदलता। Playwright की best practices कहती हैं कि हर test अपने storage, cookies और data के साथ स्वतंत्र रूप से चले; Cypress पिछले tests की state पर निर्भर tests को anti-pattern मानता है।

Shared state वह सब कुछ है जिसे एक test बदल सकता है और दूसरा test देख सकता है। Read-only data, जैसे ऐसा product catalogue जिसे कोई test edit नहीं करता, share करना सुरक्षित है; shared mutable state नहीं। इलाज यह है कि हर test को, या कम से कम हर worker को, जो वह बदलता है उसकी अपनी copy दें, और वह state test की शुरुआत में बनाएँ। Martin Fowler cleanup पर भरोसा करने की बजाय शुरुआती state दोबारा बनाने को बेहतर मानते हैं: cleanup fail हो तो कोई दूसरा test fail होता है, bug से दूर। Shared mutable state पाँच जगह छिपती है:

• Server data: कई tests का इस्तेमाल किया एक account, cart, order या coupon। एक test वह cart खाली कर देता है जिसे दूसरा जाँच रहा है; single-use coupon सिर्फ़ उस test के लिए काम करता है जो पहले पहुँचे।
• Order dependencies: test B वह order पढ़ता है जो test A ने बनाया। B सामान्य क्रम में pass होता है, और अकेले, shuffled क्रम में या किसी दूसरे worker पर चलने पर fail होता है।
• In-memory state: module-level variable, singleton (पूरे program में shared एक object), cache, mocked clock या कोई "current user" जिसे एक test set करता है और कभी reset नहीं करता। Worker processes memory share नहीं करते, लेकिन एक ही worker के tests करते हैं, और JUnit 5 के parallel threads भी करते हैं।
• Browser state: cookies, local storage और signed-in session। सिर्फ़ पढ़ने वाले tests के लिए saved sign-in ठीक है; जो test sign out करता है या profile edit करता है, उसे अपना session चाहिए।
• मशीन और environment के resources: downloads/report.csv जैसा fixed file path, fixed port, एक shared mailbox, rate-limited sandbox API, site-wide feature flag।

आज़माएँ: फ़ेक ईमेल जनरेटर

Runners tests को parallel में कैसे चलाते हैं

Playwright Test, Jest और pytest-xdist में worker operating system का एक अलग process है जो tests को एक के बाद एक चलाता है। चार workers हों तो एक ही पल में चार tests चलते हैं। उनकी memory अलग होती है, लेकिन test environment, उसका database, disk पर files और network ports अलग नहीं होते। Runners इसमें अलग हैं कि वे default रूप से क्या बाँटते हैं, और हर worker को उसके अपने resources कैसे दिए जाते हैं:

• Playwright Test test files को parallel में चलाता है; एक file के अंदर के tests उसी worker में क्रम से चलते हैं, जब तक आप fullyParallel: true या test.describe.configure({ mode: 'parallel' }) set न करें। संख्या config में workers से या --workers से तय करें। हर test को नया browser context मिलता है, यानी fresh private window जैसा isolated browser profile, जिसकी अपनी cookies और storage होती हैं, और किसी failure के बाद Playwright worker को नए process से बदल देता है।
• pytest को pytest-xdist plugin चाहिए: pytest -n 4, या हर CPU पर एक worker के लिए -n auto। worker_id fixture gw0, gw1 आदि लौटाता है।
• Jest test files को worker processes में बाँटता है और एक file के tests क्रम से चलाता है; --runInBand सब कुछ एक process में serially चलाता है।
• JUnit 5 default रूप से tests को एक thread में क्रम से चलाता है। Parallel execution opt-in है: configuration parameter junit.jupiter.execution.parallel.enabled=true इसे चालू करता है, लेकिन tests तब भी एक के बाद एक चलते हैं जब तक आप उन्हें concurrent न बनाएँ, जैसे junit.jupiter.execution.parallel.mode.default=concurrent से। Parallel tests एक ही JVM के threads होते हैं, इसलिए वे static fields और singletons share करते हैं। @ResourceLock बताता है कि tests ऐसा shared resource इस्तेमाल करते हैं जिसे synchronised access चाहिए।
• Per-worker resources: जो चीज़ हर test के लिए नहीं बन सकती, वह हर worker को अलग दें। Playwright का testInfo.parallelIndex 0 से workers − 1 तक जाता है, इसलिए worker 2 run से पहले तैयार pool से account 2 ले सकता है।
• Serial अपवाद: जो test कोई global चीज़ बदलता है, जैसे VAT rate या site-wide feature flag, वह दूसरे tests के साथ नहीं चल सकता। पूरे suite को serial बनाने की बजाय उसे --workers=1 वाले छोटे अलग run में ले जाएँ, और उसे ऐसे schedule करें कि वह उसी environment पर main run के साथ-साथ कभी न चले।

Sharding: suite को कई मशीनों में बाँटना

Workers एक ही मशीन का CPU और memory share करते हैं, इसलिए मशीन व्यस्त हो जाने के बाद और workers जोड़ने से फ़ायदा नहीं होता। Sharding suite को कई मशीनों में बाँटती है: हर CI job एक shard चलाता है, यानी tests का एक तय हिस्सा, और हर shard फिर भी कई workers इस्तेमाल कर सकता है। npx playwright test --shard=2/4 चार में से दूसरा हिस्सा चलाता है; Jest और Vitest भी यही --shard option लेते हैं।

फ़ायदा balance तय करता है, क्योंकि run तब ख़त्म होता है जब सबसे धीमा shard ख़त्म होता है। fullyParallel के बिना Playwright पूरी files shards को देता है, इसलिए एक लंबी file एक shard को व्यस्त रख सकती है जबकि बाक़ी इंतज़ार करते हैं; इसके साथ अलग-अलग tests बाँटे जाते हैं। हर shard सिर्फ़ अपने tests की report देता है: Playwright हर shard के लिए blob report लिखता है, और आख़िरी job उन्हें एक report में merge करता है, उसके बाद ही कोई run पर फ़ैसला करे।

Shards isolation का अपना ख़तरा भी लाते हैं। वे अलग मशीनों पर चलते हैं लेकिन आम तौर पर एक ही test environment पर, और worker indexes हर shard में दोहराए जाते हैं। इसलिए qa+w0@example.com जैसा नाम, या pool का account 0, एक साथ चार workers इस्तेमाल करते हैं; shard number जोड़ें, या UUID जैसा random हिस्सा इस्तेमाल करें।

# Four CI jobs start at the same time, one shard each
npx playwright test --shard=1/4 --reporter=blob
npx playwright test --shard=2/4 --reporter=blob
npx playwright test --shard=3/4 --reporter=blob
npx playwright test --shard=4/4 --reporter=blob

# A final job downloads the four blob reports into one folder and merges them
npx playwright merge-reports --reporter html ./all-blob-reports

आज़माएँ: UUID जनरेटर

Worked example: तीन tests जो सिर्फ़ parallel में fail होते हैं

120 browser tests वाला एक checkout suite एक worker के साथ 24 मिनट लेता है। Team fullyParallel: true और चार workers set करती है; run 7 मिनट का हो जाता है, लेकिन अब तीन tests कुछ runs में fail होते हैं। पूरा suite --workers=1 के साथ अब भी हर बार pass होता है, इसलिए संभावित कारण tests के बीच टकराव है, product नहीं।

हर test qa.shared@example.com से sign in करता है। "Cart total" 150.00 और 80.00 के items जोड़कर 230.00 की उम्मीद करता है, लेकिन कभी-कभी 0.00 देखता है, क्योंकि दूसरे worker पर चल रहा "empty cart" वही cart खाली कर देता है। "Order history" उम्मीद करता है कि list में तीन orders दिखें, वही जो उसकी file के तीन ordering tests बनाते हैं; यह सिर्फ़ इसलिए pass होता था कि यह उसी worker में उनके बाद चलता था, और अकेले चलाने पर भी fail होता है। "Download invoice" downloads/invoice.pdf में save करता है, जहाँ किसी दूसरे worker की invoice उसे overwrite कर सकती है।

• हर worker worker-scoped fixture में अपना नया account बनाता है, email में UUID के साथ, ताकि shards भी न टकराएँ।
• एक worker के tests उस account को फिर भी एक के बाद एक share करते हैं, इसलिए beforeEach hook हर test से पहले cart खाली करता है, पिछले test पर भरोसा करने की बजाय।
• "Order history" API से अपने तीन orders बनाता है और उनकी ids पर assert करता है, कुल गिनती पर नहीं।
• Invoice test.info().outputPath() में save होती है, जो हर test का अपना folder है।
• Fix की पुष्टि चार workers पर --repeat-each=10 से होती है, क्योंकि एक green run बहुत कम साबित करता है।

// fixtures.ts: one fresh account per worker process
import { test as base } from '@playwright/test';
import { randomUUID } from 'node:crypto';

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

export const test = base.extend<{}, { account: Account }>({
  account: [async ({ playwright }, use) => {
    const api = await playwright.request.newContext({ baseURL: process.env.BASE_URL });
    const email = `qa+${randomUUID()}@example.com`;   // unique in every shard
    const res = await api.post('/api/test-accounts', { data: { email } });
    const account: Account = await res.json();
    await use(account);                                // shared by this worker's tests
    await api.delete(`/api/test-accounts/${account.id}`);
    await api.dispose();
  }, { scope: 'worker' }],
});

// cart.spec.ts
import { test } from './fixtures';

test.beforeEach(async ({ request, account }) => {
  await request.delete(`/api/test-accounts/${account.id}/cart`);   // start empty
});

test('download invoice', async ({ page, account }) => {
  // ...sign in as account.email and place an order...
  const downloading = page.waitForEvent('download');
  await page.getByRole('button', { name: 'Download invoice' }).click();
  await (await downloading).saveAs(test.info().outputPath('invoice.pdf'));
});

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

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

संदर्भ

• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।
• Playwright DocumentationMicrosoft (Playwright)Playwright का आधिकारिक दस्तावेज़ — Chromium, WebKit और Firefox चलाने वाला end-to-end टेस्ट फ़्रेमवर्क।
• Best Practices — PlaywrightMicrosoft (Playwright)यूज़र को दिखने वाला व्यवहार टेस्ट करें, टेस्ट अलग-थलग रखें, मज़बूत locator और web-first assertions अपनाएँ, और trace से डिबग करें।
• Best Practices — CypressCypress.ioसमर्पित एट्रिब्यूट से एलिमेंट चुनने, फ़िक्स्ड wait से बचने और टेस्ट को स्वतंत्र रखने पर Cypress की गाइडेंस।