TestNG Słuchacze w Selenium
Krishna Szczebel
⚡ Inteligentne podsumowanie
Słuchacze w Selenium WebDriver to TestNG Interfejsy przechwytujące zdarzenia testowe w celu dostosowania dzienników, raportów i działań po awarii. W tym artykule wyjaśniono metody ITestListener i opisano działanie obiektu uruchomieniowego. Java przykład i wyjaśnia, jak Selenium Wersja 4 zastąpiła przestarzałą wersję WebDriverEventListener.
Selenium Skrypty WebDriver często muszą reagować na zdarzenia testowe, takie jak pomyślna asercja, błędny lokalizator lub pominięty krok. Nasłuchiwacze to umożliwiają. Ogólnie rzecz biorąc, Selenium projekty opierają się na dwóch rodzinach słuchaczy:
- Słuchacze WebDrivera
- TestNG Słuchacze
W tym samouczku skupimy się na TestNG Słuchacze z uwagą na temat zmian, jakie zaszły w przypadku słuchaczy na poziomie WebDriver Selenium 4.x.
Czym jest słuchacz w TestNG?
Nasłuchiwacz to interfejs, który modyfikuje domyślne zachowanie TestNGJak sama nazwa wskazuje, słuchacze „nasłuchują” zdarzeń zdefiniowanych w Selenium Skrypt i odpowiednio zareaguj. Używasz ich, implementując odpowiedni interfejs Listener i rejestrując go w swojej klasie testowej lub zestawie. Listener pozwala na dostosowanie TestNG raporty, dołączaj zrzuty ekranu i generuj uporządkowane dzienniki.
Rodzaje słuchaczy w TestNG
TestNG dostarcza rodzinę interfejsów nasłuchujących, a każdy z nich jest przeznaczony dla innego etapu cyklu życia testów.
Poniżej znajdują się powszechnie używane TestNG słuchacze:
- IAdnotacja Transformator
- IAdnotacja Transformator2
- IKonfigurowalny
- IConfigurationListener
- IExecutionLister
- I do gotowania
- IInvokedMethodListener
- IInvokedMethodListener2
- ImethodInterceptor
- IReporter
- ISuiteListener
- Odbiornik ITtestów
Te interfejsy są używane w Selenium aby generować dzienniki lub dostosowywać TestNG raporty. W tym samouczku wdrożymy Odbiornik ITtestów.
Odbiornik ITtestów udostępnia następujące metody:
- onStart – wywoływane przy rozpoczęciu dowolnego testu.
- onTestSuccess – wywoływane, gdy test zakończy się pomyślnie.
- onTestFailure – wywoływane, gdy test się nie powiedzie.
- onTestSkipped – wywoływane, gdy test zostanie pominięty.
- onTestFailedButWithinSuccessPercentage – wywoływane, gdy test się nie powiedzie, ale mieści się w procentach powodzenia.
- onFinish – wywoływane po wykonaniu wszystkich testów w klasie.
Scenariusz testowy
W tym scenariuszu testowym zautomatyzujemy proces logowania i wdrożymy Odbiornik ITtestów przeciwko temu.
- Premiera Firefox i otwórz witrynę https://demo.guru99.com/V4/
- Zaloguj się do aplikacji.
Kroki tworzenia TestNG Słuchacz
W powyższym scenariuszu testowym wdrożymy Listener krok po kroku.
Krok 1) Utwórz klasę o nazwie Test słuchacza który realizuje Odbiornik ITtestów. Najedź kursorem na czerwone podkreślenie i Eclipse zaproponuje dwa szybkie rozwiązania, jak pokazano poniżej:
Kliknij „Dodaj niezaimplementowane metody”. Do kodu zostanie dodanych wiele metod szczątkowych (bez treści), podobnie jak tutaj:
importować org.testng.ITestContext;
importować org.testng.ITestListener;
importować org.testng.ITestResult;
Klasa publiczna Test słuchacza narzędzia Odbiornik ITtestów {
@Nadpisanie
publiczna nieważność onFinish(Kontekst testowy arg0) {
// TODO Automatycznie wygenerowany szczątkowy element metody
}
@Nadpisanie
publiczna nieważność onStart(Kontekst testowy arg0) {
// TODO Automatycznie wygenerowany szczątkowy element metody
}
@Nadpisanie
publiczna nieważność onTestFailedButWithinSuccessPercentage(Wynik testu ITestResult arg0) {
// TODO Automatycznie wygenerowany szczątkowy element metody
}
@Nadpisanie
publiczna nieważność onTestFailure(Wynik testu ITestResult arg0) {
// TODO Automatycznie wygenerowany szczątkowy element metody
}
@Nadpisanie
publiczna nieważność onTestSkipped(Wynik testu ITestResult arg0) {
// TODO Automatycznie wygenerowany szczątkowy element metody
}
@Nadpisanie
publiczna nieważność onTestStart(Wynik testu ITestResult arg0) {
// TODO Automatycznie wygenerowany szczątkowy element metody
}
@Nadpisanie
publiczna nieważność onTestSuccess(Wynik testu ITestResult arg0) {
// TODO Automatycznie wygenerowany szczątkowy element metody
}
}
Teraz zmodyfikujmy Test słuchacza klasa. W szczególności wypełnimy następujące metody: onTestFailure, onTestSkipped, onTestStart, onTestSuccess.
Zmiana jest prosta: każda metoda wyświetla nazwę testu, dzięki czemu konsola wyraźnie pokazuje status testu (zaliczony, niezaliczony lub pominięty).
Po modyfikacji kod wygląda następująco:
importować org.testng.ITestContext;
importować org.testng.ITestListener;
importować org.testng.ITestResult;
Klasa publiczna Test słuchacza narzędzia Odbiornik ITtestów {
@Nadpisanie
publiczna nieważność onFinish(Kontekst testowy Wynik) {
}
@Nadpisanie
publiczna nieważność onStart(Kontekst testowy Wynik) {
}
@Nadpisanie
publiczna nieważność onTestFailedButWithinSuccessPercentage(Wynik testu ITestResult Wynik) {
}
// Ta metoda jest wywoływana, gdy przypadek testowy zakończy się niepowodzeniem.
@Nadpisanie
publiczna nieważność onTestFailure(Wynik testu ITestResult Wynik) {
System.out.println(„Nazwa nieudanego przypadku testowego to:” + Wynik.getName());
}
// Ta metoda jest wywoływana, gdy przypadek testowy zostanie pominięty.
@Nadpisanie
publiczna nieważność onTestSkipped(Wynik testu ITestResult Wynik) {
System.out.println(„Nazwa pominiętego przypadku testowego to:” + Wynik.getName());
}
// Ta metoda jest wywoływana, gdy rozpoczyna się przypadek testowy.
@Nadpisanie
publiczna nieważność onTestStart(Wynik testu ITestResult Wynik) {
System.out.println(Result.getName() + „rozpoczęto przypadek testowy”);
}
// Ta metoda jest wywoływana, gdy przypadek testowy zostanie zaliczony.
@Nadpisanie
publiczna nieważność onTestSuccess(Wynik testu ITestResult Wynik) {
System.out.println(„Nazwa zaliczonego przypadku testowego to:” + Wynik.getName());
}
}
Krok 2) Utwórz inną klasę o nazwie Przypadki testowe do automatyzacji logowania. Selenium wykona tę klasę, aby zalogować się do witryny demonstracyjnej.
importować org.openqa.selenium.By;
importować org.openqa.selenium.WebDriver;
importować org.openqa.selenium.firefox.FirefoxKierowcy;
importować org.testng.Assert;
importować org.testng.annotations.Nasłuchiwacze;
importować org.testng.adnotacje.Test;
Klasa publiczna Przypadki testowe {
Sterownik sieciowy kierowca = nowych FirefoxKierowca();
// Test zaprojektowany tak, aby zaliczyć, w celu weryfikacji powodzenia nasłuchiwania.
@Test
publiczna nieważność Zaloguj() {
sterownik.get(„https://demo.guru99.com/V4/”);
driver.findElement(By.name(„płyn”)).wyślijKlucze(„mngr34926”);
driver.findElement(By.name("Hasło")).wyślijKlucze(„amUpenu”);
driver.findElement(By.name(„btnLogin”)).trzask();
}
// Wymuszone niepowodzenie testu w celu weryfikacji nasłuchiwacza błędów.
@Test
publiczna nieważność TestToFail() {
System.out.println(„Ta metoda testowania zawodzi”);
Assert.assertTrue(fałszywy);
}
}
Krok 3) Następnie dołącz tego słuchacza do naszej klasy testowej Przypadki testoweIstnieją dwa sposoby połączenia klasy z interfejsem nasłuchującym.
Pierwszym sposobem jest użycie @Słuchacze adnotacja, jak pokazano poniżej:
Dodajemy tę adnotację powyżej Przypadki testowe Klasa. Klasa wygląda wtedy tak:
importować org.openqa.selenium.By;
importować org.openqa.selenium.WebDriver;
importować org.openqa.selenium.firefox.FirefoxKierowcy;
importować org.testng.Assert;
importować org.testng.annotations.Nasłuchiwacze;
importować org.testng.adnotacje.Test;
@Listeners(Listener_Demo.ListenerTest.class)
Klasa publiczna Przypadki testowe {
Sterownik sieciowy kierowca = nowych FirefoxKierowca();
// Test sprawdzający zaliczenie, w celu weryfikacji powodzenia nasłuchiwania.
@Test
publiczna nieważność Zaloguj() {
sterownik.get(„https://demo.guru99.com/V4/”);
driver.findElement(By.name(„płyn”)).wyślijKlucze(„mngr34926”);
driver.findElement(By.name("Hasło")).wyślijKlucze(„amUpenu”);
driver.findElement(By.name(„btnLogin”)).trzask();
}
// Wymuszone niepowodzenie testu w celu weryfikacji nasłuchiwacza błędów.
@Test
publiczna nieważność TestToFail() {
System.out.println(„Ta metoda testowania zawodzi”);
Assert.assertTrue(fałszywy);
}
}
Struktura projektu wygląda następująco:
Krok 4) Wykonaj Przypadki testowe Klasa. Metody wewnątrz Test słuchacza są wywoływane automatycznie na podstawie zachowania metod oznaczonych adnotacją @Test.
Krok 5) Sprawdź dane wyjściowe wyświetlone w konsoli.
Moc wyjściowa Przypadki testowe wygląda jak:
C:\Użytkownicy\gauravn\AppData\Local\Temp\testng-eclipse–1058076918\testng-customsuite.xml
Rozpoczęto przypadek testowy logowania
Nazwa zaliczonego przypadku testowego to: Login
Rozpoczęto przypadek testowy TestToFail
Ta metoda testowania nie działa
Nazwa nieudanego przypadku testowego to: TestToFail
ZATWIERDZONO: Zaloguj się
NIEPOWODZENIE: TestToFail
java.lang.AssertionError: oczekiwano [prawda], ale znaleziono [fałsz]
Korzystanie z obiektu nasłuchującego dla wielu klas
Jeżeli projekt ma wiele klas testowych, dodanie @Słuchacze adnotacje do każdego z nich stają się uciążliwe i podatne na błędy.
W takim przypadku utwórz testng.xml plik i zarejestruj tam słuchacza tylko raz.
Ten nasłuchiwacz jest następnie stosowany w całym zestawie testów, niezależnie od liczby klas. Po uruchomieniu pliku XML nasłuchiwacz jest uruchamiany dla każdej klasy zadeklarowanej w zestawie, a w ramach tego samego znacznika można połączyć dowolną liczbę klas nasłuchiwaczy.
WebDriverListener w Selenium 4 kontra przestarzały EventFiringWebDriver
Kompletujemy wszystkie dokumenty (wymagana jest kopia paszportu i XNUMX zdjęcia) potrzebne do TestNG Słuchacze reagują na zdarzenia cyklu życia testu, słuchacze WebDriver reagują na działania sterownika przeglądarki, takie jak kliknięcie, nawigacja lub wywołanie findElement. Selenium 3 typowe podejście było takie, Nasłuchiwacz zdarzeń WebDriver interfejs podłączony przewodowo EventFiringWebDriver. Oba są przestarzałe w Selenium 4.x.
Nowoczesną alternatywą jest WebDriverListener interfejs połączony z Dekorator zdarzeń:
importować org.openqa.selenium.chrome.ChromeDriver;
importować org.openqa.selenium.support.events.EventFiringDecorator;
importować org.openqa.selenium.support.events.WebDriverListener;
Klasa publiczna LoggingListener narzędzia WebDriverListener {
@Nadpisanie
publiczna nieważność przedPobraniem(Sterownik sieciowy sterownik, ciąg url) {
System.out.println(„Nawigacja do” + url);
}
}
Sterownik sieciowy surowy = nowych Sterownik Chrome();
Sterownik sieciowy kierowca = nowych Dekorator zdarzeń<>(nowych LoggingListener()).decorate(raw);
Dekorator może opakować dowolny WebDriver, WebElement lub Alert, co jest bardziej elastyczne niż stary wrapper wyzwalający zdarzenia. Użyj WebDriverListener dla obserwowalności po stronie przeglądarki i TestNG Odbiornik ITtestów do raportowania na poziomie pakietu.
Słuchacze wspomagani przez sztuczną inteligencję: inteligentniejsze rejestry i selekcja awarii
Nowoczesne technologie Selenium Zespoły coraz częściej podłączają usługi AI do swoich odbiorników, aby sygnały CI były bardziej użyteczne. onTestFailure, nasłuchiwacz wspomagany przez sztuczną inteligencję może uchwycić migawkę DOM i zrzut ekranu, wysłać je do modelu, który zwraca prawdopodobny klaster przyczyny źródłowej i zapisać tag z powrotem do TestNG raportu lub narzędzia takiego jak ReportPortal.
Typowe wzorce napędzane przez sztuczną inteligencję obejmują:
- Wykrywanie niestabilnych testów: Słuchacze przekazują osie czasu zaliczenia/niezaliczenia do modelu, który klasyfikuje awarię jako niestabilną, związaną ze środowiskiem lub rzeczywistą regresją.
- Inteligentne zrzuty ekranu: Modele komputerowego widzenia przycinają, opisują i różnicują zrzuty ekranu interfejsu użytkownika, dzięki czemu recenzenci widzą zmieniony obszar zamiast całego zrzutu strony.
- Lokalizatory samonaprawiające: A WebDriverListener haczyki przedZnalezieniemElementu i prosi pomocnika AI o zasugerowanie alternatywnego lokalizatora, gdy lokalizator główny wyrzuci Wyjątek NoSuchElement.
- Podsumowania w języku naturalnym: An IReporter wdrożenie przekazuje wyniki do LLM, który z kolei tworzy podsumowanie składające się z jednego akapitu.
Warstwa nasłuchująca jest najczystszym miejscem do wstrzykiwania tych haków, ponieważ nie wpływa ona na logikę testu i jest stosowana jednolicie w całym zestawie.
Podsumowanie
Odbiorniki są wymagane do generowania dzienników lub dostosowywania TestNG raporty w Selenium Sterownik sieciowy.
- TestNG oferuje wiele interfejsów nasłuchujących; wybierz ten, który odpowiada zdarzeniu, które Cię interesuje.
- Słuchacze to interfejsy używane w Selenium Skrypty WebDriver reagujące na zdarzenia cyklu życia testu.
- Pokazano w samouczku Odbiornik ITtestów z wynikiem pozytywnym i negatywnym testu.
- Możesz dołączyć słuchacza za pomocą @Słuchacze lub zarejestruj go raz testng.xml za cały apartament.
- Selenium 4.x zastępuje EventFiringWebDriver w WebDriverListener + Dekorator zdarzeń dla zdarzeń na poziomie WebDriver.
