O czym będzie ?
O testach interfejsu aplikacji WEB’owych. Temat, choć związany z programowaniem, to niezbyt popularny wśród developerów. Pisanie testów uchodzi za zajęcie mniej ambitne, nudne, poboczne i częstokroć traktowane jest jako zło konieczne.
Testy to temat rzeka. Płynie ona w wielu serwisach i blogach w internecie. Nie będę więc zawracał tej rzeki i przepisywał internet na nowo. Doleję do niej tylko jedną ważną informację – odpowiem na pytanie, czy można zmienić powszechny stereotyp na temat testów interfejsu na przykładzie testów Selenium.
Pytanie to zrodziło się w mojej głowie, na przestrzeni kilku ostatnich lat. Zadawałem je sobie niejednokrotnie, myśląc, że odpowiedź jest oczywista i potwierdzająca stereotyp. Tak było, dopóki nie trafiłem do dużego projektu, w którym ktoś wreszcie ‘odpowiednio’ podszedł do tematu testów.
Myślisz ze znasz Selenium ?
Selenium to środowisko do obsługi testów frontendów aplikacji internetowych. W większości przypadków używane jest według scenariusza: nagraj test klikając po stronie, a potem odtwarzaj po każdej zmianie w kodzie. Niby ok, ale nie do końca.
Nagrane w ten sposób testy bardzo szybko stają się nieutrzymywalne. Wyobraźmy sobie 500 testów tego typu, a później wyobraźmy sobie, że trzeba zmienić interfejs aplikacji na inny. Inaczej rozmieszczone kontrolki, panele, inne ich nazwy id’ki itd. Przerobienie takiej ilości testów do nowej wersji aplikacji staje się praktycznie niemożliwe, a już na pewno nie opłacalne.
Jest kilka sposobów by radzić sobie z tego typu sytuacjami. Ja opiszę jedno konkretne rozwiązanie, które dla mnie, z punktu widzenia osoby piszącej w JAVIE, jest najbardziej wygodne. Testy Selenium można pisać właśnie w tym języku. ‘Dokładnie’ tak, jak zwykłe aplikacje. I to Dokładnie przez duże ‘D’, bo nie tylko korzystając z języka, ale też stosując wszelkie związane z nim dobre praktyki, wzorce projektowe, moc i funkcjonalność testów jednostkowych. Nie bez znaczenia jest też to, że testy można pisać i utrzymywać w ulubionym IDE, które nie tylko ułatwia pisanie, ale też i utrzymanie testów, serwując szereg narzędzi odpowiedzialnych za np. refaktoring, czy obsługę wersjonowania.
Testy – jak to się robi ?
Niechęć do testów bierze się głównie z dwóch powodów: ich pisanie jest nudne i żmudne. Obie opinie nie są niestety bezpodstawne, co pokażę cytując kod z tutoriala do Selenium+Java ze strony projektu: http://code.google.com/p/selenium/wiki/GettingStarted. Podkreślam, że nie chcę nikogo obrazić i wiem, że w poniższym kodzie jest kilka uproszczeń, niemniej jednak tak właśnie wygląda większość testów, które można znaleźć w internecie. Kto nie wierzy niech sobie wygoogla frazę: selenium java. [java] // Go to the Google Suggest home page driver.get(“http://www.google.com/webhp?complete=1&hl=en”); // Enter the query string “Cheese” WebElement query = driver.findElement(By.name(“q”)); query.sendKeys(“Cheese”); // Sleep until the div we want is visible or 5 seconds is over long end = System.currentTimeMillis() + 5000; while (System.currentTimeMillis() < end) { WebElement resultsDiv = driver.findElement(By.className(“gssb_e”)); // If results have been returned, the results are displayed in a drop down. if (resultsDiv.isDisplayed()) { break; } } // And now list the suggestions List allSuggestions = driver.findElements(By.xpath(“//td[@class=’gssb_a gbqfsf’]”)); for (WebElement suggestion : allSuggestions) { System.out.println(suggestion.getText()); } } [/java]
Co robi powyższy kod ? Na pierwszy rzut oka widać, że.. nic nie widać. Gdyby nie komentarze, to jego zrozumienie byłoby trudne. Wymagałoby nie tylko znajomości działania strony google, ale także jej kodu źródłowego. Nawet wtedy jednak, zrozumienie tej instrukcji: driver.findElements(By.xpath(“//td[@class=’gssb_a gbqfsf’]”)); zajełoby chwilę.
Testy – jak można to robić lepiej ?
Testy Selenium + Java wcale nie muszą być ani nudne, ani żmudne. Mogą wyglądać tak: [java] public void nieMoznaDodacEFakturyDlaPrepaida() { //given StarterPrepaid starter30Minut = new StarterPrepaid30Minut(); KatalogKart karty = Sklep.otworzSklep().menuGlowne.katalogKart(); //when Koszyk koszyk = karty.listaProduktow().wybierz(starter30Minut); //then assertFalse(koszyk.moznaDodacEfakture()); } [/java]
Już na pierwszy rzut oka widać o co chodzi w powyższym teście. Chodzi o to, by sprawdzić, czy możemy wybrać e-fakturę kupując ofertę na starter.
Pisząc ten test, analizując jego działanie, nie musimy wiedzieć, jak wygląda implementacja i kod źródłowy aplikacji. Nie obchodzi nas, który znacznik html musimy przeczytać, jakie są id’ki kolejnych przycisków, które trzeba kliknąć itd. Test jest na innym, wyższym poziomie abstrakcji. Operuje na działaniach biznesowych, bezpośrednio dotyczy funkcjonalności, którą testujemy.
Tak właśnie powinny być konstruowane testy Selenium. Najpierw należy poświęcić trochę czasu na napisanie odpowiedniej ‘domeny’, która pokryje funkcjonalność aplikacji, a dopiero potem pisać testy. Domena ta powinna udostępniać metody biznesowe, takie jak: kup, wyświetl, zaloguj, dodajDoKoszyka, usunZKoszyka itd. Metody takie powinny ukrywać bezpośrednią imlpementacje kliknięć, wyszukań po XPath, czy oczekiwań na przeładowanie strony www. Jednym słowem, mówiąc kolokwialnie, powinniśmy opakować selenium w coś bardziej wygodnego dla użytkownika naszej aplikacji.
A co z refaktoringiem ?
Oprócz ułatwień dla programistów, podniesienie testów na wyższy poziom abstrakcji, ma jeszcze jedną, kolosalną zaletę. Umożliwia bezpośrednie przeniesienie scenariuszy testowych na język aplikacji. Taki test nie tylko szybko się czyta, czy tworzy, ale bardzo łatwo weryfikuje i utrzymuje.
Na początku wspomniałem o trudnościach w dostosowaniu ‘typowych’ testów Selenium do zmian w interfejsie aplikacji. A co z refaktoringiem, przedstawionej przeze mnie konstrukcji testów ? Czy faktycznie jest on łatwiejszy ? Wyobraźmy więc sobie te 500 testów napisanych w taki odseparowany biznesowo sposób. Żaden z tych testów nie zawiera więc odnośników do kodu html, nie wykorzystuje bezpośrednio linków, ani nie zawiera odwołań do inputów, div’ów itd. W żadnym z tych 500 testów nie trzeba więc NIC zmieniać! Jedyne co trzeba zmienić, to domenę, część wspólną, która bazuje bezpośrednio na kodzie aplikacji. To jednak jest o niebo łatwiejsze niż zmiana 500 testów.
Czy to już wszsystko ?
Tak, to już wszystko. Celem niniejszego wpisu nie było pokazanie gotowych rozwiązań i ich implementacji krok po kroku. Celem było przekonanie do idei rozdzielenia testów na dwie warstwy: biznesową i tą związaną bezpośrednio z implementacją. Warto też zauważyć, że choć takie rozwiązanie nie jest często stosowane przy okazji testów, to jednak nie jest niczym nowym. Moim zdaniem warto je stosować, a już na pewno warto w połączeniu Selenium + Java.
Myślisz ze znasz Selenium ?
Selenium to środowisko do obsługi testów frontendów aplikacji internetowych. W większości przypadków używane jest według scenariusza: nagraj test klikając po stronie, a potem odtwarzaj po każdej zmianie w kodzie. Niby ok, ale nie do końca.
Nagrane w ten sposób testy bardzo szybko stają się nieutrzymywalne. Wyobraźmy sobie 500 testów tego typu, a później wyobraźmy sobie, że trzeba zmienić interfejs aplikacji na inny. Inaczej rozmieszczone kontrolki, panele, inne ich nazwy id’ki itd. Przerobienie takiej ilości testów do nowej wersji aplikacji staje się praktycznie niemożliwe, a już na pewno nie opłacalne.
Jest kilka sposobów by radzić sobie z tego typu sytuacjami. Ja opiszę jedno konkretne rozwiązanie, które dla mnie, z punktu widzenia osoby piszącej w JAVIE, jest najbardziej wygodne. Testy Selenium można pisać właśnie w tym języku. ‘Dokładnie’ tak, jak zwykłe aplikacje. I to Dokładnie przez duże ‘D’, bo nie tylko korzystając z języka, ale też stosując wszelkie związane z nim dobre praktyki, wzorce projektowe, moc i funkcjonalność testów jednostkowych. Nie bez znaczenia jest też to, że testy można pisać i utrzymywać w ulubionym IDE, które nie tylko ułatwia pisanie, ale też i utrzymanie testów, serwując szereg narzędzi odpowiedzialnych za np. refaktoring, czy obsługę wersjonowania.
Testy – jak to się robi ?
Niechęć do testów bierze się głównie z dwóch powodów: ich pisanie jest nudne i żmudne. Obie opinie nie są niestety bezpodstawne, co pokażę cytując kod z tutoriala do Selenium+Java ze strony projektu: http://code.google.com/p/selenium/wiki/GettingStarted. Podkreślam, że nie chcę nikogo obrazić i wiem, że w poniższym kodzie jest kilka uproszczeń, niemniej jednak tak właśnie wygląda większość testów, które można znaleźć w internecie. Kto nie wierzy niech sobie wygoogla frazę: selenium java. [java] // Go to the Google Suggest home page driver.get(“http://www.google.com/webhp?complete=1&hl=en”); // Enter the query string “Cheese” WebElement query = driver.findElement(By.name(“q”)); query.sendKeys(“Cheese”); // Sleep until the div we want is visible or 5 seconds is over long end = System.currentTimeMillis() + 5000; while (System.currentTimeMillis() < end) { WebElement resultsDiv = driver.findElement(By.className(“gssb_e”)); // If results have been returned, the results are displayed in a drop down. if (resultsDiv.isDisplayed()) { break; } } // And now list the suggestions List allSuggestions = driver.findElements(By.xpath(“//td[@class=’gssb_a gbqfsf’]”)); for (WebElement suggestion : allSuggestions) { System.out.println(suggestion.getText()); } } [/java]
Co robi powyższy kod ? Na pierwszy rzut oka widać, że.. nic nie widać. Gdyby nie komentarze, to jego zrozumienie byłoby trudne. Wymagałoby nie tylko znajomości działania strony google, ale także jej kodu źródłowego. Nawet wtedy jednak, zrozumienie tej instrukcji: driver.findElements(By.xpath(“//td[@class=’gssb_a gbqfsf’]”)); zajełoby chwilę.
Testy – jak można to robić lepiej ?
Testy Selenium + Java wcale nie muszą być ani nudne, ani żmudne. Mogą wyglądać tak: [java] public void nieMoznaDodacEFakturyDlaPrepaida() { //given StarterPrepaid starter30Minut = new StarterPrepaid30Minut(); KatalogKart karty = Sklep.otworzSklep().menuGlowne.katalogKart(); //when Koszyk koszyk = karty.listaProduktow().wybierz(starter30Minut); //then assertFalse(koszyk.moznaDodacEfakture()); } [/java]
Już na pierwszy rzut oka widać o co chodzi w powyższym teście. Chodzi o to, by sprawdzić, czy możemy wybrać e-fakturę kupując ofertę na starter.
Pisząc ten test, analizując jego działanie, nie musimy wiedzieć, jak wygląda implementacja i kod źródłowy aplikacji. Nie obchodzi nas, który znacznik html musimy przeczytać, jakie są id’ki kolejnych przycisków, które trzeba kliknąć itd. Test jest na innym, wyższym poziomie abstrakcji. Operuje na działaniach biznesowych, bezpośrednio dotyczy funkcjonalności, którą testujemy.
Tak właśnie powinny być konstruowane testy Selenium. Najpierw należy poświęcić trochę czasu na napisanie odpowiedniej ‘domeny’, która pokryje funkcjonalność aplikacji, a dopiero potem pisać testy. Domena ta powinna udostępniać metody biznesowe, takie jak: kup, wyświetl, zaloguj, dodajDoKoszyka, usunZKoszyka itd. Metody takie powinny ukrywać bezpośrednią imlpementacje kliknięć, wyszukań po XPath, czy oczekiwań na przeładowanie strony www. Jednym słowem, mówiąc kolokwialnie, powinniśmy opakować selenium w coś bardziej wygodnego dla użytkownika naszej aplikacji.
A co z refaktoringiem ?
Oprócz ułatwień dla programistów, podniesienie testów na wyższy poziom abstrakcji, ma jeszcze jedną, kolosalną zaletę. Umożliwia bezpośrednie przeniesienie scenariuszy testowych na język aplikacji. Taki test nie tylko szybko się czyta, czy tworzy, ale bardzo łatwo weryfikuje i utrzymuje.
Na początku wspomniałem o trudnościach w dostosowaniu ‘typowych’ testów Selenium do zmian w interfejsie aplikacji. A co z refaktoringiem, przedstawionej przeze mnie konstrukcji testów ? Czy faktycznie jest on łatwiejszy ? Wyobraźmy więc sobie te 500 testów napisanych w taki odseparowany biznesowo sposób. Żaden z tych testów nie zawiera więc odnośników do kodu html, nie wykorzystuje bezpośrednio linków, ani nie zawiera odwołań do inputów, div’ów itd. W żadnym z tych 500 testów nie trzeba więc NIC zmieniać! Jedyne co trzeba zmienić, to domenę, część wspólną, która bazuje bezpośrednio na kodzie aplikacji. To jednak jest o niebo łatwiejsze niż zmiana 500 testów.
Czy to już wszsystko ?
Tak, to już wszystko. Celem niniejszego wpisu nie było pokazanie gotowych rozwiązań i ich implementacji krok po kroku. Celem było przekonanie do idei rozdzielenia testów na dwie warstwy: biznesową i tą związaną bezpośrednio z implementacją. Warto też zauważyć, że choć takie rozwiązanie nie jest często stosowane przy okazji testów, to jednak nie jest niczym nowym. Moim zdaniem warto je stosować, a już na pewno warto w połączeniu Selenium + Java.
