visual regression testing: मोबाइल पर मुफ़्त Playwright सेटअप

visual regression testing आपके पेजों के screenshots की तुलना स्वीकृत baseline images से करता है, और pixels बदलने पर test फ़ेल होता है। मोबाइल layouts के लिए यह वह पकड़ता है जो functional tests छोड़ देते हैं: 360px स्क्रीन से बाहर धकेला गया menu button, तीन लाइनों में टूटा heading, या tablet चौड़ाई पर गलत तरीके से सिकुड़ता card grid। आप इसे Playwright के toHaveScreenshot() से फ़ोन और tablet viewports पर मुफ़्त चला सकते हैं; फिर तय करें कि review workflow और cloud में cross-browser rendering के लिए कोई paid सेवा लेने लायक है या नहीं।

visual regression testing कैसे काम करता है

visual test के चार चरण हैं: baseline लें, किसी बदलाव के बाद फिर से लें, दोनों images का diff निकालें, और किसी व्यक्ति को फ़र्क स्वीकार या अस्वीकार करने दें। स्वीकृत बदलाव नया baseline बन जाते हैं।

diff में tools अलग होते हैं। pixel comparison (Playwright, BackstopJS) बदले हुए pixels गिनता है और आपके तय threshold से ऊपर होने पर फ़ेल करता है। Applitools सख्त pixel गिनती के बजाय अपने Visual AI से तुलना करता है, और Percy व Chromatic review dashboard वाली hosted सेवाएँ हैं। इन सबको स्थिर पेज चाहिए: अगर दो runs के बीच घड़ी, ad या animation बदलता है, तो test बिना असली कारण के फ़ेल होता है। नीचे का ज़्यादातर सेटअप इसी शोर को हटाने के बारे में है।

tools की तुलना

मुफ़्त, self-hosted स्थिति के लिए Playwright का built-in assertion काफ़ी है। अक्टूबर 2026 तक:

Percy हर browser और चौड़ाई पर हर पेज को एक screenshot गिनता है, इसलिए दो पेज, तीन फ़ोन और tablet चौड़ाइयों पर, और दो browsers में, पहले ही बारह इस्तेमाल हो जाते हैं। plan की कीमतें और सीमाएँ 25 अक्टूबर 2026 को हर vendor के pricing पेज से हैं, और ये अक्सर बदलती हैं।

फ़ोन viewports पर visual regression tests सेट करें

यह सेटअप @playwright/test 1.64 इस्तेमाल करता है (25 अक्टूबर 2026 को मौजूदा)। इसके लिए Node.js और एक साइट चाहिए जिसे test machine से खोला जा सके, स्थानीय या deploy हुई।

1. Playwright और उसके browsers इंस्टॉल करें:

   npm init playwright@latest

2. playwright.config.ts में mobile projects जोड़ें। हर device descriptor viewport, pixel ratio, user agent और touch support तय करता है, और engine चुनता है (iPhone 15 WebKit में चलता है, Pixel 7 Chromium में)।

   import { defineConfig, devices } from '@playwright/test';
   
   export default defineConfig({
     testDir: './visual',
     use: { baseURL: 'http://localhost:4321' },
     expect: {
       toHaveScreenshot: { maxDiffPixelRatio: 0.01 },
     },
     projects: [
       { name: 'pixel-7', use: { ...devices['Pixel 7'] } },
       { name: 'iphone-15', use: { ...devices['iPhone 15'] } },
       { name: 'tablet', use: { browserName: 'chromium', viewport: { width: 820, height: 1180 } } },
     ],
   });

   Playwright 1.64 में Pixel 7 descriptor का viewport 412 × 839 है, pixel ratio 2.625 पर, और iPhone 15 393 × 659 पर है, pixel ratio 3 पर। 1% का maxDiffPixelRatio एक शुरुआती मान है जिसे आपको tune करना है, कोई मानक नहीं।

3. test लिखें। केवल उन पेजों तक सीमित रखें जिनका layout सबसे ज़्यादा मायने रखता है:

   // visual/pages.spec.ts
   import { test, expect } from '@playwright/test';
   
   const pages = ['/', '/pricing', '/blog'];
   
   for (const path of pages) {
     test(`layout ${path}`, async ({ page }) => {
       await page.goto(path);
       await page.evaluate(async () => { await document.fonts.ready; });
       await expect(page).toHaveScreenshot({
         fullPage: true,
         mask: [page.locator('[data-testid="live-date"]')],
       });
     });
   }

4. baselines बनाएँ और commit करें:

   npx playwright test --update-snapshots

   Playwright हर test और project के लिए एक PNG सहेजता है, जिसके file name के अंत में project name और platform होता है (उदाहरण के लिए ...-iphone-15-linux.png)। *-snapshots folders commit करें।

5. हर pull request पर npx playwright test चलाएँ। असफल तुलना test को फ़ेल करती है; विफलता देखने के लिए npx playwright show-report से HTML report खोलें। अगर बदलाव जानबूझकर है, तो --update-snapshots से baselines अपडेट करें और उन्हें code बदलाव के साथ commit करें।

यहाँ defaults मदद करते हैं: toHaveScreenshot() तुलना से पहले तब तक रुकता है जब तक दो लगातार screenshots मेल न खाएँ, CSS animations और transitions बंद करता है, और text caret छुपाता है (Playwright API docs)। इसका scale विकल्प डिफ़ॉल्ट रूप से "css" है, यानी हर CSS pixel के लिए एक image pixel, इसलिए iPhone का baseline 1179 के बजाय 393 px चौड़ा होता है, और diffs तेज़ रहते हैं।

baselines लेने से पहले layout देखें

baseline वह रिकॉर्ड करता है कि जब आपने उसे लिया तब पेज कैसा दिखता था। अगर पहले screenshot में ही फ़ोन layout टूटा है, तो हर बाद का run उस bug की रक्षा करेगा। baselines बनाने से पहले, जिन चौड़ाइयों पर आप टेस्ट करेंगे, उन पर हर पेज देखें:

1. पेज को फ़ोन की चौड़ाई पर खोलें। Mobile View Extension tab को फ़ोन के user agent, screen size और pixel ratio के साथ दोबारा लोड करता है, और दो devices साथ-साथ दिखा सकता है, इसलिए आप एक ही URL के फ़ोन और tablet layouts एक साथ जाँच सकते हैं। यह localhost पर भी काम करता है।
2. पूरा पेज scroll करें, और navigation, टूटते headings, tables और sticky elements जाँचें।
3. जो मिले उसे ठीक करें, फिर --update-snapshots चलाएँ।

extension desktop Chrome के engine और mouse से रेंडर करता है, इसलिए यह layout दिखाता है, Safari का रेंडरिंग या touch व्यवहार नहीं। Playwright का WebKit project इस अंतर का कुछ हिस्सा भरता है, और असली iPhone बाकी। हाथ से जाँच की व्यापक दिनचर्या responsive design कैसे टेस्ट करें में है, और tickets के लिए एक-बार के captures वेबसाइट का मोबाइल screenshot कैसे लें में।

अस्थिर screenshot diffs ठीक करें

अस्थिर diffs उन चीज़ों से आते हैं जो runs के बीच बदलती हैं, इसलिए समाधान है उन्हें हर बार एक जैसा बनाना। आम स्रोत और हर एक के लिए क्या करें:

पहली पंक्ति उन failures को समझाती है जो बेतरतीब दिखते हैं। Playwright के दस्तावेज़ चेतावनी देते हैं कि रेंडरिंग host OS, version, settings और hardware के साथ बदल सकती है, और इसी वजह से platform snapshot नाम का हिस्सा है: Mac पर बना baseline (-darwin.png) Linux CI runner (-linux.png) पर इस्तेमाल नहीं होता। baselines के लिए एक environment चुनें। CI वाली उसी Docker image में npx playwright test --update-snapshots चलाने से यह फ़र्क का स्रोत खत्म हो जाता है।

सभी tests में शोर छुपाने के लिए stylePath फ़ाइल सबसे साफ़ जगह है:

/* visual/screenshot.css */
iframe, [data-testid="cookie-banner"] { visibility: hidden; }

import path from 'node:path';

await expect(page).toHaveScreenshot({
  stylePath: path.join(__dirname, 'screenshot.css'),
});

यही विकल्प config की expect.toHaveScreenshot में भी डाला जा सकता है, ताकि हर test पर लागू हो।

visual tests क्या नहीं पकड़ते

screenshot diff वह pixels जाँचता है जो आपके चलाए engines में बने। यह नहीं जाँचता कि button काम करता है, tap target काफ़ी बड़ा है, या असली फ़ोन के browser chrome और keyboard के साथ पेज कैसा व्यवहार करता है। Playwright का WebKit Safari के करीब है, पर iPhone पर iOS Safari नहीं है। functional tests को visual tests के साथ रखें, और असली browsers को cross-browser testing चेकलिस्ट से कवर करें।

suite को छोटा रखें। हर पेज, project और स्थिति समीक्षा के लिए images की संख्या बढ़ाती है। तीन से दस मुख्य templates (home, listing, detail पेज, form) दो फ़ोन आकारों और एक tablet आकार पर, यानी हर run में कुछ दर्जन images की समीक्षा। यह संख्या एक शुरुआती बिंदु है जिसे आप बदल सकते हैं (यह डिज़ाइन का फ़ैसला है), नियम नहीं।

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

क्या visual regression testing मुफ़्त है?

हाँ, open-source tools से। Playwright का toHaveScreenshot() और BackstopJS स्थानीय रूप से और आपके CI में बिना लागत चलते हैं। Percy, Chromatic और Applitools जैसी paid सेवाएँ hosted रेंडरिंग और review dashboards जोड़ती हैं, और अक्टूबर 2026 तक Percy और Chromatic के मुफ़्त plans में हर महीने 5,000 screenshots या snapshots मिलते हैं।

visual testing और screenshot testing में क्या फ़र्क है?

दोनों screenshot लेते हैं और उसे स्वीकृत baseline से तुलना करते हैं। फ़र्क तुलना में है: Playwright और BackstopJS बदले हुए pixels गिनते हैं, जबकि Applitools Visual AI इस्तेमाल करता है (ऊपर की tools तालिका देखें)।

मेरे Playwright screenshots CI में फ़ेल होते हैं, पर स्थानीय रूप से पास होते हैं, क्यों?

क्योंकि baselines एक अलग operating system या browser build पर बने थे। Playwright snapshot file name में platform शामिल करता है, और macOS और Linux पर fonts और anti-aliasing अलग होते हैं। baselines उसी Docker image में बनाएँ जो CI इस्तेमाल करता है।

visual tests में dynamic content कैसे नज़रअंदाज़ करूँ?

तारीखों और ads जैसे elements को ढकने के लिए mask विकल्प इस्तेमाल करें, या उन्हें stylePath stylesheet से छुपाएँ। जो पूरे क्षेत्र बदलते हैं, उनके लिए पूरे पेज के बजाय किसी स्थिर element का screenshot लें।