Spojrzenie w przeszłość: ewolucja automatyzacji testów

Jecelyn Yeen

Maksim Sadym

Narodziny automatyzacji testów

Cofnijmy się do lat 90., kiedy narodziła się przeglądarka internetowa. Automatyzacja testów stała się rzeczywistością dopiero w 2000 r., kiedy powstały projekty Selenium i WebDriver, których celem było rozwiązywanie problemów z testowaniem w różnych przeglądarkach i na wielu urządzeniach.

Oba projekty połączyły siły w 2011 roku pod nazwą Selenium WebDriver, a w 2018 roku stały się standardem W3C. Zwykle określamy go jako WebDriver lub WebDriver „Classic”.

Automatyzacja testów przed wdrożeniem wersji WebDriver „Classic” była dość skomplikowana. Możliwość zautomatyzowania testowania przeglądarek znacznie poprawiła jakość życia programistów i testerów.

Wzrost popularności JavaScriptu

W miarę jak tworzenie stron internetowych w większym stopniu opiera się na języku JavaScript, pojawiły się nowe rozwiązania do automatyzacji, takie jak WebdriverIO, Appium, Nightwatch, Protractor (wycofane), Testcafe, Cypress, Puppeteer i Playwright.

Metody automatyzacji

Narzędzia te można podzielić na 2 główne grupy w zależności od tego, jak automatyzują przeglądarki:

• Wysoki poziom: narzędzia wykonujące JavaScript w przeglądarce. Na przykład Cypress i TestCafe wykorzystują internetowe interfejsy API oraz Node.js do przeprowadzania testów bezpośrednio w przeglądarce. Ciekawostka – w pierwszej wersji Selenium również zastosowano to samo podejście.
• Niski poziom: narzędzia wykonujące polecenia zdalne poza przeglądarką. Gdy narzędzia wymagają jeszcze większej kontroli, na przykład otwieranie wielu kart lub symulowanie trybu urządzenia, wówczas muszą wykonywać polecenia zdalne, aby sterować przeglądarką za pomocą protokołów. Dwa główne protokoły automatyzacji to WebDriver „Classic” i protokół narzędzi Chrome DevTools Protocol (CDP).

W następnej sekcji przyjrzymy się tym dwóm protokołom, aby poznać ich mocne i ograniczenia.

Klasyczny WebDriver i protokół narzędzi deweloperskich w Chrome (CDP)

WebDriver „Classic” to standard internetowy obsługiwany przez wszystkie popularne przeglądarki. Skrypty automatyzacji wysyłają polecenia za pomocą żądań HTTP do serwera sterownika, który następnie komunikuje się z przeglądarkami za pomocą wewnętrznych protokołów powiązanych z przeglądarką.

Oferuje doskonałą obsługę różnych przeglądarek, a jego interfejsy API są przeznaczone do testowania, ale może działać wolno i nie obsługuje niektórych niskopoziomowych ustawień.

Załóżmy na przykład, że masz skrypt testowy, który klika element await coffee.click();. Jest przekształcana w serię żądań HTTP.

# WebDriver: Click on a coffee element

curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
   -H 'Content-Type: application/json'
   -d '{}'

Z kolei protokół Chrome DevTools Protocol (CDP) początkowo opracowano na potrzeby Narzędzi deweloperskich w Chrome i debugowania Chrome, ale na potrzeby automatyzacji wdrożył go Puppeteer. Interfejs CDP komunikuje się bezpośrednio z przeglądarkami opartymi na Chromium przez połączenia WebSocket, zapewniając szybszą wydajność i niskopoziomową kontrolę.

Działa jednak tylko w przeglądarkach opartych na Chromium i nie jest otwartym standardem. Poza tym interfejsy API CDP są stosunkowo złożone. W niektórych przypadkach praca z CDP nie zapewnia ergonomii. Na przykład praca z elementami iframe poza procesem może być bardzo pracochłonna.

Na przykład kliknięcie elementu await coffee.click(); przekłada się na serię poleceń CDP.

// CDP: Click on a coffee element

// Mouse pressed
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}

// Mouse released
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}

Co to są ustawienia niskiego poziomu?

W czasach, gdy opracowano klasyczną wersję WebDriver, kontrola niskopoziomowa nie była potrzebna. Jednak czas się zmienił, internet daje większe możliwości i dzisiejsze testowanie wymaga bardziej precyzyjnych działań.

CDP zaprojektowano tak, aby zaspokajał wszystkie potrzeby związane z debugowaniem, dlatego obsługuje więcej ustawień niskiego poziomu niż klasyczna wersja WebDriver. Pozwala to na obsługę takich funkcji jak:

• Przechwytywanie komunikatów konsoli
• Przechwytywanie żądań sieciowych
• Symuluję tryb urządzenia
• Symulowanie geolokalizacji
• …i wiele innych.

Nie było to możliwe w klasycznej wersji WebDriver ze względu na odmienną architekturę – rozwiązanie WebDriver „Classic” jest oparte na protokole HTTP, co utrudnia subskrybowanie i odsłuchiwanie zdarzeń przeglądarki. CDP jest natomiast oparty na protokole WebSocket, który domyślnie obsługuje komunikację dwukierunkową.

Co dalej: WebDriver BiDi

Oto podsumowanie zalet zarówno klasycznej wersji WebDriver, jak i CDP:

Model WebDriver BiDi łączy najlepsze cechy klasycznej wersji WebDriver i CDP. Jest to nowy standardowy protokół automatyzacji przeglądarek, który jest obecnie w fazie rozwoju.

Dowiedz się więcej o projekcie WebDriver BiDi, czyli o sposobie jego działania, wizji i procesie standaryzacji.