Najprostsza implementacja wzorca Page Object Model

Powrót do: Praktyczne wprowadzenie do testów automatycznych z Playwright

Spis treści

Najprostsza implementacja wzorca POM

TIP: Ta lekcja jest częścią rozwijanego Programu Testy Automatyczne z Playwright 🎭

Prezentacja

Dodatkowe materiały

Bazujemy na kodzie lekcji L08_dane_i_wtyczka_pw

Kod wynikowy tej lekcji znajduje się tu: L03_pom_login

Pamiętaj, aby po danej porcji pracy: uruchamiać test, commitować poprawnie działający kod 😉

TIP: W tej lekcji używamy kontroli wersji Git. Również w tej sekcji mamy w projekcie skonfigurowane narzędzie Prettier, które automatycznie formatuje kod.

Jeśli w poprzednich lekcjach go nie skonfigurowałeś tych narzędzi, to możesz to zrobić bazując na lekcjach bonusowych: Wersjonowanie projektu z Git oraz Prettier, czyli formatter kodu.

Page Object Model

Page Object Model może zostać zaimplementowany na różne sposoby i z różnym poziomem złożoności. Wszystko zależy od języka programowania, zastosowanych dodatkowych wzorców, wymagań i potrzeb. W tej lekcji zaczniemy od jednej z najprostszych implementacji 🙂

Page Object Model w najprostszej postaci

Page Object Model w jednej z najprostszych postaci to klasa, która reprezentuje daną stronę. Natomiast w tej klasie znajdują się lokatory, które wskazują na elementy (przyciski, pola tekstowe, etc.), z którymi wchodzimy w interakcję podczas testów.

W dużym uproszczeniu jego implementacja polega na następujących krokach:

Tworzymy nowy moduł (plik), który zawiera klasę, która reprezentuje testowaną stronę.
Następnie w tej klasie deklarujemy lokatory, które odwołują się do elementów na stronie.
W testach wykorzystujemy obiekt strony wraz z lokatorami, aby wchodzić w interakcje z elementami strony.

Zawartość pliku login.page.ts:

import { Page } from '@playwright/test'


export class LoginPage {
    constructor(private page: Page) {}


    loginInput = this.page.getByTestId('login-input')
    passwordInput = this.page.getByTestId('password-input')
    loginButton = this.page.getByTestId('login-button')
}

Test successful login with correct credentials z pliku login.spec.ts:

  test('successful login with correct credentials', async ({ page }) => {
    // Arrange
    const userId = loginData.userId;
    const userPassword = loginData.userPassword;
    const expectedUserName = 'Jan Demobankowy';


    // Act
    const loginPage = new LoginPage(page)
    await loginPage.loginInput.fill(userId)
    await loginPage.passwordInput.fill(userPassword)
    await loginPage.loginButton.click()


    // Assert
    await expect(page.getByTestId('user-name')).toHaveText(expectedUserName);
  });

Zalety:

zmniejszenie duplikacji kodu w testach – selektory i lokatory są w jednym miejscu (w klasie strony)
dobra utrzymywalność – gdy nastąpi zmiana na stronie (np. zmiana ID elementu), to musimy zaktualizować selektory w klasie strony, a testy pozostają bez zmian,
agregacja danych strony – zebranie w jednym miejscu wszystkich elementów strony, z którymi wchodzimy w interakcję,
bardzo szybka implementacja,
dobry dla mniejszych i prostszych testów i projektów.

Wady:

odpowiedzialność za kolejność działań jest po stronie piszącego testu – osoba pisząca nowe testy musi pamiętać, jakie elementy w jakiej kolejności powinno się używać na danej stronie, np. najpierw wpisanie loginu, później hasła, a na końcu przyciśnięcie przycisku zaloguj,
słabsza utrzymywalność przy większych projektach lub bardzo dużej liczbie testów – jeśli zmieni się wymagana kolejność działań (np. najpierw hasło, a później login), to będzie wymagana aktualizacja testów.

16 komentarzy

Hej hej mam 2 pytanka,
Klasę pod loginPage skonstruowałem trochę inaczej

// Firstly import propernames from playwright test
import {
  Locator,
  Page,
} from '@playwright/test';

export class LoginPage {
  // The variables with types
  private page: Page;
  private userId: string;
  private userPasswword: string;
  public loginInnput: Locator;
  public passwordInput: Locator;
  public loginSubmitButton: Locator;
  // For assertion only
  public accountOwner: Locator;

  // Constructor
  constructor(page: Page) {
    this.page = page;
    this.loginInnput = this.page.getByTestId('login-input');
    this.passwordInput = this.page.getByTestId('password-input');
    this.loginSubmitButton = this.page.getByTestId('login-button');
    // For assertion only
    this.accountOwner = this.page.getByTestId('user-name');
  }

  // Methods
  // User Login type in
  enterUserId = async (userId: string) => {
    await this.loginInnput.fill(userId);
  };
  // User Password type in
  enterUserPassword = async (userPasswword: string) => {
    await this.passwordInput.fill(userPasswword);
  }
  // Login user with credentials 
  submitLoggedUser = async () => {
    // this.enterUserId(this.userId);
    // this.enterUserPassword(this.userPasswword);
    await this.loginSubmitButton.click();
  }
}

Pytanie pierwsze brzmi czy używając w klasie metod z wykorzystaniem odpowiednich akcji lepiej jest użyć jednej metody która wywołuje kroki po kolei – czy lepiej rozbić to wszystko na osobne metody:
– minusy – większa ilość kodu
– plusy – po każdym kroku można używać asercje w kodzie co pozwoli na dokładniejsze przetestowanie danego działania??

A pytanie drugie to
Użyłem i w testach loginu i w testach desktopa i paymentów takiej konstrukcji w before Each’u

  test.beforeEach(async ({ page }) => {
    const userId = loginData.userId;
    const userPassword = loginData.userPassword;

    // Declaring our page instance
    const loginPage = new LoginPage(page);

    await page.goto('/');
    // new attitude of login operation
    await loginPage.enterUserId(userId);
    loginPage.enterUserPassword(userPassword);
    loginPage.submitLoggedUser();
  });

Jak zauważyliście mimo deklaracji w klasie awaita przy metodzie wpisywania id usera musiałem dodać i w beforeEachu awaita dla tej metody ponieważ playwright nie wychwytywał tej metody – wpisywania tekstu w pole na czas i pole loginu zostawało puste – moje pytanie brzmi:
Czy to jest błąd mój czy raczej Playwrighta że nie wychwytuje wpisania z przywołanej z klasy metody asychronicznej – i to tylko na pole loginu bo submit button i wpisanie hasła nie poczebuje już awaita ??
Dzięki z góry za odpowiedź,

Pozdrawiam,
Jakub K

Jakub Kruszyński

14 kwietnia 2024 o 18:55 2 tygodnie temu

Odpowiedz

znawczy się w testach loginu nie robiłem before eacha dla logowania tylko do wejścia na stronę i w żadnej z metod nie musiałem potem robić awaita

    // Act LOGIN:
    // Here we need to  creaqte loginPage obhect
    const loginPage = new LoginPage(page);
    // Assertion of proper page display
    await expect.soft(page).toHaveURL(/.*.app/);
    // Act entering the user Login
    loginPage.enterUserId(userId);
    // Soft Assertion - to verify element which is less important:
    await expect.soft(loginPage.loginInnput).toHaveValue(userId);
    // Act enterting user password
    loginPage.enterUserPassword(userPassword);
    // Soft Assertion - to verify element which is less important:
    await expect.soft(loginPage.passwordInput).toHaveValue(userPassword);
    // Submit login button
    // await page.getByTestId('login-button').click();
    loginPage.submitLoggedUser();

Więc może to z hookiem Playwright ma problemy wiecie coś o tym ?? dzięki z góry za odpowiedź
Pozdrawiam i spokojności życzę,
Jakub K