End-to-end testing Playwright-ով

01E2E-ի տեղը testing pyramid-ում

Testing pyramid-ն ունի շատ արագ unit թեստեր ներքևում, ավելի քիչ integration թեստեր մեջտեղում և փոքր քանակով E2E թեստեր գագաթին։ E2E թեստերն ամենաիրատեսականն են, բայց նաև ամենադանդաղն ու պահպանման համար ամենաթանկը, ուստի օգտագործեք դրանք կրիտիկական ճանապարհների համար․ գրանցում, մուտք, որոնում, զամբյուղում ավելացում, checkout, գաղտնաբառի վերականգնում, admin-ի հիմնական գործողություններ։ Մի թեստավորեք յուրաքանչյուր validation հաղորդագրություն browser-ով․ դա unit կամ component թեստերի գործն է։ Առողջ suite-ն ունի տասնյակից մինչև մի քանի հարյուր E2E թեստ, որոնք զուգահեռ աշխատում են րոպեների ընթացքում, և յուրաքանչյուրը պաշտպանում է մի բան, որի կոտրվելը կվնասեր օգտատերերին կամ եկամտին։

02Կարգավորում և ձեր առաջին թեստը

Տեղադրեք npm init playwright@latest-ով, որը ստեղծում է config, օրինակ թեստ և GitHub Actions workflow և ներբեռնում browser-ները։ Թեստը async ֆունկցիա է, որը ստանում է fixture-ներ․ ամենակարևորը page-ն է՝ թարմ browser tab մեկուսացված browser context-ում (ինչպես նոր incognito profile) յուրաքանչյուր թեստի համար։ Էլեմենտները գտեք օգտատիրոջը տեսանելի locator-ներով, ինչպիսիք են getByRole-ը, getByLabel-ը և getByText-ը, գործողություն կատարեք դրանց վրա և ստուգեք expect-ով։ Playwright-ը ավտոմատ սպասում է, մինչև էլեմենտները տեսանելի, ակտիվ և կայուն լինեն՝ նախքան սեղմելը, իսկ web-first assertion-ները, ինչպիսիք են toBeVisible-ը և toHaveURL-ը, կրկնվում են, մինչև անցնեն կամ timeout-ը լրանա։ Ձեռքով սպասումներ գրեթե երբեք պետք չեն։

1import { test, expect } from "@playwright/test";
2 
3test("user can search and open a product", async ({ page }) => {
4  await page.goto("/");
5  await page.getByRole("searchbox", { name: "Search" }).fill("running shoes");
6  await page.getByRole("button", { name: "Search" }).click();
7 
8  const results = page.getByRole("listitem").filter({ hasText: "Trail" });
9  await expect(results.first()).toBeVisible();
10 
11  await results.first().getByRole("link").click();
12  await expect(page).toHaveURL(/\/products\//);
13  await expect(page.getByRole("heading", { level: 1 })).toContainText("Trail");
14});

03Locator-ներ, որոնք վերապրում են redesign-ները

Flaky և փխրուն թեստերը սովորաբար գալիս են վատ selector-ներից։ div > div:nth-child(3) > button-ի նման CSS ուղին կոտրվում է, երբ դիզայները wrapper է ավելացնում։ Նախընտրեք locator-ներ, որոնք արտացոլում են այն, ինչ տեսնում են օգտատերերը և assistive technology-ն․ առաջինը getByRole՝ accessible name-ով, ապա getByLabel ձևի դաշտերի համար, getByPlaceholder, getByText, և getByTestId որպես բացահայտ պայմանագիր, երբ ոչ մի այլ բան կայուն չէ։ Locator-ները lazy և strict են․ դրանք վերագնահատվում են յուրաքանչյուր գործողության ժամանակ, և եթե մեկը համընկնում է մի քանի էլեմենտի հետ, Playwright-ը սխալ է նետում՝ սխալ էլեմենտը սեղմելու փոխարեն։ Շղթայեք և filter արեք locator-ները՝ դրանց շրջանակը սահմանելու համար, օրինակ՝ որոշակի պատվերի համար պարունակող տող։ Բոնուս․ role-ի վրա հիմնված locator-ները հավելվածը մղում են դեպի ավելի լավ accessibility։

• Լավ է՝ page.getByRole("button", { name: "Place order" })
• Լավ է՝ page.getByLabel("Email")
• Խուսափեք՝ page.locator(".btn.btn-primary:nth-child(2)")

04Կոնֆիգուրացիա, project-ներ և authentication

playwright.config.ts-ը սահմանում է base URL-ը, browser-ները (project-ներ), retry-ները, reporter-ները և ինչպես գործարկել հավելվածը։ Տարածված pattern է setup project-ը, որը մեկ անգամ մուտք է գործում և պահում browser-ի storage state-ը (cookie-ներ և localStorage) ֆայլում․ մյուս project-ները նորից օգտագործում են այն, ուստի թեստերի մեծ մասը սկսվում է արդեն authenticated վիճակում՝ առանց login UI-ը կրկնելու։ webServer-ը գործարկում է ձեր հավելվածը թեստերից առաջ և սպասում դրան։ Պահեք trace-եր ձախողված retry-ների համար, ինչը տալիս է ամբողջական ձայնագրություն CI-ի ձախողումները debug անելու համար։ Մի commit արեք պահված auth ֆայլը․ թղթապանակն ավելացրեք .gitignore-ում։

1import { defineConfig, devices } from "@playwright/test";
2 
3export default defineConfig({
4  testDir: "./e2e",
5  fullyParallel: true,
6  forbidOnly: !!process.env.CI,
7  retries: process.env.CI ? 2 : 0,
8  reporter: [["html"], ["list"]],
9  use: { baseURL: "http://localhost:3000", trace: "on-first-retry" },
10  projects: [
11    { name: "setup", testMatch: /.*\.setup\.ts/ },
12    { name: "chromium", dependencies: ["setup"],
13      use: { ...devices["Desktop Chrome"], storageState: "playwright/.auth/user.json" } },
14    { name: "mobile", dependencies: ["setup"],
15      use: { ...devices["iPhone 15"], storageState: "playwright/.auth/user.json" } },
16  ],
17  webServer: { command: "npm run start", url: "http://localhost:3000", reuseExistingServer: !process.env.CI },
18});

05Fixture-ներ և page object-ներ

Fixture-ները Playwright-ի dependency injection-ն են․ թեստը հայտարարում է, թե ինչ է իրեն պետք (page, request կամ ձեր սեփական fixture-ը, օրինակ՝ մուտք գործած admin կամ seed արված ապրանք), և Playwright-ը այն կարգավորում և մաքրում է թեստի շուրջ։ Custom fixture-ները փոխարինում են beforeEach շղթաներին և թեստերը կարճ են պահում։ Page object model-ները էջի locator-ներն ու գործողությունները փաթաթում են class-ի մեջ, ուստի UI-ի փոփոխությունը շտկվում է մեկ տեղում։ Page object-ները պահեք բարակ․ դրանք բացում են գործողություններ օգտատիրոջ լեզվով (addToCart, checkout) և assertion-ները թողնում թեստերին։ Օգտագործեք request fixture-ը՝ թեստային տվյալները API-ով ստեղծելու համար, ինչը շատ ավելի արագ է, քան UI-ով սեղմելը։

1import { test as base, expect } from "@playwright/test";
2 
3type Fixtures = { product: { slug: string } };
4 
5export const test = base.extend<Fixtures>({
6  product: async ({ request }, use) => {
7    const res = await request.post("/api/test/products", { data: { name: "E2E shoe", price: 50 } });
8    const product = await res.json();
9    await use(product);                                   // run the test
10    await request.delete("/api/test/products/" + product.slug); // clean up
11  },
12});
13 
14test("product page shows price", async ({ page, product }) => {
15  await page.goto("/products/" + product.slug);
16  await expect(page.getByTestId("price")).toHaveText("$50.00");
17});

06Debugging և CI

Playwright-ը գալիս է ուժեղ գործիքներով։ npx playwright test --ui-ը բացում է UI mode՝ watch mode-ով և յուրաքանչյուր քայլով time-travel-ով։ --debug-ը բացում է inspector-ը՝ գործողություններով քայլ առ քայլ անցնելու համար։ codegen-ը ձեր սեղմումները ձայնագրում է թեստի մեջ, ինչը լավ մեկնարկային կետ է, որը հետո մաքրում եք։ Trace viewer-ը ցույց է տալիս ձախողված թեստի յուրաքանչյուր գործողություն, DOM snapshot, ցանցային հարցում և console log, և այդպես եք debug անում CI-ի ձախողումները՝ առանց դրանք տեղում վերարտադրելու։ CI-ում browser-ները տեղադրեք npx playwright install --with-deps-ով, աշխատեցրեք զուգահեռ worker-ներով, մեծ suite-երը բաժանեք մեքենաների միջև --shard-ով և HTML report-ը և trace-երը վերբեռնեք որպես artifact-ներ։ Պաշտոնական Docker image-ը պարունակում է browser-ների բոլոր dependency-ները։

1# .github/workflows/e2e.yml (steps)
2- uses: actions/checkout@v4
3- uses: actions/setup-node@v4
4  with: { node-version: 22, cache: npm }
5- run: npm ci
6- run: npx playwright install --with-deps
7- run: npx playwright test --shard=${{ matrix.shard }}/4
8- uses: actions/upload-artifact@v4
9  if: ${{ !cancelled() }}
10  with: { name: report-${{ matrix.shard }}, path: playwright-report/ }

07Ինչպես է Playwright-ը կառավարում browser-ները

Playwright-ը ձեր թեստային կոդն աշխատեցնում է Node.js-ում և browser-ների հետ խոսում մշտական connection-ով․ Chromium-ի համար Chrome DevTools Protocol-ով, իսկ Firefox-ի և WebKit-ի համար՝ իր սեփական patch արված protocol-ներով։ Այս out-of-process դիզայնը թույլ է տալիս մեկ թեստին կառավարել մի քանի էջ, context և նույնիսկ browser և ուղղակիորեն դիտարկել ցանցային տրաֆիկը։ Browser context-ները էժան, մեկուսացված session-ներ են մեկ browser պրոցեսի ներսում, և ահա թե ինչու յուրաքանչյուր թեստ կարող է միլիվայրկյանների ընթացքում թարմ context ստանալ։ Playwright-ը յուրաքանչյուր release-ին կցում է browser-ների կոնկրետ build-եր․ 1.57-ից ի վեր Chromium-ի համար օգտագործում է Chrome for Testing build-եր, և դրանք տեղադրում եք npx playwright install-ով։ Լրացուցիչ վստահության համար կարող եք նաև աշխատեցնել branded Chrome-ի կամ Edge-ի դեմ channel տարբերակով։

08Ցանցի վերահսկում՝ mocking, HAR և API testing

page.route-ը intercept է անում URL pattern-ին համապատասխանող հարցումները, որպեսզի կարողանաք դրանք կատարել ֆիքսված տվյալներով, փոփոխել կամ abort անել՝ ձախողումները մոդելավորելու համար։ Այդպես եք թեստավորում «վճարային պրովայդերը չի աշխատում» իրավիճակը՝ առանց իրական պրովայդերը կոտրելու։ routeFromHAR-ը replay է անում ձայնագրված տրաֆիկը կայուն demo-ների կամ offline թեստերի համար։ request fixture-ը լիարժեք HTTP client է, որը, ցանկության դեպքում, կիսում է cookie-ները browser context-ի հետ, ուստի կարող եք ստեղծել տվյալներ, կանչել ներքին endpoint-ներ կամ գրել մաքուր API թեստեր նույն framework-ում։ Համատեղեք դրանք․ ստեղծեք պատվեր API-ով, ապա ստուգեք, որ UI-ն այն ցույց է տալիս, ինչը արագ է և ստուգում է երկու շերտն էլ։

1test("shows a friendly error when payments fail", async ({ page }) => {
2  await page.route("**/api/payments/intent", (route) =>
3    route.fulfill({ status: 503, json: { error: "unavailable" } }),
4  );
5  await page.goto("/checkout");
6  await page.getByRole("button", { name: "Pay now" }).click();
7  await expect(page.getByRole("alert")).toContainText("try again");
8});

09Visual regression testing

expect(page).toHaveScreenshot()-ը screenshot է անում և այն պիքսել առ պիքսել համեմատում պահված baseline-ի հետ՝ ձախողվելով, եթե տարբերությունը գերազանցում է threshold-ը։ Առաջին run-ը ստեղծում է baseline-ը․ թարմացրեք այն միտումնավոր --update-snapshots-ով։ Screenshot-ները տարբերվում են operating system-ների և font rendering-ի միջև, ուստի baseline-ները ստեղծեք և համեմատեք նույն միջավայրում, սովորաբար CI-ում պաշտոնական Playwright Docker image-ում։ Նվազեցրեք աղմուկը․ դինամիկ տարածքները (ամսաթվեր, գովազդ, avatar-ներ) դիմակավորեք mask տարբերակով, անջատեք անիմացիաները, սպասեք font-երին և, հնարավորության դեպքում, screenshot արեք կոնկրետ component-ներ ամբողջ էջերի փոխարեն։ toMatchAriaSnapshot-ով accessibility snapshot-ները accessibility tree-ն համեմատում են որպես տեքստ, ինչը պիքսելներից պակաս փխրուն է և բռնում է կառուցվածքային regression-ները։

1await expect(page).toHaveScreenshot("checkout.png", {
2  fullPage: true,
3  mask: [page.getByTestId("order-date"), page.locator(".promo-banner")],
4  animations: "disabled",
5  maxDiffPixelRatio: 0.01,
6});

10Suite-ի մասշտաբավորում՝ զուգահեռություն, sharding և flakiness-ի վերահսկում

Playwright-ը լռելյայն test ֆայլերն աշխատեցնում է զուգահեռ worker պրոցեսներում․ fullyParallel-ը զուգահեռացնում է նաև ֆայլի ներսի թեստերը։ Յուրաքանչյուր worker ստանում է իր browser-ը, ուստի թեստերը չպետք է կիսեն փոփոխվող տվյալներ․ ստեղծեք եզակի գրառումներ յուրաքանչյուր թեստի համար կամ օգտագործեք worker-scoped fixture-ներ, որոնք ստեղծում են մեկ account յուրաքանչյուր worker-ի համար (testInfo.workerIndex-ը օգնում է)։ CI-ում shard արեք մեքենաների միջև --shard=1/4-ով և blob report-ները միավորեք npx playwright merge-reports-ով մեկ HTML report-ի մեջ։ Հետևեք flakiness-ին․ թեստը, որը անցնում է retry-ից հետո, հաղորդվում է որպես flaky․ վերանայեք այդ ցանկը շաբաթական և շտկեք արմատային պատճառը, սովորաբար ընդհանուր state, բաց թողնված await-ներ կամ անիմացիաներ։ --repeat-each-ը և --fail-on-flaky-tests-ը օգնում են վերարտադրել և պարտադրել։ Վերջին տարբերակներն առաջարկում են նաև AI-ի օգնությամբ test agent-ներ, որոնք պլանավորում, ստեղծում և «բուժում» են թեստերը, բայց դեռ review են պահանջում։