מהן Playwright Assertions?

כאשר כותבים בדיקה אוטומטית, לא מספיק להפעיל פעולות באתר. למשל, אפשר ללחוץ על כפתור התחברות, אבל הלחיצה לבדה אינה מוכיחה שהמשתמש התחבר בהצלחה. כדי לוודא שהתהליך הסתיים כמצופה, צריך לבדוק את התוצאה.

כאן נכנסות לתמונה Assertions. אלה פקודות שמאפשרות לבדוק תנאים מוגדרים מראש ולהכשיל את הבדיקה כאשר התנאי אינו מתקיים.

ב־Playwright, הדרך הנפוצה לבצע בדיקות כאלה היא באמצעות הפונקציה expect().

import { test, expect } from '@playwright/test';

test('page displays the expected heading', async ({ page }) => {
  await page.goto('https://example.com');

  await expect(page.locator('h1')).toBeVisible();
});

בדוגמה זו, הבדיקה פותחת עמוד ומוודאת שאלמנט הכותרת מסוג h1 מוצג למשתמש. אם האלמנט אינו מופיע בתוך פרק הזמן המוגדר, הבדיקה נכשלת.

למה Assertions חשובות בבדיקות אוטומטיות?

בדיקה אוטומטית צריכה לאמת את התנהגות המערכת, ולא רק לבצע רצף פעולות. ללא Assertions, תרחיש בדיקה עלול להסתיים בלי לזהות שהמערכת הציגה הודעת שגיאה, לא שמרה מידע או ניווטה לעמוד שגוי.

• אימות תוצאות: בדיקה שהפעולה הובילה לתוצאה הצפויה.
• זיהוי תקלות: איתור שינויים בממשק או בהתנהגות המערכת.
• בדיקות רגרסיה: ווידוא שפיתוחים חדשים לא פגעו בפונקציונליות קיימת.
• אמינות: שימוש בהמתנות חכמות שמצמצמות כשלים הנובעים מתזמון.
• קריאות: יצירת בדיקות שקל להבין מה הן אמורות לוודא.

איך משתמשים ב־expect?

התחביר הבסיסי כולל שלושה חלקים: האובייקט שאותו רוצים לבדוק, הפונקציה expect וה־Matcher שמגדיר את התנאי הרצוי.

await expect(locator).toBeVisible();

במקרה זה, locator מייצג אלמנט בעמוד, ו־toBeVisible מוודא שהאלמנט מוצג. מילת המפתח await חשובה משום שהבדיקה היא אסינכרונית ויש להמתין לתוצאה שלה.

אם עדיין אינכם מכירים את אופן איתור האלמנטים, מומלץ לקרוא את המדריך המלא ל־Playwright Locators.

Web-First Assertions – היתרון המרכזי של Playwright

אחד היתרונות המשמעותיים של Playwright הוא התמיכה ב־Web-First Assertions. בבדיקות אלה, Playwright חוזר ומנסה לבדוק את התנאי עד שהוא מתקיים או עד שתם פרק הזמן המוגדר.

לדוגמה, לאחר שליחת טופס, ייתכן שיעברו כמה רגעים עד שהודעת האישור תופיע. במקום לבדוק מיד אם ההודעה קיימת, אפשר להשתמש ב־Assertion שממתין אוטומטית להופעתה.

await expect(page.getByText('הטופס נשלח בהצלחה'))
  .toBeVisible();

הבדיקה תנסה לאמת שהטקסט מוצג. היא אינה דורשת מהבודק להוסיף המתנה קבועה לפני כל Assertion.

Assertions נפוצות ב־Playwright

הטבלה הבאה מרכזת את הבדיקות השימושיות ביותר למי שמתחיל לכתוב בדיקות אוטומטיות.

בדיקת התחברות באמצעות Assertions

נניח שאנו רוצים לבדוק תהליך התחברות. הבדיקה צריכה למלא את פרטי המשתמש, ללחוץ על הכפתור ולאמת שהמשתמש הגיע לאזור האישי.

import { test, expect } from '@playwright/test';

test('user can log in', async ({ page }) => {
  await page.goto('https://example.com/login');

  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Password').fill('example-password');

  await page.getByRole('button', { name: 'Log in' }).click();

  await expect(page).toHaveURL(/dashboard/);
  await expect(
    page.getByRole('heading', { name: 'Dashboard' })
  ).toBeVisible();
});

בדוגמה יש שתי בדיקות נפרדות: הראשונה מוודאת שכתובת הדף מכילה dashboard, והשנייה מוודאת שכותרת האזור האישי מוצגת. יחד הן מספקות אימות ברור יותר מאשר בדיקת כתובת בלבד.

יש להתאים את כתובת האתר, שמות השדות והכותרת למערכת האמיתית. הדוגמה מיועדת להמחשה ואינה משתמשת באתר התחברות פעיל.

בדיקת טקסטים: toHaveText לעומת toContainText

שתי Assertions שימושיות במיוחד הן toHaveText ו־toContainText, אך הן מיועדות לציפיות שונות.

toHaveText – התאמה לטקסט הצפוי

נשתמש בה כאשר חשוב לנו לבדוק שהתוכן תואם לטקסט שהגדרנו.

await expect(
  page.getByRole('heading')
).toHaveText('ההזמנה נקלטה בהצלחה');

toContainText – בדיקת חלק מהטקסט

נשתמש בה כאשר התוכן עשוי להכיל מידע נוסף, אבל חשוב לנו לוודא שמופיע בו ביטוי מסוים.

await expect(
  page.locator('.notification')
).toContainText('ההזמנה נקלטה');

לדוגמה, אם ההודעה היא "ההזמנה נקלטה בהצלחה. מספר ההזמנה: 12345", בדיקת toContainText יכולה לאמת את הביטוי המרכזי בלי לדרוש התאמה לכל ההודעה.

בדיקת נראות של אלמנטים

בממשקי משתמש, חשוב לוודא שאלמנטים מוצגים או מוסתרים בהתאם לתהליך. לדוגמה, לאחר לחיצה על כפתור פתיחת חלון, אפשר לבדוק שהחלון הופיע.

await page.getByRole('button', { name: 'Open dialog' }).click();

await expect(
  page.getByRole('dialog')
).toBeVisible();

כדי לבדוק שהחלון נעלם לאחר סגירתו:

await page.getByRole('button', { name: 'Close' }).click();

await expect(
  page.getByRole('dialog')
).toBeHidden();

הבדיקות האלה עוזרות לוודא שהתנהגות הממשק תואמת את הציפיות ולא רק שהפעולות בוצעו.

בדיקת ערכים בשדות טופס

כאשר ממלאים שדה, אפשר לוודא שהערך הנכון אכן נמצא בו. הדבר שימושי במיוחד בטפסים שבהם הנתונים מתעדכנים אוטומטית או מועתקים משדה אחר.

const emailInput = page.getByLabel('Email');

await emailInput.fill('qa@example.com');

await expect(emailInput).toHaveValue('qa@example.com');

אם השדה מכיל ערך אחר, ה־Assertion תיכשל. כך ניתן לזהות בעיות שבהן הקלדת המשתמש אינה נשמרת או שהמערכת משנה את הערך באופן בלתי צפוי.

בדיקת מספר אלמנטים באמצעות toHaveCount

לעיתים נרצה לוודא שרשימה מציגה מספר פריטים מסוים. למשל, אם תוצאת חיפוש אמורה להציג שלוש תוצאות, אפשר לבדוק את מספר האלמנטים.

const products = page.locator('.product-card');

await expect(products).toHaveCount(3);

הבדיקה מוודאת שמספר האלמנטים התואמים לבורר הוא שלושה. אם התוצאות נטענות באופן אסינכרוני, Playwright ינסה שוב עד שהתנאי יתקיים או עד שתסתיים ההמתנה.

בדיקת URL וכותרת הדף

לאחר ניווט, התחברות או שליחת טופס, כדאי לוודא שהמערכת העבירה את המשתמש למקום הנכון.

await expect(page).toHaveURL(/orders/);

await expect(page).toHaveTitle('My Orders');

הדוגמה הראשונה בודקת שהכתובת מכילה את המחרוזת orders. השנייה בודקת את כותרת הדפדפן. אפשר להשתמש במחרוזת מדויקת או בביטוי רגולרי, בהתאם לדרישה.

למה לא להשתמש בהמתנה קבועה לפני כל Assertion?

טעות נפוצה היא להוסיף השהיה קבועה לפני כל בדיקה, בתקווה שהעמוד יספיק להיטען.

// Usually avoid fixed waits like this:
await page.waitForTimeout(3000);

await expect(
  page.getByText('Saved successfully')
).toBeVisible();

המתנה קבועה עלולה להאריך את הבדיקה גם כאשר התוכן מופיע מיד, ועדיין לא להספיק כאשר המערכת איטית יותר מהצפוי. עדיף להמתין ישירות לתנאי הרצוי באמצעות Web-First Assertion.

המתנה קבועה עשויה להיות שימושית במקרים נקודתיים של ניפוי תקלות, אך בדרך כלל אינה הבחירה הנכונה בבדיקות אוטומטיות יציבות.

מה ההבדל בין Locator לבין Assertion?

שני המושגים קשורים זה לזה, אך לכל אחד תפקיד שונה:

• Locator: מגדיר כיצד למצוא אלמנט בעמוד, לדוגמה כפתור התחברות או שדה אימייל.
• Assertion: מגדירה מה צריך להיות נכון לגבי האלמנט או העמוד.

לדוגמה:

const loginButton = page.getByRole('button', {
  name: 'Log in'
});

await expect(loginButton).toBeVisible();
await expect(loginButton).toBeEnabled();

כאן ה־Locator מאתר את הכפתור, ואילו ה־Assertions בודקות שהוא מוצג וניתן להפעלה.

Timeout – כמה זמן Playwright ממתין?

ל־Assertions יש פרק זמן מרבי שבו הן מנסות לאמת את התנאי. אם התנאי לא מתקיים בתוך הזמן הזה, הבדיקה נכשלת. אפשר להגדיר זמן המתנה ייעודי ל־Assertion מסוימת.

await expect(
  page.getByText('Report completed')
).toBeVisible({ timeout: 10000 });

בדוגמה, ה־Assertion יכולה להמתין עד עשר שניות. אין פירוש הדבר שהיא תמיד תחכה עשר שניות: אם התנאי מתקיים קודם, הבדיקה יכולה להמשיך מיד.

הגדלת timeout אינה תחליף לתיקון בדיקה שגויה. אם התנאי לעולם אינו מתקיים, גם זמן המתנה ארוך יותר לא יפתור את הבעיה.

טעויות נפוצות בשימוש ב־Assertions

דוגמה לתרחיש E2E שמשלב כמה Assertions

בתרחיש מקצה לקצה, אפשר לבדוק את התהליך העסקי כולו: פתיחת עמוד, הוספת פריט לעגלה, מעבר לתשלום ואימות שהפריט מופיע בעגלה.

import { test, expect } from '@playwright/test';

test('product can be added to cart', async ({ page }) => {
  await page.goto('https://example.com/products');

  await page.getByRole('button', {
    name: 'Add to cart'
  }).click();

  await expect(
    page.getByRole('status')
  ).toContainText('Added to cart');

  await expect(
    page.getByTestId('cart-count')
  ).toHaveText('1');
});

הדוגמה ממחישה שתי Assertions: האחת מאמתת את הודעת ההצלחה, והשנייה את מספר הפריטים בעגלה. שמות האלמנטים וההודעות תלויים במימוש האתר, ולכן יש להתאים אותם למערכת הנבדקת.

להרחבה בנושא, קראו את המדריך המעשי לבדיקות E2E עם Playwright.

איך מריצים את הבדיקות?

לאחר שמירת הבדיקה בקובץ מתאים בפרויקט Playwright, אפשר להריץ את כל הבדיקות באמצעות הפקודה:

npx playwright test

כדי להריץ בדיקה מסוימת, אפשר לציין את שם הקובץ:

npx playwright test tests/login.spec.ts

אם אתם בתחילת הדרך, מומלץ לעבור גם על מדריך Playwright למתחילים.

שיטות עבודה מומלצות

• השתמשו ב־Web-First Assertions כאשר בודקים מצב של אלמנט בעמוד.
• העדיפו בדיקות של התוצאה העסקית החשובה ולא רק של פעולות המשתמש.
• בחרו Locators יציבים, ברורים ונגישים, כגון getByRole ו־getByLabel.
• הימנעו מהמתנות קבועות כאשר אפשר להמתין ישירות לתנאי הרצוי.
• התאימו את רמת הדיוק של בדיקת הטקסט לצורך: התאמה מלאה או בדיקת חלק מהטקסט.
• כתבו הודעות בדיקה ושמות תרחישים שקל להבין מהם מה אמור להתרחש.
• כאשר בדיקה נכשלת, בדקו אם מדובר בתקלה במוצר, ב־Locator שגוי, בתנאי ציפייה לא נכון או בבעיה בתזמון.

שאלות נפוצות על Playwright Assertions

סיכום

Playwright Assertions הן מרכיב מרכזי בבניית בדיקות אוטומטיות אמינות. הן מאפשרות לוודא שהמערכת מציגה את המידע הנכון, שהאלמנטים מתנהגים כמצופה ושתהליכים עסקיים מסתיימים בהצלחה.

כדי להתחיל, כדאי להכיר היטב את expect, את toBeVisible, את toHaveText, את toHaveValue ואת toHaveURL. בהמשך אפשר לשלב אותן בתרחישי E2E מורכבים יותר, ולהשתמש ב־Web-First Assertions כדי לצמצם בעיות תזמון ולשפר את יציבות הבדיקות.