पेज ऑब्जेक्ट मॉडल

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

इस structure के बिना हर test वही locators और steps दोहराता है। जब कोई button rename होता है या form में एक step जुड़ता है, तो product ठीक चलने के बावजूद दर्जनों tests fail हो जाते हैं, और कोई testing की जगह पूरा दिन tests edit करने में लगाता है।

Page objects interface के बदलाव को एक class का fix बना देते हैं और test को उसी scenario की तरह पढ़ने लायक बनाते हैं जिसे वह check करता है। लेकिन ये खराब locator को अच्छा नहीं बनाते: page object के अंदर fragile locator भी fragile ही रहता है, बस अब एक जगह पर।

Page object में क्या आता है और क्या बाहर रहता है

Page object किसी page, या उसके हिस्से, को application की शब्दावली वाले API में लपेटता है। यह हर test के लिए उसी test के browser handle से बनता है, जैसे पिछले lesson का Playwright page fixture, और यही अकेला code है जो जानता है कि उसकी screen कैसे बनी है। Selenium documentation ऐसे rules देता है जो हर tool पर लागू होते हैं:

• Public methods वे services हैं जो page देता है, और उनके नाम user के इरादे पर रखे जाते हैं: placeOrder(), न कि clickBlueButton()।
• अंदरूनी बातें अंदर रहती हैं: locators, frames, clicks और waits का क्रम। Test को कभी selector की ज़रूरत नहीं पड़ती।
• Assertions नहीं: method data या element लौटाता है, और क्या सही है यह test तय करता है। Fowler दोनों राय सामने रखकर ख़ुद भी assertions बाहर रखना पसंद करते हैं; जो checks कई tests में दोहराए जाते हैं, वे shared assertion helpers में जा सकते हैं। अंदर सिर्फ़ एक check आता है: कि सही page load हुआ है, जो object बनते समय होता है। JavaScript का constructor await नहीं कर सकता, इसलिए Playwright के page objects यह check उस method में करते हैं जो page तक पहुँचाता है, जैसा नीचे placeOrder() करता है।
• Navigation अगला page object लौटाता है: cart.checkout() एक CheckoutPage लौटाता है, इसलिए return types ही flow का documentation बन जाते हैं।
• एक ही action के अलग नतीजे अलग methods हैं: signIn() account page लौटाता है, signInExpectingError() sign-in page।

Component objects: दोहराए जाने वाले हिस्से के लिए एक class

Screen के कई हिस्से pages नहीं होते: search और cart count वाला header, orders table की एक row, date picker, dialog। Selenium documentation इनकी classes को page component objects कहता है; Fowler का उदाहरण एक album list है जिसमें album objects होते हैं। Page objects इन्हें जोड़कर बनते हैं: CheckoutPage के पास एक header है, और OrdersPage किसी order number के लिए एक OrderRow लौटाता है।

मुख्य technique root है: component object को उसके अपने container का locator मिलता है और वह सिर्फ़ उसी के अंदर खोजता है, इसलिए एक class हर row के लिए काम करती है, और order('ORD-2026-000184').cancel() बगल वाली row का button click नहीं कर सकता। Playwright locator को filter({ hasText }) से छोटा करता है और उसके अंदर getByRole से खोजता है; Selenium parent element पर findElement call करता है।

// components/order-row.ts: one class for every row of the orders table
import type { Locator } from '@playwright/test';

export class OrderRow {
  constructor(private readonly root: Locator) {}    // the row's own element

  status(): Locator {
    return this.root.getByTestId('order-status');
  }

  async cancel(): Promise<void> {
    await this.root.getByRole('button', { name: 'Cancel order' }).click();
  }
}

// pages/orders-page.ts: the page composes the component
import type { Page } from '@playwright/test';
import { OrderRow } from '../components/order-row';

export class OrdersPage {
  constructor(private readonly page: Page) {}

  order(orderNumber: string): OrderRow {
    const row = this.page.getByRole('row').filter({ hasText: orderNumber });
    return new OrderRow(row);
  }
}

// in a test
const ordersPage = new OrdersPage(page);
const row = ordersPage.order('ORD-2026-000184');
await row.cancel();
await expect(row.status()).toHaveText('Cancelled');

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

Worked example: checkout test का refactoring

एक online store में बारह tests checkout से गुज़रते हैं, और हर एक अच्छे, user-facing locators के साथ नीचे वाले पहले test के steps दोहराता है।

Refactoring के बाद steps page objects में हैं, cart count एक Header component में, और test सिर्फ़ scenario और expected नतीजा बताता है। CheckoutPage submit करने के दो नतीजों को दो methods से दिखाता है, जो एक private submit() share करते हैं।

• "Place order" का नाम "Pay now" हो गया: पहले 12 tests बदलते; अब CheckoutPage की एक line।
• Cart count की test id बदल गई या वह header के अंदर किसी दूसरी जगह चला गया: सिर्फ़ Header.cartCount() बदलता है, कोई test नहीं।

// BEFORE: tests/checkout.spec.ts (these steps are copied into 12 tests)
test('customer pays with a saved address', async ({ page }) => {
  await page.goto('/cart');
  await page.getByRole('button', { name: 'Checkout' }).click();
  await page.getByRole('radio', { name: 'Home' }).check();
  await page.getByRole('button', { name: 'Place order' }).click();
  await expect(page.getByRole('heading', { level: 1 }))
    .toHaveText('Thank you for your order');
  await expect(page.getByRole('banner').getByTestId('cart-count')).toHaveText('0');
});

// AFTER: pages/checkout-page.ts (CartPage, ConfirmationPage and the
// Header component are written the same way; imports omitted)
export class CheckoutPage {
  readonly header: Header;

  constructor(private readonly page: Page) {
    this.header = new Header(page);
  }

  async placeOrder(address: string): Promise<ConfirmationPage> {
    await this.submit(address);
    await this.page.waitForURL('**/order/confirmation');   // the page-loaded check
    return new ConfirmationPage(this.page);
  }

  async placeOrderExpectingError(address: string): Promise<CheckoutPage> {
    await this.submit(address);
    return this;                      // stays on checkout, which shows the error
  }

  errorMessage(): Locator {
    return this.page.getByRole('alert');
  }

  private async submit(address: string): Promise<void> {
    await this.page.getByRole('radio', { name: address }).check();
    await this.page.getByRole('button', { name: 'Place order' }).click();
  }
}

// AFTER: tests/checkout.spec.ts
test('customer pays with a saved address', async ({ page }) => {
  const cart = await new CartPage(page).open();
  const checkout = await cart.checkout();
  const confirmation = await checkout.placeOrder('Home');
  await expect(confirmation.heading()).toHaveText('Thank you for your order');
  await expect(confirmation.header.cartCount()).toHaveText('0');
});

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

Screenplay pattern: actors, tasks और questions

Page objects test code को screens के इर्द-गिर्द व्यवस्थित करते हैं; Screenplay pattern उसे system इस्तेमाल करने वाले लोगों और उनके लक्ष्यों के इर्द-गिर्द रखता है। Java के लिए Serenity BDD और Serenity/JS इसे implement करते हैं; Serenity/JS की शब्दावली में इसके concepts नीचे हैं।

क्योंकि एक actor के पास कई abilities हो सकती हैं, एक ही scenario API से order बना सकता है और browser में उसे check कर सकता है।

• Actors: लोग या external systems जो system under test से interact करते हैं, जैसे लैला, जो दोबारा खरीदारी करने आई customer है।
• Abilities: actor जिन libraries का इस्तेमाल करता है उनके पतले wrappers, जैसे browser के लिए Playwright या REST API के लिए HTTP client।
• Interactions: एक interface के ज़रिए low-level activities, जैसे button click करना या request भेजना।
• Tasks: activities का क्रम जो business का एक step बनाता है, जैसे cart खोलने, address चुनने और submit करने से बना PlaceOrder।
• Questions: जानकारी निकालते हैं, जैसे page पर दिखा या API response में आया order status; test उसी जवाब पर assert करता है।

Anti-patterns जो page objects को बोझ बना देते हैं

इनमें से हर एक suite को बदलना मुश्किल बनाता है।

• Page objects के अंदर assertions, जैसे verifyOrderTotal(): test अब नहीं दिखाता कि वह क्या उम्मीद करता है, और अलग-अलग उम्मीद वाले tests वह method share नहीं कर पाते।
• God page: सैकड़ों lines का BasePage जिसे हर page inherit करता है, या पूरे single-page app के लिए एक ही class। Deep inheritance की जगह छोटी classes और composition (page के पास header है) चुनें।
• Steps expose करना: tests page object के elements को एक-एक करके click और fill करते हैं, तो flow फिर से test में आ जाता है। Retry करने वाले assertion के लिए locator लौटाना ठीक है, जैसा Playwright के examples करते हैं।
• Methods में fixed sleeps: placeOrder() के अंदर waitForTimeout(3000) उसे call करने वाले हर test को धीमा करता है और धीमे दिन फिर भी fail होता है।
• Flags से चलने वाले methods: checkout(true, false, 'Home') कई flows को एक नाम के पीछे छिपा देता है।
• Shared state: static driver या पूरे suite के लिए एक ही page object parallel runs तोड़ देता है; page objects हर test के लिए या fixture से बनाएँ।

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

संदर्भ

• Page object models — SeleniumSelenium ProjectPage object पैटर्न: हर पेज या कंपोनेंट के लिए एक क्लास जो locator छिपाती है और टेस्ट को चाहिए वे एक्शन देती है, जिससे दोहराव घटता है।
• Page Object (Martin Fowler)martinfowler.com · 2013Page object पैटर्न: पेज को application-specific API में लपेटना ताकि टेस्ट सीधे HTML को न छुएँ, और assertions page object में नहीं बल्कि टेस्ट में रखना।
• Locators — PlaywrightMicrosoft (Playwright)Playwright एलिमेंट कैसे ढूँढता है, locator दोबारा resolve होकर अपने-आप इंतज़ार क्यों करते हैं, और role-आधारित locator पहले क्यों सुझाए जाते हैं।
• Best Practices — PlaywrightMicrosoft (Playwright)यूज़र को दिखने वाला व्यवहार टेस्ट करें, टेस्ट अलग-थलग रखें, मज़बूत locator और web-first assertions अपनाएँ, और trace से डिबग करें।