Testy – nie takie straszne, jak je malująTests – not so scary as they used to

Java + Selenium
Java + Selenium

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.

You May Also Like

Log4j and MDC in Grails

Log4j provides very useful feature: MDC - mapped diagnostic context. It can be used to store data in context of current thread. It may sound scary a bit but idea is simple.

My post is based on post http://burtbeckwith.com/blog/?p=521 from Burt Beckwith's excellent blog, it's definitely worth checking if you are interested in Grails.

Short background story...


Suppose we want to do logging our brand new shopping system and we want to have in each log customer's shopping basket number. And our system can be used at once by many users who can perform many transactions, actions like adding items and so on. How can we achieve that? Of course we can add basket number in every place where we do some logging but this task would be boring and error-prone. 

Instead of this we can use MDC to store variable with basket number in map. 

In fact MDC can be treated as map of custom values for current thread that can be used by logger. 


How to do that with Grails?


Using MDC with Grails is quite simple. All we need to do is to create our own custom filter which works for given urls and puts our data in MDC.

Filters in Grails are classes in directory grails-app/conf/* which names end with *Filters.groovy postfix. We can create this class manually or use Grails command: 
grails create-filters info.rnowak.App.Basket

In result class named BasketFilters will be created in grails-app/conf/info/rnowak/UberApp.

Initially filter class looks a little bit empty:
class BasketFilters {
def filters = {
all(controller:'*', action:'*') {
before = {

}
after = { Map model ->

}
afterView = { Exception e ->

}
}
}
}
All we need to do is fill empty closures, modify filter properties and put some data into MDC.

all is the general name of our filter, as class BasketFilters (plural!) can contain many various filters. You can name it whatever you want, for this post let assume it will be named basketFilter

Another thing is change of filter parameters. According to official documentation (link) we can customize our filter in many ways. You can specify controller to be filtered, its actions, filtered urls and so on. In our example you can stay with default option where filter is applied to every action of every controller. If you are interested in filtering only some urls, use uri parameter with expression describing desired urls to be filtered.

Three closures that are already defined in template have their function and they are started in these conditions:

  • before - as name says, it is executed before filtered action takes place
  • after - similarly, it is called after the action
  • afterView - called after rendering of the actions view
Ok, so now we know what are these mysterious methods and when they are called. But what can be done within them? In official Grails docs (link again) under section 7.6.3 there is a list of properties that are available to use in filter.

With that knowledge, we can proceed to implementing filter.

Putting something into MDC in filter


What we want to do is quite easy: we want to retrieve basket number from parameters and put it into MDC in our filter:
class BasketFilters {
def filters = {
basketFilter(controller:'*', action:'*') {
before = {
MDC.put("basketNumber", params.basketNumber ?: "")
}
after = { Map model ->
MDC.remove("basketNumber")
}
}
}
}

We retrieve basket number from Grails params map and then we put in map under specified key ("basketNumber" in this case), which will be later used in logger conversion pattern. It is important to remove custom value after processing of action to avoid leaks.

So we are putting something into MDC. But how make use of it in logs?


We can refer to custom data in MDC in conversion patter using syntax: %X{key}, where key is our key we used in filter to put data, like:
def conversionPattern = "%d{yyyy-MM-dd HH:mm:ss} %-5p %t [%c{1}] %X{basketNumber} - %m%n"


And that's it :) We've put custom data in log4j MDC and successfully used it in logs to display interesting values.