कमांड लाइन और टेस्ट रनर

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

पिछले lesson में आपने एक test file पढ़ी; जब तक कोई उसे चलाए नहीं, कुछ नहीं होता। जो tester terminal से suite नहीं चला सकता, वह यह जानने के लिए दूसरों पर निर्भर रहता है कि product टूटा है या नहीं, लाल pipeline को अपनी मशीन पर reproduce नहीं कर पाता, और दो घंटे के run को उस एक टेस्ट तक नहीं घटा पाता जो मायने रखता है।

Terminal सच का ईमानदार रूप भी है: dashboard पर हरा badge सिर्फ़ इतना बताता है कि किसी command ने exit code 0 लौटाया। जब आप पूरी chain देख लेते हैं, command, runner, tests, report और exit code, तो आप product defect को टूटे installation, गलत folder या किसी ऐसे filter से अलग पहचान सकते हैं जिसने कुछ match नहीं किया, और developers को वह exact command दे सकते हैं जो failure reproduce करे।

Terminal: आप कहाँ हैं और क्या चला रहे हैं

हर command एक working directory के अंदर चलता है, यानी उस folder में जहाँ terminal इस समय खड़ा है। pwd उसे print करता है, ls उसकी सामग्री दिखाता है (पुराने Windows command prompt में dir), cd tests किसी sub-folder में ले जाता है और cd .. एक स्तर ऊपर। Path या तो उस folder के सापेक्ष (relative) होता है (tests/login.spec.ts) या disk की root से absolute (/home/sara/shop-tests, C:\Users\sara\shop-tests)। "command not found" और "no tests found" की बहुत-सी हैरानियाँ बस गलत folder में खड़े terminal की वजह से होती हैं।

Command एक program का नाम है जिसके बाद arguments और options आते हैं: npx playwright test tests/login.spec.ts --headed में npx program है, फ़ाइल एक argument और --headed एक option। Shell, यानी वह program जो आपका टाइप किया हुआ पढ़ता है, programs को PATH environment variable से ढूँढता है, जो उन folders की list है जिनमें वह उस नाम का program खोजता है। Environment variables नाम वाली values हैं जो हर program को उसे शुरू करने वाले shell से मिलती हैं; आपकी set की हुई value सिर्फ़ उसी terminal window तक रहती है। Test projects वह सब कुछ इनमें रखते हैं जो मशीन-दर-मशीन बदलता है, जैसे टेस्ट किया जा रहा URL या कोई password, ताकि test code वही रहे।

• bash, zsh और Git Bash: export BASE_URL=https://staging.shop.example, या सिर्फ़ एक command के लिए: BASE_URL=https://staging.shop.example npx playwright test।
• PowerShell: $env:BASE_URL = 'https://staging.shop.example'; command prompt: set BASE_URL=https://staging.shop.example।
• Node.js में value process.env.BASE_URL से आती है; variable न हो तो वह undefined होती है, इसलिए project को शुरू में ही इसे जाँचकर साफ़ message के साथ रुक जाना चाहिए, न कि बाद में undefined/login जैसे टूटे address पर fail होना चाहिए।
• Ctrl+C चल रहे command को रोकता है; Tab key फ़ाइल नाम पूरे करती है।

$ pwd                        # where am I?  (PowerShell: pwd works too; cmd.exe: cd)
/home/sara/shop-tests
$ ls                         # what is here?  (cmd.exe: dir)
node_modules  package.json  package-lock.json  playwright.config.ts  tests
$ cd tests && ls
checkout.spec.ts  login.spec.ts
$ cd ..
$ export BASE_URL=https://staging.shop.example   # PowerShell: $env:BASE_URL = '...'
$ npx playwright test

Node.js, npm, npx और package की दो फ़ाइलें

Playwright Test, Jest और Vitest जैसे JavaScript runner Node.js पर चलते हैं। nodejs.org से मौजूदा LTS (long-term support) release install करें और node --version व npm --version से जाँचें। npm, जो Node के साथ आने वाला package manager है, project की dependencies को node_modules folder में download करता है। npx उन packages में से किसी का दिया command-line program चलाता है, यहाँ playwright, बिना global install के; अगर package project में नहीं है तो npx उसे पहले एक cache में download करता है, और terminal interactive हो तो पहले आपसे पुष्टि माँगता है।

दो फ़ाइलें project का वर्णन करती हैं। package.json लोग लिखते हैं: scripts लंबे commands के छोटे नाम हैं, इसलिए npm test वही चलाता है जो test script कहती है, और devDependencies में version ranges वाले packages हैं, जहाँ ^1.47.0 का मतलब है 1.47.0 से ऊपर की कोई भी 1.x release। package-lock.json npm लिखता है: हर package और sub-package का exact version जो install हुआ। npm install lock file को शुरुआती बिंदु मानता है: अगर package.json बदल गई हो या lock file न हो, तो वह ranges दोबारा resolve करता है, नए versions चुन सकता है और lock file दोबारा लिखता है। npm ci ठीक वही install करता है जो lock file कहती है, पहले मौजूदा node_modules हटाता है और दोनों फ़ाइलों में फ़र्क़ हो तो error देकर रुक जाता है। इसीलिए CI को, और project को नए सिरे से setup करने वाले हर व्यक्ति को, npm ci चलाना चाहिए। npm ci वे browsers download नहीं करता जिन्हें Playwright चलाता है: यह काम Playwright install या upgrade होने के बाद npx playwright install करता है, और Linux पर चलने वाली नई CI मशीन पर npx playwright install --with-deps उनके लिए ज़रूरी system libraries भी जोड़ता है।

{
  "name": "shop-tests",
  "scripts": {
    "test": "playwright test",
    "test:smoke": "playwright test --grep @smoke"
  },
  "devDependencies": {
    "@playwright/test": "^1.47.0"
  }
}

आज़माएँ: JSON वैलिडेटर

Worked example: एक login suite, चलाने के कई तरीक़े

Project shop-tests में tests/login.spec.ts है जिसमें तीन टेस्ट हैं, दो पर @smoke tag है, और tests/checkout.spec.ts में चार और। ये Playwright Test के commands हैं; दूसरे runners के आकार वही हैं, spelling अलग।

-g (--grep) एक regular expression लेता है, यानी एक text pattern जिसका सबसे सरल रूप एक साधारण शब्द है, और उसे पूरे title से match करता है, describe नाम समेत, इसलिए -g Login पूरा group चलाता है; tag @smoke जैसा शब्द है जो उसी तरह filter होता है। PowerShell में tag को quotes में लिखें, --grep '@smoke': बिना quotes का @smoke PowerShell variable की तरह पढ़ा जाता है और filter खो जाता है। Headless, जो default है, browser को बिना window के चलाता है। --headed window दिखाता है, --debug Playwright Inspector खोलता है जिसमें टेस्ट रुका रहता है ताकि आप action-दर-action आगे बढ़ें, और --ui देखने और re-run करने देता है। तीनों आपकी मशीन के लिए हैं; CI के पास screen नहीं होती।

Goal                           Command
All tests                      npx playwright test
One file                       npx playwright test tests/login.spec.ts
By title (regular expression)  npx playwright test -g "wrong password"
By tag                         npx playwright test --grep @smoke
Headed: watch the browser      npx playwright test --headed
Debug: step through actions    npx playwright test tests/login.spec.ts --debug
One browser project only       npx playwright test --project=chromium
Through package.json scripts   npm test          npm run test:smoke

आज़माएँ: Regex टेस्टर

Runner टेस्ट कैसे ढूँढता है और क्या print करता है

Runner "project" नहीं चलाता; वह फ़ाइलें discover करता है। Playwright Test configured testDir में ऐसी फ़ाइलें देखता है जिनके नाम default रूप से .spec.ts, .spec.js, .test.ts या .test.js जैसे suffix पर ख़त्म होते हैं, उन्हें load करता है और हर test() call इकट्ठा करता है, test.describe() blocks में grouped; Jest और Vitest यही structure describe और it या test के साथ इस्तेमाल करते हैं, Mocha describe और it के साथ। जो फ़ाइल pattern से match नहीं करती वह चुपचाप ignore हो जाती है, और यह एक आम वजह है कि कोई नया टेस्ट "चला ही नहीं"।

Output ऊपर से नीचे पढ़ें: header मिले हुए tests और workers गिनता है, यानी वे parallel processes जो tests चलाते हैं; हर line एक टेस्ट है, उसकी status, फ़ाइल, line number और title के साथ; failures अंत में assertion message और stack trace के साथ दोहराए जाते हैं; आख़िरी lines failed, flaky (पहले fail, फिर retry पर pass), skipped और passed गिनती हैं। html reporter, अगर config में चालू हो, report playwright-report/ में लिखता है (npx playwright show-report से खोलें), failed tests के screenshots और traces, अगर config में चालू हों, test-results/ में जाते हैं, और junit reporter XML लिखता है, आम तौर पर config में दिए गए नाम की फ़ाइल में, जिसे CI servers per-test view में बदलते हैं।

// tests/login.spec.ts — what the runner collects
import { test, expect } from '@playwright/test';

test.describe('Login', () => {
  test('valid login reaches dashboard', { tag: '@smoke' }, async ({ page }) => {
    // arrange, act, assert
  });
  test('wrong password shows error', { tag: '@smoke' }, async ({ page }) => {
    // ...
  });
  test('locked account is refused', async ({ page }) => { /* ... */ });
});

// npx playwright test tests/login.spec.ts — the list reporter
Running 3 tests using 1 worker

  ✓  1 [chromium] › login.spec.ts:4:7 › Login › valid login reaches dashboard (2.1s)
  ✘  2 [chromium] › login.spec.ts:7:7 › Login › wrong password shows error (1.4s)
  ✓  3 [chromium] › login.spec.ts:10:7 › Login › locked account is refused (1.2s)

  1) [chromium] › login.spec.ts:7:7 › Login › wrong password shows error

    Error: expect(locator).toHaveText(expected) failed
    Expected string: "Wrong e-mail or password"
    Received string: "Invalid credentials"

  1 failed
    [chromium] › login.spec.ts:7:7 › Login › wrong password shows error
  2 passed (5.0s)

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

Exit codes: CI को नतीजा कैसे पता चलता है

हर program एक exit code के साथ ख़त्म होता है, एक number जो operating system उसे वापस देता है जिसने program शुरू किया था। परंपरा से 0 का मतलब success है और बाक़ी कुछ भी failure। Test runner 0 से तभी निकलता है जब कोई टेस्ट fail न हुआ हो; एक failed test, configuration file में कोई error, कुछ भी match न करने वाला filter या install न हुआ browser, सब non-zero code देते हैं। Command के ठीक बाद bash में echo $? इसे print करता है, PowerShell में $LASTEXITCODE और command prompt में %ERRORLEVEL%।

GitHub Actions, GitLab CI और Jenkins जैसे CI servers रंग नहीं पढ़ते: वे हर step को एक command की तरह चलाते हैं और exit code non-zero होने पर step को failed mark करते हैं, जिससे job रुकता है, लाल होता है और, जहाँ team ने इस check को required बनाया हो, merge block हो जाता है। यही पूरा contract है। इसका मतलब यह भी है कि failures निगलकर 0 से निकलने वाला runner टूटे product के लिए हरा job देता है, और कभी-कभी fail होने वाला flaky टेस्ट product ठीक होने पर भी job को लाल कर देता है। Steps ख़ुद repository की एक pipeline file में लिखे जाते हैं: GitHub Actions के लिए .github/workflows/ में YAML workflow या GitLab CI के लिए .gitlab-ci.yml (Jenkins Jenkinsfile इस्तेमाल करता है), जहाँ हर run: या script: entry इस lesson के commands जैसा एक command होती है।

• Python: pip install -r requirements.txt dependencies install करता है; pytest tests/test_login.py -k wrong_password test के नाम के keyword से filtered एक फ़ाइल चलाता है और -m smoke एक marker चुनता है; pytest 0 से निकलता है जब चुने हुए टेस्ट चले और कोई fail नहीं हुआ, 1 से जब कोई टेस्ट fail हुआ और 5 से जब कोई टेस्ट collect ही नहीं हुआ।
• Java: Maven pom.xml पढ़ता है; mvn test suite चलाता है और mvn -Dtest=LoginTest test एक class; failing test build को non-zero exit code से fail कर देता है।

$ npx playwright test --grep @smoke
  1 failed
  2 passed (6.8s)
$ echo $?                    # PowerShell: $LASTEXITCODE    cmd.exe: echo %ERRORLEVEL%
1

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

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

संदर्भ

• Playwright DocumentationMicrosoft (Playwright)Playwright का आधिकारिक दस्तावेज़ — Chromium, WebKit और Firefox चलाने वाला end-to-end टेस्ट फ़्रेमवर्क।
• Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।
• GitHub Actions documentationGitHubGitHub Actions में workflows, jobs, runners और artifacts कैसे परिभाषित होते हैं — जहाँ हर push या pull request पर ऑटोमेटेड टेस्ट चलते हैं।
• Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024टेस्ट ऑटोमेशन समाधान और उनकी आर्किटेक्चर के डिज़ाइन, कार्यान्वयन और रखरखाव पर ISTQB का advanced पाठ्यक्रम।