Baza Wiedzy

Zasada segregacji interfejsów na przykładzie Page Objectu

Segregacja interfejsów

Zasada segregacji interfejsów (I – interface segregation) jest jedną z najprostszych zasad ze zbioru SOLID. W oryginale brzmi ona:

 "Wiele dedykowanych interfejsów jest lepsze niż jeden ogólny”.

Z powyższego zdania wynika, że lepiej jest mieć klasę która implementuje wiele interfejsów, niż klasę, która implementuje jeden duży interfejs z wieloma metodami. Ale przejdźmy do przykładu.

 

Scenariusz

Załóżmy, że automatyzujemy aplikację, w której mamy bardzo dużo modalnych okiem z ang. modal window.

Większość okien w aplikacji wygląda tak na obrazku poniżej. Oczywiście jest to okno przykładowe.

Przykładowe modalne okno składa się z:

  • Tytułu okna,
  • Treści w oknie,
  • Przycisku zatwierdzenia (confirm),
  • Przycisku negacji (cancel),

Załóżmy, że chcielibyśmy teraz wprowadzić zasadę segregacji interfejsów do Page Objectów, które implementują powyższy przykład.

 

Przykład niepoprawny

Ponieważ, w aplikacji którą automatyzujemy jest wiele taki okiem modal. To dla porządku każde okno modal będzie posiadało osobny Page Object. Niestety nie możemy stworzyć generycznego Page Objectu ponieważ, lokatory w oknach zawsze są różne. Poniżej przykładowy Page Object o nazwie ConfirmModalPage:

import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.FindBy;

import static org.testng.Assert.assertEquals;

public class ConfirmModalPage extends BasePage {

    @FindBy(name = "modal-title")
    private WebElement modalTitleLabel;

    @FindBy(name = "modal-question")
    private WebElement contentModalLabel;

    @FindBy(name = "modal-confirm-btn")
    private WebElement confirmButton;

    @FindBy(css = "cancel-button")
    private WebElement cancelButton;

    public void assertModalTitle(String modalTitle) {
        assertEquals(modalTitleLabel.getText(), modalTitle);
    }

    public void assertModalContent(String modalContent) {
        assertEquals(contentModalLabel.getText(), modalContent);
    }

    public void clickOnCancelButton() {
        cancelButton.click();
    }

    public void clickOnConfirmButton() {
        confirmButton.click();
    }

}

Ponieważ chcemy zachować spójność z innymi modalami w aplikacji, tworzymy interfejs o nazwie ModalWindow, w którym umieszczamy wszystkie wspólne metody dla wszystkich okien. I tak mamy:

public interface ModalWindow {
    
    void assertModalTitle(String modalTitle);
    void assertModalContent(String modalQuestion);
    void clickOnCancelButton();
    void clickOnConfirmButton();
    
}

Ostatecznie nasza przykładowa klasa ConfirmModalPage wygląda następująco:

import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.FindBy;

import static org.testng.Assert.assertEquals;

public class ConfirmModalPage extends BasePage implements ModalWindow {

    @FindBy(name = "modal-title")
    private WebElement modalTitleLabel;

    @FindBy(name = "modal-question")
    private WebElement contentModalLabel;

    @FindBy(name = "modal-confirm-btn")
    private WebElement confirmButton;

    @FindBy(css = "cancel-button")
    private WebElement cancelButton;

    public void assertModalTitle(String modalTitle) {
        assertEquals(modalTitleLabel.getText(), modalTitle);
    }

    public void assertModalContent(String modalContent) {
        assertEquals(contentModalLabel.getText(), modalContent);
    }

    public void clickOnCancelButton() {
        cancelButton.click();
    }

    public void clickOnConfirmButton() {
        confirmButton.click();
    }

}

Dzięki zastosowaniu interfejsu dbamy o to, aby wszystkie Page Objecty, które pomimo różnych wartości lokatorów dla WebElementów miały takie same nazwy metod. Tym samym były łatwe w utrzymaniu i spójne między sobą.

Problem pojawia się w momencie kiedy do aplikacji, którą automatyzujemy zostanie dodane okno modal, które wygląda inaczej. Na przykład, tak jak na obrazku poniżej:

Podany powyżej przykład:

  • Posiada tytuł okna,
  • Posiada treść okna,
  • Posiada przycisk zatwierdzenia (confirm),
  • Nie posiada przycisku negacji,
  • Ma inne elementy takie jak pole do wpisywania, której dla uproszczenia pominiemy.

 

W z związku z czym nie możemy zastosować interfejsu ModalWindow ponieważ, nowy modal nie posiada takich samych cech. Jak w takim razie poradzić sobie z tą sytuacją?

Odpowiedzią na to pytanie jest oczywiście segregacja interfejsów w myśl:

 "Wiele dedykowanych interfejsów jest lepsze niż jeden ogólny”.

Poprawny przykład

Zaczynamy od rozbicia interfejsu ModalWindow na mniejsze, i tak mamy:

Interfejs ModalTitle:

public interface ModalTitle {

    void assertModalTitle(String modalTitle);

}

Interfejs ModalContent:

public interface ModalContent {

    void assertModalContent(String modalQuestion);

}

Interfejs ModalConfirmButton:

public interface ModalConfirmButton {

    void clickOnConfirmButton();

}

Interfejs ModalCancelButton:

public interface ModalCancelButton {

    void clickOnCancelButton();

}

Następnie dla klasy ConfirmModalPage modyfikujemy implementację:

import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.FindBy;

import static org.testng.Assert.assertEquals;

public class ConfirmModalPage extends BasePage implements ModalTitle, ModalContent, ModalConfirmButton, ModalCancelButton {

    @FindBy(name = "modal-title")
    private WebElement modalTitleLabel;

    @FindBy(name = "modal-question")
    private WebElement contentModalLabel;

    @FindBy(name = "modal-confirm-btn")
    private WebElement confirmButton;

    @FindBy(css = "cancel-button")
    private WebElement cancelButton;

    public void assertModalTitle(String modalTitle) {
        assertEquals(modalTitleLabel.getText(), modalTitle);
    }

    public void assertModalContent(String modalContent) {
        assertEquals(contentModalLabel.getText(), modalContent);
    }

    public void clickOnCancelButton() {
        cancelButton.click();
    }

    public void clickOnConfirmButton() {
        confirmButton.click();
    }

}

Dla nowego okna tworzymy klasę SubscribeModalWindow, która implementuje tylko interfejsy ModalTitle, ModalContent, ModalConfirmButton:

import example.solid.i.bad.BasePage;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.FindBy;

import static org.testng.Assert.assertEquals;

public class SubscribeModalPage extends BasePage implements ModalTitle, ModalContent, ModalConfirmButton {

    @FindBy(name = "modal-title")
    private WebElement modalTitleLabel;

    @FindBy(name = "modal-question")
    private WebElement contentModalLabel;

    @FindBy(name = "modal-confirm-btn")
    private WebElement confirmButton;

    public void assertModalTitle(String modalTitle) {
        assertEquals(modalTitleLabel.getText(), modalTitle);
    }

    public void assertModalContent(String modalContent) {
        assertEquals(contentModalLabel.getText(), modalContent);
    }

    public void clickOnConfirmButton() {
        confirmButton.click();
    }

}

Dzięki rozbiciu interfejsu ModalWindow na mniejsze:

  • Uzyskaliśmy większą elastyczność kod,
  • Jesteśmy w stanie obsłużyć więcej specyficznych przypadków,
  • Spełniamy zasadę segregacji interfejsów.

To było na tyle! 

Potrzebujesz więcej informacji?

Artykuł powstał na bazie kursu Automatyzacja testów z wykorzystaniem Selenium

O Autorze

Nazywam się Mateusz Ciołek i od 2011 roku zajmuję się testowaniem oprogramowania ze specjalizacją w automatyzacji testów. 

Najlepszy newsletter o Javie w Polsce

Czy chcesz otrzymywać nowości ze świata Javy oraz przykładowe pytania rekrutacyjne? Zapisz się na newsletter i bądź na bieżąco! Otrzymasz także ekskluzywne materiały oraz informacje o nowych kursach i promocjach.

Traktujemy Twoją prywatność poważnie. Nikomu nie udostępniamy Twojego maila no i zawsze możesz się wypisać.

Komentarze do artykułu

Wyłączyliśmy możliwość dodawania komentarzy. Poniżej znajdziesz archiwalne wpisy z czasów gdy strona była jeszcze hobbystycznym blogiem. Zapraszamy natomiast do zadawnia pytań i dyskusji na naszej grupe na facebooku.

Kurs Java WrocławJavaStart na Youtube