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

Mentoring in Software Craftsmanship

Maria Diaconu and  Alexandru Bolboaca are both strong supporters of Software Craftsmanship and Agile movements in Romania, with years of experience as developers, leaders, architects, managers and instructors. On their lecture at Agile Central Eur...Maria Diaconu and  Alexandru Bolboaca are both strong supporters of Software Craftsmanship and Agile movements in Romania, with years of experience as developers, leaders, architects, managers and instructors. On their lecture at Agile Central Eur...

Super Confitura Man

How Super Confitura Man came to be :)

Recently at TouK we had a one-day hackathon. There was no main theme for it, you just could post a project idea, gather people around it and hack on that idea for a whole day - drinks and pizza included.

My main idea was to create something that could be fun to build and be useful somehow to others. I’d figured out that since Confitura was just around a corner I could make a game, that would be playable at TouK’s booth at the conference venue. This idea seemed good enough to attract Rafał Nowak @RNowak3 and Marcin Jasion @marcinjasion - two TouK employees, that with me formed a team for the hackathon.

Confitura 01

The initial plan was to develop a simple mario-style game, with preceduraly generated levels, random collectible items and enemies. One of the ideas was to introduce Confitura Man as the main character, but due to time constraints, this fall through. We’ve decided to just choose a random available sprite for a character - hence the onion man :)

Confitura 02

How the game is played?

Since we wanted to have a scoreboard and have unique users, we’ve printed out QR codes. A person that would like to play the game could pick up a QR code, show it against a camera attached to the play booth. The start page scanned the QR code and launched the game with username read from paper code.

The rest of the game was playable with gamepad or keyboard.

Confitura game screen

Technicalities

Writing a game takes a lot of time and effort. We wanted to deliver, so we’ve decided to spend some time in the days before the hackathon just to bootstrap the technology stack of our enterprise.

We’ve decided that the game would be written in some Javascript based engine, with Google Chrome as a web platform. There are a lot of HTML5 game engines - list of html5 game engines and you could easily create a game with each and every of them. We’ve decided to use Phaser IO which handles a lot of difficult, game-related stuff on its own. So, we didn’t have to worry about physics, loading and storing assets, animations, object collisions, controls input/output. Go see for yourself, it is really nice and easy to use.

Scoreboard would be a rip-off from JIRA Survivor with stats being served from some web server app. To make things harder, the backend server was written in Clojure. With no experience in that language in the team, it was a bit risky, but the tasks of the server were trivial, so if all that clojure effort failed, it could be rewritten in something we know.

Statistics

During the whole Confitura day there were 69 unique players (69 QR codes were used), and 1237 games were played. The final score looked like this:

  1. Barister Lingerie 158 - 1450 points
  2. Boilerdang Custardbath 386 - 1060 points
  3. Benadryl Clarytin 306 - 870 points

And the obligatory scoreboard screenshot:

Confitura 03

Obstacles

The game, being created in just one day, had to have problems :) It wasn’t play tested enough, there were some rough edges. During the day we had to make a few fixes:

  • the server did not respect the highest score by specific user, it was just overwritting a user’s score with it’s latest one,
  • there was one feature not supported on keyboard, that was available on gamepad - turbo button
  • server was opening a database connection each time it got a request, so after around 5 minutes it would exhaust open file limit for MongoDB (backend database), this was easily fixed - thou the fix is a bit hackish :)

These were easily identified and fixed. Unfortunately there were issues that we were unable to fix while the event was on:

  • google chrome kept asking for the permission to use webcam - this was very annoying, and all the info found on the web did not work - StackOverflow thread
  • it was hard to start the game with QR code - either the codes were too small, or the lighting around that area was inappropriate - I think this issue could be fixed by printing larger codes,

Technology evaluation

All in all we were pretty happy with the chosen stack. Phaser was easy to use and left us with just the fun parts of the game creation process. Finding the right graphics with appropriate licensing was rather hard. We didn’t have enough time to polish all the visual aspects of the game before Confitura.

Writing a server in clojure was the most challenging part, with all the new syntax and new libraries. There were tasks, trivial in java/scala, but hard in Clojure - at least for a whimpy beginners :) Nevertheless Clojure seems like a really handy tool and I’d like to dive deeper into its ecosystem.

Source code

All of the sources for the game can be found here TouK/confitura-man.

The repository is split into two parts:

  • game - HTML5 game
  • server - clojure based backend server

To run the server you need to have a local MongoDB installation. Than in server’s directory run: $ lein ring server-headless This will start a server on http://localhost:3000

To run the game you need to install dependencies with bower and than run $ grunt from game’s directory.

To launch the QR reading part of the game, you enter http://localhost:9000/start.html. After scanning the code you’ll be redirected to http://localhost:9000/index.html - and the game starts.

Conclusion

Summing up, it was a great experience creating the game. It was fun to watch people playing the game. And even with all those glitches and stupid graphics, there were people vigorously playing it, which was awesome.

Thanks to Rafał and Michał for great coding experience, and thanks to all the players of our stupid little game. If you’d like to ask me about anything - feel free to contact me by mail or twitter @zygm0nt

Recently at TouK we had a one-day hackathon. There was no main theme for it, you just could post a project idea, gather people around it and hack on that idea for a whole day - drinks and pizza included.

My main idea was to create something that could be fun to build and be useful somehow to others. I’d figured out that since Confitura was just around a corner I could make a game, that would be playable at TouK’s booth at the conference venue. This idea seemed good enough to attract >Conclusion