साइप्रेस

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

Tool का design तय करता है कि कौन-से tests आसान हैं और कौन-से तकलीफ़देह। Cypress queries और assertions को अपने-आप retry करता है और हर command को page के snapshot के साथ दिखाता है, इसलिए कई failures जल्दी समझ आते हैं। यही design सीमाएँ भी लाता है: हर test में एक tab, सिर्फ़ JavaScript, और ऐसे commands जो सामान्य JavaScript जैसे व्यवहार नहीं करते। इन्हें अनदेखा करेंगे तो fixed sleeps और गलत वजह से fail होने वाले tests लिखेंगे।

Product के लिए, हर pull request पर चलने वाला Cypress suite अहम journeys के regressions users से पहले पकड़ता है। आपके लिए, किसी मौजूदा Cypress suite को बढ़ाना JavaScript front end वाली किसी भी team में काम का skill है।

Cypress कैसे काम करता है: browser के अंदर, command queue के ज़रिए

Selenium (Java, Python, C#, JavaScript, Ruby) HTTP पर W3C WebDriver commands chromedriver या safaridriver जैसे driver को भेजता है; explicit waits आप लिखते हैं और windows के बीच handle से switch करते हैं। Playwright (TypeScript/JavaScript, Python, Java, .NET) Chromium, Firefox और WebKit को अपने ख़ुद के connection से चलाता है, auto-waiting actions और retry होने वाले assertions के साथ, और एक test में कई pages इस्तेमाल कर सकता है। दोनों tests को अलग process में चलाते हैं। Cypress आपकी spec को browser के अंदर, application के ही run loop में चलाता है; उसके पीछे एक Node.js process browser शुरू करता है और config file में defined वे Node tasks चलाता है जिन्हें test cy.task() से call करता है। Cypress network को भी control करता है, और इसी से cy.intercept() संभव होता है।

Commands queue में जाते हैं, अपनी line execute होते ही नहीं चलते: cy.visit(), cy.get() और .click() एक queue में जुड़ते हैं जिसे Cypress test function ख़त्म होने के बाद चलाता है। ये promises नहीं हैं, इसलिए आप इन्हें await नहीं कर सकते, न इनका result रख सकते हैं; इसकी जगह .then() या .should() chain करें।

मुख्य विचार retry-ability है: cy.get() और cy.contains() जैसी queries अपने chained assertions के साथ तब तक दोबारा चलती हैं जब तक assertions pass न हों या defaultCommandTimeout (default 4 seconds) ख़त्म न हो। .click() जैसे actions एक बार चलते हैं, element के actionable होने का इंतज़ार करने के बाद: visible, enabled और किसी चीज़ से ढका न हो। cy.wait(5000) जोड़ने की जगह अपेक्षित state assert करें।

cy.visit('/cart')
cy.get('[data-cy=add-item]').click()   // action: waits until actionable, runs once
cy.get('[data-cy=cart-count]')         // query: retried...
  .should('have.text', '1')            // ...until this passes or the timeout expires

// Wrong: commands are queued, they return no value you can store
// const count = cy.get('[data-cy=cart-count]').text()

// Right: work with the yielded value inside .then()
cy.get('[data-cy=cart-count]').invoke('text').then((text) => {
  cy.log(`The badge shows ${text}`)
})

Install, project layout और config file

Cypress को हर project में npm install --save-dev cypress से install करें; पहली बार npx cypress open चलाने पर Launchpad खुलता है, जहाँ E2E Testing चुनने से config file और cypress/ folder बन जाते हैं। नीचे की config file Node के require() और module.exports (CommonJS) इस्तेमाल करती है, जो import और export का पुराना समकक्ष है, क्योंकि उसे Node load करता है; spec, support और page object files फिर भी import और export इस्तेमाल कर सकती हैं, क्योंकि Cypress उन्हें browser में चलाने से पहले bundle करता है।

Config file में baseUrl cy.visit("/orders") को किसी environment की ओर point करता है; timeouts queries, page loads और responses का समय सीमित करते हैं; retries cypress run और cypress open के लिए अलग-अलग set होता है; reporter output चुनता है, जैसे CI के लिए JUnit XML। Browser run के समय --browser chrome, edge या firefox से चुना जाता है; flag न हो तो defaultBrowser वाला browser चलता है (वरना cypress run bundled Electron browser इस्तेमाल करता है, जो Cypress 16 से deprecated है), और browsers list को setupNodeEvents में filter किया जा सकता है।

• cypress/e2e/: orders.cy.js जैसी spec files।
• cypress/fixtures/: orders.json जैसा stub data, और upload करने वाली files।
• cypress/support/: e2e.js हर spec से पहले चलती है और commands.js import करती है, जिसमें cy.login() जैसे custom commands होते हैं; page objects अक्सर इसके बगल में रहते हैं।
• cypress/screenshots/ और cypress/downloads/: run का output, version control से बाहर।

// cypress.config.js
const { defineConfig } = require('cypress')

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3000',        // cy.visit('/orders') opens this host
    specPattern: 'cypress/e2e/**/*.cy.js',
  },
  defaultBrowser: 'chrome',                  // used when --browser is not given
  defaultCommandTimeout: 6000,               // queries and assertions (default 4000)
  pageLoadTimeout: 60000,                    // page loads after cy.visit()
  responseTimeout: 30000,                    // cy.request() and cy.wait() responses
  retries: { runMode: 1, openMode: 0 },      // one rerun in cypress run only
  reporter: 'junit',
  reporterOptions: { mochaFile: 'results/junit-[hash].xml' },
  screenshotOnRunFailure: true,
  video: false,
})

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

एक test चलाएँ, debug करें, और suite को CI में चलाएँ

लिखते समय npx cypress open इस्तेमाल करें: browser और spec चुनें, और हर save पर spec फिर से चलती है। Command Log में किसी command पर click करने से page वैसा दिखता है जैसा वह उस पल था (time travel)। Command line और CI में:

• एक spec: npx cypress run --spec cypress/e2e/orders.cy.js --browser chrome।
• एक test: काम करते समय it.only(; commit से पहले हटा दें।
• Headed mode: cypress run browser छिपाता है; run देखने के लिए --headed जोड़ें।
• Debugging: cy.pause() open runner में queue रोकता है, .debug() DevTools खुले हों तो breakpoint पर रुकता है, और DEBUG=cypress:* (Linux और macOS syntax) Cypress के अपने logs छापता है जब वह start न हो या browser launch न कर पाए।
• CI: official image cypress/browsers में Node.js और browsers हैं (cypress/included उसमें एक fixed Cypress version जोड़ती है)। नीचे का job सारी specs Chrome में चलाता है, password repository secrets से लेता है और JUnit results व failure screenshots रखता है।

# .github/workflows/e2e.yml
name: e2e
on: [pull_request]

jobs:
  cypress:
    runs-on: ubuntu-latest
    container:
      image: cypress/browsers:latest     # pin an exact tag in a real pipeline
    steps:
      - uses: actions/checkout@v7
      - run: npm ci
      - run: npx cypress run --browser chrome --config baseUrl=https://test.example.com
        env:
          CYPRESS_BUYER_PASSWORD: ${{ secrets.BUYER_PASSWORD }}
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: cypress-results
          path: |
            results
            cypress/screenshots

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

Sessions, network stubs, dialogs, tabs और file upload

Test isolation default रूप से on है: हर test खाली page से, बिना cookies या storage के शुरू होता है, इसलिए हर test को login करना पड़ता है। cy.session() login एक बार चलाता है, बनी cookies और storage cache करता है, और उसी id वाले बाद के tests में restore करता है; validate जाँचता है कि restore हुई session अब भी काम करती है। उसके बाद कोई page visit करें, क्योंकि page खाली होता है।

cy.intercept() requests को method और URL से match करता है। { fixture: "orders.json" } या { statusCode: 500 } जैसे static response के साथ वह server को stub करता है, जिससे empty states और errors जब चाहें मिल जाते हैं; उसके बिना वह सिर्फ़ देखता है, और cy.wait("@alias") request का इंतज़ार करता है ताकि आप उस पर assert कर सकें।

• Dialogs: Cypress alert() और confirm() को अपने-आप accept करता है। cy.on("window:alert", …) को एक stub दें, यानी असली function की जगह लेने वाला function जो अपनी calls record करता है, और उसके alias पर assert करें, ताकि alert न आने पर भी test fail हो; false लौटाने वाला window:confirm stub Cancel चुनता है।
• नए tabs: Cypress एक tab चलाता है। target="_blank" वाले link का href और target जाँचें, फिर URL उसी tab में visit करें या click से पहले target हटा दें; दूसरा tab ज़रूरी ही हो तो documentation @cypress/puppeteer plugin बताता है।
• Upload: file input पर .selectFile("cypress/fixtures/receipt.pdf"); drop zone के लिए { action: "drag-drop" } जोड़ें।

// cypress/support/commands.js: sign in once per user, reuse the session
Cypress.Commands.add('login', (email) => {
  cy.session(email, () => {
    cy.env(['BUYER_PASSWORD']).then(({ BUYER_PASSWORD }) => {
      cy.request({
        method: 'POST',
        url: '/api/login',
        body: { email, password: BUYER_PASSWORD },
        log: false,                          // keep the password out of the log
      })
    })
  }, {
    validate() {
      cy.request('/api/me').its('status').should('eq', 200)
    },
  })
})

// In a spec: watch a request, check an alert, upload a file
cy.login('buyer@example.com')
cy.intercept('POST', '/api/receipts').as('upload')     // watch only, no stub
cy.on('window:alert', cy.stub().as('alert'))           // record every alert
cy.visit('/account/receipts')
cy.get('[data-cy=receipt-file]').selectFile('cypress/fixtures/receipt.pdf')
cy.get('[data-cy=upload]').click()
cy.wait('@upload').its('response.statusCode').should('eq', 201)
cy.get('@alert').should('have.been.calledOnceWith', 'Receipt uploaded')

आज़माएँ: Mock API रिस्पॉन्स जनरेटर आज़माएँ: Mock एरर रिस्पॉन्स जनरेटर

Worked example: चार tests और एक page object में order history

पहला Cypress test अक्सर एक ही it में login करता है, list जाँचता है, order cancel करता है और error जाँचता है। कोई शुरुआती step fail हो तो बाद की जाँचें चलती ही नहीं। इसे behaviour के हिसाब से बाँटें।

Requirement: “Order history page buyer के orders दिखाता है। कोई order न हो तो You have no orders yet दिखाता है; loading fail हो तो Could not load your orders। Cancel करने पर confirmation माँगा जाता है; Cancel चुनने पर order बना रहता है।”

Page object में selectors हैं और कोई assertion नहीं। Fixture orders.json में तीन orders हैं; A-1002 का status Processing है। हर test अपना data ख़ुद stub करता है, cached session reuse करता है और एक behaviour जाँचता है, इसलिए fail हुए test का title बताता है कि क्या टूटा।

// cypress/support/pages/ordersPage.js: knows the screen, makes no assertions
export const ordersPage = {
  visit: () => cy.visit('/account/orders'),
  rows: () => cy.get('[data-cy=order-row]'),
  row: (id) => cy.get(`[data-cy=order-row][data-order-id="${id}"]`),
  message: () => cy.get('[data-cy=orders-message]'),
  cancel: (id) => ordersPage.row(id).find('[data-cy=cancel-order]').click(),
}

// cypress/e2e/orders.cy.js: one behaviour per test
import { ordersPage } from '../support/pages/ordersPage'

describe('Order history', () => {
  beforeEach(() => {
    cy.login('buyer@example.com')
  })

  it('lists the orders returned by the API', () => {
    cy.intercept('GET', '/api/orders', { fixture: 'orders.json' }).as('orders')
    ordersPage.visit()
    cy.wait('@orders')
    ordersPage.rows().should('have.length', 3)
  })

  it('shows the empty state when there are no orders', () => {
    cy.intercept('GET', '/api/orders', { body: [] })
    ordersPage.visit()
    ordersPage.message().should('have.text', 'You have no orders yet')
  })

  it('shows an error when the orders cannot be loaded', () => {
    cy.intercept('GET', '/api/orders', { statusCode: 500, body: {} })
    ordersPage.visit()
    ordersPage.message().should('have.text', 'Could not load your orders')
  })

  it('keeps the order when the buyer cancels the confirmation', () => {
    cy.intercept('GET', '/api/orders', { fixture: 'orders.json' })
    cy.on('window:confirm', cy.stub().as('confirm').returns(false))  // choose Cancel
    ordersPage.visit()
    ordersPage.cancel('A-1002')
    cy.get('@confirm').should('have.been.calledOnceWith', 'Cancel order A-1002?')
    ordersPage.row('A-1002').should('contain', 'Processing')
  })
})

आज़माएँ: JSON वैलिडेटर आज़माएँ: Mock API रिस्पॉन्स जनरेटर

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

संदर्भ

• Cypress DocumentationCypress.ioCypress से ब्राउज़र में एंड-टू-एंड और कंपोनेंट टेस्टिंग का आधिकारिक दस्तावेज़।
• Best Practices — CypressCypress.ioसमर्पित एट्रिब्यूट से एलिमेंट चुनने, फ़िक्स्ड wait से बचने और टेस्ट को स्वतंत्र रखने पर Cypress की गाइडेंस।
• GitHub Actions documentationGitHubGitHub Actions में workflows, jobs, runners और artifacts कैसे परिभाषित होते हैं — जहाँ हर push या pull request पर ऑटोमेटेड टेस्ट चलते हैं।