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

byRafal P
March 25, 2013
7 minute read

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 ?

Testy – jak to się robi ?

Testy – jak można to robić lepiej ?

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.

A co z refaktoringiem ?

Czy to już wszsystko ?

Rafal P

— Previous article

[:en] Operational problems with Zookeeper

Next article —

Usability - otwarte spotkanie

xquery4j in action

byRafal Rusin
January 20, 2010

In my previous article, I introduced a wrapper library for Saxon, xquery4j http://github.com/rafalrusin/xquery4j. Here, I will explain how…

DDevelopment & Design

How to use mocks in controller tests

byTomasz Kalkosiński
August 20, 2012

Even since I started to write tests for my Grails application I couldn't find many articles on using mocks. Everyone is talking about tests and TDD but if you search for it there isn't many articles.

Today I want to share with you a test with mocks for a simple and complete scenario. I have a simple application that can fetch Twitter tweets and present it to user. I use REST service and I use GET to fetch tweets by id like this: http://api.twitter.com/1/statuses/show/236024636775735296.json. You can copy and paste it into your browser to see a result.

My application uses Grails 2.1 with spock-0.6 for tests. I have TwitterReaderService that fetches tweets by id, then I parse a response into my Tweet class.


class TwitterReaderService {
    Tweet readTweet(String id) throws TwitterError {
        try {
            String jsonBody = callTwitter(id)
            Tweet parsedTweet = parseBody(jsonBody)
            return parsedTweet
        } catch (Throwable t) {
            throw new TwitterError(t)
        }
    }

    private String callTwitter(String id) {
        // TODO: implementation
    }

    private Tweet parseBody(String jsonBody) {
        // TODO: implementation
    }
}

class Tweet {
    String id
    String userId
    String username
    String text
    Date createdAt
}

class TwitterError extends RuntimeException {}

TwitterController plays main part here. Users call show action along with id of a tweet. This action is my subject under test. I've implemented some basic functionality. It's easier to focus on it while writing tests.


class TwitterController {
    def twitterReaderService

    def index() {
    }

    def show() {
        Tweet tweet = twitterReaderService.readTweet(params.id)
        if (tweet == null) {
            flash.message = 'Tweet not found'
            redirect(action: 'index')
            return
        }

        [tweet: tweet]
    }
}

Let's start writing a test from scratch. Most important thing here is that I use mock for my TwitterReaderService. I do not construct new TwitterReaderService(), because in this test I test only TwitterController. I am not interested in injected service. I know how this service is supposed to work and I am not interested in internals. So before every test I inject a twitterReaderServiceMock into controller:


import grails.test.mixin.TestFor
import spock.lang.Specification

@TestFor(TwitterController)
class TwitterControllerSpec extends Specification {
    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)

    def setup() {
        controller.twitterReaderService = twitterReaderServiceMock
    }
}

Now it's time to think what scenarios I need to test. This line from TwitterReaderService is the most important:


Tweet readTweet(String id) throws TwitterError

You must think of this method like a black box right now. You know nothing of internals from controller's point of view. You're only interested what can be returned for you:

a TwitterError can be thrown
null can be returned
Tweet instance can be returned

This list is your test blueprint. Now answer a simple question for each element: "What do I want my controller to do in this situation?" and you have plan test:

show action should redirect to index if TwitterError is thrown and inform about error
show action should redirect to index and inform if tweet is not found
show action should show found tweet

That was easy and straightforward! And now is the best part: we use twitterReaderServiceMock to mock each of these three scenarios!

In Spock there is a good documentation about interaction with mocks. You declare what methods are called, how many times, what parameters are given and what should be returned. Remember a black box? Mock is your black box with detailed instruction, e.g.: I expect you that if receive exactly one call to readTweet with parameter '1' then you should throw me a TwitterError. Rephrase this sentence out loud and look at this:


1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }

This is a valid interaction definition on mock! It's that easy! Here is a complete test that fails for now:


import grails.test.mixin.TestFor
import spock.lang.Specification

@TestFor(TwitterController)
class TwitterControllerSpec extends Specification {
    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)

    def setup() {
        controller.twitterReaderService = twitterReaderServiceMock
    }

    def "show should redirect to index if TwitterError is thrown"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }
            0 * _._
            flash.message == 'There was an error on fetching your tweet'
            response.redirectUrl == '/twitter/index'
    }
}


| Failure:  show should redirect to index if TwitterError is thrown(pl.refaktor.twitter.TwitterControllerSpec)
|  pl.refaktor.twitter.TwitterError
 at pl.refaktor.twitter.TwitterControllerSpec.show should redirect to index if TwitterError is thrown_closure1(TwitterControllerSpec.groovy:29)

You may notice 0 * _._ notation. It says: I don't want any other mocks or any other methods called. Fail this test if something is called! It's a good practice to ensure that there are no more interactions than you want.

Ok, now I need to implement controller logic to handle TwitterError.


class TwitterController {

    def twitterReaderService

    def index() {
    }

    def show() {
        Tweet tweet

        try {
            tweet = twitterReaderService.readTweet(params.id)
        } catch (TwitterError e) {
            log.error(e)
            flash.message = 'There was an error on fetching your tweet'
            redirect(action: 'index')
            return
        }

        [tweet: tweet]
    }
}

My tests passes! We have two scenarios left. Rule stays the same: TwitterReaderService returns something and we test against it. So this line is the heart of each test, change only returned values after >>:


1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }

Here is a complete test for three scenarios and controller that passes it.


import grails.test.mixin.TestFor
import spock.lang.Specification

@TestFor(TwitterController)
class TwitterControllerSpec extends Specification {

    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)

    def setup() {
        controller.twitterReaderService = twitterReaderServiceMock
    }

    def "show should redirect to index if TwitterError is thrown"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }
            0 * _._
            flash.message == 'There was an error on fetching your tweet'
            response.redirectUrl == '/twitter/index'
    }

    def "show should inform about not found tweet"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> null
            0 * _._
            flash.message == 'Tweet not found'
            response.redirectUrl == '/twitter/index'
    }


    def "show should show found tweet"() {
        given:
            controller.params.id = '1'
        when:
            controller.show()
        then:
            1 * twitterReaderServiceMock.readTweet('1') >> new Tweet()
            0 * _._
            flash.message == null
            response.status == 200
    }
}


class TwitterController {

    def twitterReaderService

    def index() {
    }

    def show() {
        Tweet tweet

        try {
            tweet = twitterReaderService.readTweet(params.id)
        } catch (TwitterError e) {
            log.error(e)
            flash.message = 'There was an error on fetching your tweet'
            redirect(action: 'index')
            return
        }

        if (tweet == null) {
            flash.message = 'Tweet not found'
            redirect(action: 'index')
            return
        }

        [tweet: tweet]
    }
}

The most important thing here is that we've tested controller-service interaction without logic implementation in service! That's why mock technique is so useful. It decouples your dependencies and let you focus on exactly one subject under test. Happy testing!

DDevelopment & Design

Log4j and MDC in Grails

byRafał Nowak
November 5, 2013

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.