टेस्ट ऑटोमेशन के लिए प्रोग्रामिंग

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

जो टेस्टर test code नहीं पढ़ सकता, वह यह नहीं बता सकता कि fail हुए test ने product में defect पकड़ा है या उसमें खुद defect है, और वह साथी के change की review भी नहीं कर सकता। इससे बुरा यह कि कुछ test defects test को pass करा देते हैं जबकि product टूटा है: भूला हुआ await assertion को page बदलने से पहले चला देता है, और log करके आगे बढ़ जाने वाला try/catch fail हुई जाँच को runner से छिपा देता है। ऐसे tests से भरी suite green दिखाती है और कुछ नहीं पकड़ती।

Test code हर change पर चलता है, इसलिए उसकी structure तय करती है कि user interface में छोटे बदलाव की कीमत क्या होगी: एक file में एक edit, या हर test में वही edit।

Control flow: if, for...of और arrow functions

Test code में भी वही decisions और loops होते हैं जो किसी भी program में, पर कम। if/else एक रास्ता चुनता है, जैसे cookie banner तभी बंद करना जब वह दिखे। for...of एक array के हर item के लिए वही steps एक बार चलाता है, और test code में array में test-data objects होते हैं: हर case के लिए एक object, जिसमें inputs और expected result हों। Loop हर object के लिए एक named test बनाता है, इसलिए failure बताती है कि कौन-सा case fail हुआ।

Arrow function, (a, b) => a + b, value के रूप में लिखा गया function है। Runners functions को arguments के रूप में लेते हैं, इसलिए हर test की body एक function है जो callback के रूप में pass होता है, आमतौर पर arrow function: test('name', async () => { ... })। Runner इस callback को रखता है और बाद में call करता है; file load होते समय इसकी body नहीं चलती। नीचे के async ({ page }) => { ... } में runner callback को एक object देता है, और { page } उसकी page property निकाल लेता है (इसे destructuring कहते हैं): यह इस test का browser page है।

• Expected message को data object में लिखें; उसे test के अंदर if से न निकालें, वरना test bug से सहमत हो सकता है।
• for...of values पर चलता है, for...in object की keys पर; test code में लगभग हमेशा for...of चाहिए।

const cases = [
  { email: 'sara@example.com', password: 'Correct-1', message: 'Welcome, Sara' },
  { email: 'sara@example.com', password: 'wrong', message: 'Invalid login' },
];

for (const c of cases) {
  test('login: ' + c.message, async ({ page }) => {   // one test per data object
    // the steps use c.email, c.password and c.message
  });
}

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

Modules: export और import

Module एक file है जो बताती है कि वह क्या share करती है। export class LoginPage नाम को उपलब्ध कराता है; import { LoginPage } from './pages/login-page' उसे दूसरी file में लाता है। कुछ भी संयोग से share नहीं होता: बिना export वाला नाम अपनी file में private रहता है, और जिस file को कुछ चाहिए उसे import करना पड़ता है।

इसीलिए spec file दो तरह के import से शुरू होती है: runner package से test और expect, यानी वे functions जो test register करते और नतीजा जाँचते हैं, और आपकी अपनी files से page objects और data। तब spec एक scenario की तरह पढ़ी जाती है और locators (किसी element को ढूँढने वाले expressions, जैसे getByLabel('Email')) एक जगह रहते हैं: login form बदलने पर आप page object बदलते हैं और उसे import करने वाली हर spec ठीक हो जाती है।

• Relative paths ./ या ../ से शुरू होते हैं; @playwright/test जैसे package names नहीं।
• import type { Page } सिर्फ़ type import करता है; compiler उसे output से हटा देता है।

// pages/login-page.ts
export class LoginPage { /* ... */ }

// login.spec.ts
import { test, expect } from '@playwright/test';   // the runner
import { LoginPage } from './pages/login-page';     // your page object

Classes और instances: page object की shape

Class ऐसे objects का template है जो fields (data) और methods (functions) share करते हैं। new LoginPage(page) एक instance बनाता है: यह constructor चलाता है, जो browser page को एक field में रखता है, और ऐसा object लौटाता है जिसके methods this के ज़रिए उस field तक पहुँचते हैं। हर test अपना instance बनाता है, इसलिए कोई दो tests एक page object share नहीं करते।

Page object ठीक यही है: page के लिए एक field, उसे लेने वाला constructor, और screen पर यूज़र जो-जो कर सकता है उसके लिए एक-एक method, जैसे open() और signIn(email, password)। Methods locators और clicks छिपाते हैं; test उन्हें नाम से call करता है। Selenium documentation एक नियम जोड़ता है जो हर language में लागू है: page objects में assertions न हों, क्योंकि क्या सही है यह test तय करता है; page object के अंदर वह सिर्फ़ एक जाँच की अनुमति देता है, कि page सही से load हुआ है।

• private readonly page का मतलब है कि field को सिर्फ़ class के अंदर का code इस्तेमाल करता है और constructor के बाद कोई उसे दोबारा assign नहीं करता; जो test login.page तक पहुँचे उसे compiler error मिलता है।

import type { Page } from '@playwright/test';

export class LoginPage {
  private readonly page: Page;              // a field

  constructor(page: Page) {                 // runs once, on new
    this.page = page;                       // this = the instance being built
  }

  async open(): Promise<void> {             // a method
    await this.page.goto('/login');         // relative to baseURL in the config
  }

  async signIn(email: string, password: string): Promise<void> {
    await this.page.getByLabel('Email').fill(email);
    await this.page.getByLabel('Password').fill(password);
    await this.page.getByRole('button', { name: 'Sign in' }).click();
  }
}

Async code और errors: हर चीज़ await करें, कुछ भी निगलें नहीं

हर browser action (goto, fill, click) और हर retry करने वाला assertion एक promise लौटाता है, क्योंकि काम browser में होता है और समय लेता है। जो function इंतज़ार करता है वह async घोषित होता है; उसके अंदर await promise settle होने तक रुकता है, फिर value के साथ आगे बढ़ता है या error throw करता है। नियम: promise लौटाने वाले हर action और हर assertion को await करें।

JavaScript test flaky हो तो सबसे पहले ढूँढी जाने वाली चीज़ों में missing-await bug है। बिना await के login.open() navigation शुरू करके तुरंत अगली line चला देता है, तो page को एक बार पढ़ने वाली जाँच पुराना page पढ़ सकती है; और अगर बिना await वाली call आख़िरी action हो, तो test function उसके पूरा होने से पहले ख़त्म हो सकता है, और test में कुछ भी उसका नतीजा नहीं जाँचता। Compiler ऐसे promise पर कुछ नहीं कहता जिसका कोई इंतज़ार नहीं करता; linter (code में जोखिम भरे patterns जाँचने वाला tool, जैसे ESLint) @typescript-eslint/no-floating-promises जैसे rule से इसकी चेतावनी देता है, और type भी उसे पकड़ सकता है, जैसा worked example में दिखेगा।

Throw हुआ error ही test के fail होने का तरीका है: fail हुआ expect throw करता है, और runner उस error को result के रूप में दर्ज करता है। try/catch/finally को इसका सम्मान करना चाहिए। finally उस cleanup के लिए रखें जो दोनों हालात में चलना चाहिए, और catch सिर्फ़ तब जब error ही वह चीज़ हो जिसे आप test कर रहे हैं, फिर उस पर assert करें। Log करके आगे बढ़ जाने वाला catch fail हुई जाँच को pass बना देता है। असली cleanup आमतौर पर वह data हटाता है जो test ने बनाया; नीचे की clearCookies call सिर्फ़ यह दिखाती है कि cleanup कहाँ जाता है, क्योंकि Playwright हर test को पहले से fresh cookies के साथ शुरू करता है।

// Wrong: the navigation is started but not awaited
login.open();
expect(await page.title()).toBe('Sign in');      // may read the previous page

// Wrong: the error is swallowed, so the runner records a pass
try {
  await expect(page.getByTestId('message')).toHaveText('Welcome, Sara');
} catch (error) {
  console.log('check failed', error);            // the test still passes
}

// Right: await every action, let a failed check throw, clean up in finally
await login.open();
try {
  await login.signIn('sara@example.com', 'Correct-1');
  await expect(page.getByTestId('message')).toHaveText('Welcome, Sara');
} finally {
  await page.context().clearCookies();           // runs on pass and on fail
}

Worked example: arrange-act-assert रूप में एक test file

नीचे login.spec.ts है, जो classes वाले section की LoginPage class इस्तेमाल करती है और इस पाठ की हर feature को label करती है। हर test arrange-act-assert में चलता है: state arrange करें (page object बनाएँ, page खोलें), act करें (sign in), assert करें (message जाँचें)। हर test में एक act और एक focused assertion report को पढ़ने लायक रखता है।

email: string, qty: number और Promise<void> जैसी annotations TypeScript types हैं; Promise<T> को ऐसे पढ़ें: एक promise जो T type की value देगा, और void का मतलब है कोई value नहीं। Run time पर ये कुछ नहीं बदलतीं। Compiler इन्हें जाँचता है और मेल न खाने वाली हर call की रिपोर्ट करता है: signIn(c.email, 123) क्योंकि number string नहीं है, login.signin(...) क्योंकि यह method है ही नहीं, और const title = page.title(); title.includes('x') क्योंकि title एक Promise<string> है जिसमें includes नहीं होता: type ने missing await पकड़ लिया। Playwright types को बिना जाँचे हटा देता है और tests फिर भी चला देता है, इसलिए ये errors सिर्फ़ आपके editor में और npx tsc --noEmit (सिर्फ़ जाँच, कोई file नहीं लिखी जाती) चलाने पर दिखती हैं, जिसे टीमें tests से पहले एक step के रूप में जोड़ती हैं।

यह file चलती कैसे है? Test runner एक program है जिसे आप command line से शुरू करते हैं (अगला पाठ)। यह *.spec.ts जैसे pattern से मेल खाती files ढूँढता है और हर एक को load करता है, जिससे top-level code चलता है: loop test(...) call करता है और runner callbacks रख लेता है। फिर यह हर callback को नया page देकर call करता है, लौटे promise का इंतज़ार करता है, और fulfil होने पर pass, और reject होने पर error व stack trace के साथ fail दर्ज करता है।

• Selenium users के लिए: import Java का import या Python का from ... import है; fields और constructor वाली class दोनों में है (Python में __init__ और self, Java में class के नाम वाला constructor और this); Java और Python bindings synchronous हैं, इसलिए वहाँ await नहीं: हर call driver के जवाब तक रुकती है, और वहाँ का जोखिम missing explicit wait है।

भाग 1:1import { test, expect } from '@playwright/test';
import { LoginPage } from './pages/login-page';

भाग 2:2const cases = [
  { email: 'sara@example.com', password: 'Correct-1', message: 'Welcome, Sara' },
  { email: 'sara@example.com', password: 'wrong', message: 'Invalid login' },
];

भाग 3:3for (const c of cases) {
  भाग 4:4test('login: ' + c.message, async ({ page }) => {
    const login = भाग 5:5new LoginPage(page);
    भाग 6:6await login.open();
    await login.signIn(c.email, c.password);
    भाग 7:7await expect(page.getByTestId('message')).toHaveText(c.message);
  });
}

import type { Page } from '@playwright/test';

भाग 8:8export class LoginPage {
  भाग 9:9private readonly page: Page;
  constructor(page: Page) { this.page = page; }

  async open(): Promise<void> { await this.page.goto('/login'); }

  भाग 10:10async signIn(email: string, password: string): Promise<void> {
    await this.page.getByLabel('Email').fill(email);
    await this.page.getByLabel('Password').fill(password);
    await this.page.getByRole('button', { name: 'Sign in' }).click();
  }
}

// login.spec.ts
import { test, expect } from '@playwright/test';   // module: the runner
import { LoginPage } from './pages/login-page';     // module: our page object

const cases = [                                     // test data: one object per case
  { email: 'sara@example.com', password: 'Correct-1', message: 'Welcome, Sara' },
  { email: 'sara@example.com', password: 'wrong', message: 'Invalid login' },
];

for (const c of cases) {                            // control flow: one test per object
  test('login: ' + c.message, async ({ page }) => { // async arrow function as callback
    // Arrange
    const login = new LoginPage(page);              // class -> instance
    await login.open();                             // await: a browser action
    // Act
    await login.signIn(c.email, c.password);        // typed: (string, string)
    // Assert
    await expect(page.getByTestId('message')).toHaveText(c.message);
  });
}

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

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

संदर्भ

• ECMAScript® Language Specification (ECMA-262)Ecma International / TC39JavaScript भाषा का मानक, जिसमें RegExp का व्याकरण और अर्थ, JSON.parse/JSON.stringify और Date ऑब्जेक्ट शामिल हैं।
• JavaScript — MDNMDN Web Docs (Mozilla)MDN की JavaScript गाइड और reference: भाषा का सिंटैक्स, types, objects और built-ins, जैसे ब्राउज़र उन्हें लागू करते हैं।
• Playwright DocumentationMicrosoft (Playwright)Playwright का आधिकारिक दस्तावेज़ — Chromium, WebKit और Firefox चलाने वाला end-to-end टेस्ट फ़्रेमवर्क।
• Page object models — SeleniumSelenium ProjectPage object पैटर्न: हर पेज या कंपोनेंट के लिए एक क्लास जो locator छिपाती है और टेस्ट को चाहिए वे एक्शन देती है, जिससे दोहराव घटता है।