package org.code_house.test.mock;

interface Populator {
    int fill(String value, String[] arguments);
}

Implementacja interfejsu jest bardzo prosta:

package org.code_house.test.mock;

class FillAnswer implements IAnswer<Integer> {
    public Integer answer() throws Throwable {
        // pobranie argumentow
        Object[] arguments = EasyMock.getCurrentArguments();
        String name = (String) arguments[0];
        Object[] values = (Object[]) arguments[1];

        // logika potrzebna do testu
        int populated = 0;
        for (int i = 0; i < values.length; i++) {
            if (values[i] == null) {
                populated++;
                values[i] = name;
            }
        }
        return populated;
    }
}

Test jest również niezbyt skomplikowany – bazuje on na poprzedniej nocie – “Testowanie tablic argumentów z EasyMock”:

package org.code_house.test.mock;

import static org.easymock.EasyMock.*;
import org.easymock.IAnswer;

import java.util.Arrays;

import junit.framework.TestCase;

public class AnswerTest extends TestCase {

    public void testPopulate() {
        Populator populator = createMock(Populator.class);
        expect(populator.fill(eq("Code House"), aryEq(new String[3])))
            .andAnswer(new FillAnswer());
        expect(populator.fill(eq("Code House"), aryEq(new String[] {"1"})))
            .andAnswer(new FillAnswer());
        replay(populator);

        // tablica do wypełnienia
        String[] populated = new String[3];
        int added = populator.fill("Code House", populated);
        assertEquals(3, added);
        // w odpowiedzi oczekujemy dodania 3 nowych elementów
        assertTrue(Arrays.equals(
            new String[] {"Code House", "Code House", "Code House"},
            populated
        ));

        // w tym przypadku nie oczekujemy nowości
        added = populator.fill("Code House", new String[] {"1"});
        assertEquals(0, added);
    }
}

java.lang.AssertionError:
  Unexpected method call find([Ljava.lang.String;@1ad77a7):
    find([Ljava.lang.String;@b8f82d): expected: 1, actual: 0

package org.code_house.test.mock;

import static org.easymock.EasyMock.aryEq;
import static org.easymock.EasyMock.createMock;
import static org.easymock.EasyMock.expect;
import static org.easymock.EasyMock.replay;

import java.util.Collections;
import java.util.List;

import junit.framework.TestCase;

interface Finder {
    List<String> find(String[] names);
}

public class FinderTest extends TestCase {

    public void testFind() {
        Finder mock = createMock(Finder.class);
        expect(mock.find(aryEq(new String[] {"Amy", "Luke"}))).andReturn(
            Collections.EMPTY_LIST);
        replay(mock);

        List<String> list = mock.find(new String[] {"Amy", "Luke"});
        assertTrue(list.isEmpty());
    }
}

Rozwiązaniem tych problemów jest użycie mechanizmu “matcherów”, które są wbudowane w sam szkielet. Najprostszym sposobem na ich użycie jest odwołanie przy pomocy statycznego wywołania którejś z metod EasyMock. Poniżej znajduje się lista dostępnych matcherów. Wartość “given” to argument przekazany w wywołaniu metody.

• eq(X value)
  Argument pasuje jeśli wyrażenie value.equals(given) zwróci true. Dostępny dla wszystkich typów prostych i obiektów.
• anyBoolean(), anyByte(), anyChar(), anyDouble(), anyFloat(), anyInt(), anyLong(), anyObject(), anyShort()
  Dowolna wartość zostanie przepuszczona niezależnie od tego co będzie przekazane. Dostępny dla wszystkich typów.
• eq(X value, X delta)
  Pasuje jeśli aktualna jeśli wyrażenie given jest równe value z dokładnością do delta. Dostępne dla typów float oraz double.
• aryEq(X value)
  Pasuje jeśli wyrażenie Arrays.equals(value, given) zwraca true. Dostępne dla tablic typów prostych jak i dla obiektów.
• isNull()
  Pasuje jeśli given == null. Dostępne tylko dla obiektów.
• notNull()
  Pasuje jeśli given != null. Dostępne tylko dla obiektów.
• same(X value)
  Pasuje jeśli wyrażenie value == given jest prawdziwe. Dostępne tylko dla obiektów.
• isA(Class clazz)
  Pasuje jeśli given instanceof clazz zwraca true. Given może być instancję clazz jak i pochodną.
• lt(X value), leq(X value), geq(X value), gt(X value)
  Zwraca true jeśli given jest mniejsze, mniejsze równe, większe równe bądź większe niż value. Dostępne dla wszystkich numerycznych typów prostych.
• startsWith(String prefix), contains(String substring), endsWith(String suffix)
  Zwraca true jeśli given zaczyna się, zawiera bądź kończy się daną wartością. Dostępne dla argumentów typu String.
• matches(String regex), find(String regex)
  Pasuje jeśli given pasuje w całości do wyrażenia/fragment pasuje. Dostępne dla argumentów typu String.
• and(X first, X second)
  Zwraca true jeśli matcher first oraz second zwracają prawdę.
• or(X first, X second)
  Zwraca true jeśli matcher first bądź second pasuje.
• not(X value)
  Zwraca true jeśli matcher value zwrócił fałsz.

Uzbrojeni w taki zestaw matcherów możemy poprawić kod testu tak by był on poprawny:

public class FinderTest extends TestCase {

    public void testFind() {
        Finder mock = createMock(Finder.class);
        expect(mock.find(aryEq(new String[] {"Amy", "Luke"}))).andReturn(
            Collections.EMPTY_LIST);
        replay(mock);

        List<String> list = mock.find(new String[] {"Amy", "Luke"});
        assertTrue(list.isEmpty());
    }
}

Inny przykład:

public class FinderTest extends TestCase {

    public void testFind() {
        Finder mock = createMock(Finder.class);
        expect(mock.find("Lucy", aryEq(new String[] {"Amy", "Luke"}))).andReturn(
            Collections.EMPTY_LIST);
        replay(mock);

        List<String> list = mock.find("Lucy", new String[] {"Amy", "Luke"});
        assertTrue(list.isEmpty());
    }
}

Warto zwrócić uwagę na to, że jeśli korzystamy dla matchera aby dopasować argument to musimy zrobić to dla wszystkich, inaczej poleci wyjątek:

java.lang.IllegalStateException: 2 matchers expected, 1 recorded.

Stąd nasz test w końcowej postaci powinien wyglądać następująco:

package org.code_house.test.mock;

import static org.easymock.EasyMock.aryEq;
import static org.easymock.EasyMock.createMock;
import static org.easymock.EasyMock.eq;
import static org.easymock.EasyMock.expect;
import static org.easymock.EasyMock.replay;

import java.util.Collections;
import java.util.List;

import junit.framework.TestCase;

interface Finder {
    List<String> find(String[] names);

    List<String> find(String name, String[] names);
}

public class FinderTest extends TestCase {

    public void testFind() {
        Finder mock = createMock(Finder.class);
        expect(mock.find(eq("Lucy"), aryEq(new String[] {"Amy", "Luke"}))).andReturn(
            Collections.EMPTY_LIST);
        replay(mock);

        List<String> list = mock.find("Lucy", new String[] {"Amy", "Luke"});
        assertTrue(list.isEmpty());
    }
}

Tych, którzy chcieliby dowiedzieć się więcej o testach na przykładzie JUnit i Javy zapraszam się do zapoznania z bardzo dobrą pozycją na temat testów jednostkowych, z którą miałem przyjemność się zetknąć.

JUnit. Pragmatyczne testy jednostkowe w Javie to tłumaczenie książki Pragmatic Unit Testing in Java z serii The Pragmatic Programmers. Nie wspominam tu o tej książce jak i całej serii przypadkowo, ponieważ pragmatyzm jest główną domeną tego bloga.

Tytuł ten traktuje o rzeczy bardzo ważnej, jaką są bez wątpienia testy jednostkowe. Nie jest to sucha referencja opisująca możliwości JUnit ale przewodnik i poradnik – czyli nie tylko o tym czym testować ale po co i w jaki sposób to robić. Sam język w którymś momencie schodzi na drugi plan a ważna staje się na prawdę idea i szczytny cel, jakim jest wykluczanie błędów przed wdrożeniem aplikacji, tak by nie musiał się o nich w ogóle dowiadywać klient.

W książce znajduje się wiele przykładów i rozważań, pisanych lekkim językiem, całość czyta się lekko i przyjemnie. Jest to bodajże najczęściej wypożyczana pozycja z mojej domowej biblioteczki. W każdej kolejnej pracy (a troszkę ich w międzyczasie było :)) staram się komuś polecić tą pozycję i odzew jest zawsze pozytywny, co dowodzi, że praca autora włożona w tytuł była bardzo przemyślana. Z najważniejszych elementów, które zostają w książce omówione należy wymienić definiowanie warunków brzegowych, wykorzystanie “obiektów imitacji”
(ang. mock objects) z użyciem biblioteki Easy Mock oraz projektowanie kodu przyjaznego dla testów. Chyba wszyscy się ze mną zgodzą że są to elementy nieodzowne podczas tworzenia testów.

Na zakończenie przytoczę dwa akapity które najbardziej zapamiętałem z całej pozycji.

Gdyby architekci sprawdzali mosty w taki sam sposób jak większość programistów to na świeżo wybudowanym moście środkiem jezdni przejeżdżałby jeden malutki samochód w ciepły dzień, bez jakiegokolwiek wiatru i innych zakłóceń atmosferycznych. (o warunkach brzegowych)

Z testami jednostkowymi jest jak ze strzyżeniem trawnika. Jeśli jest on dobrze utrzymany to jego uporządkowanie nie jest zadaniem trudnym. Jeśli jednak nasz trawnik zarośnie (w projekcie nie będzie testów jednostkowych) i pojawią się chwasty (błędy) to jego uporządkowanie (wprowadzenie testów) będzie zadaniem bardzo czasochłonnym. (o filozofii testowania)

Koniec końców, siejąc pragmatyczną propagandę na rzecz testów :), zachęcam wszystkich do zapoznania się z opisywaną książką. Dla praktyków zawiera ona kilka trafnych spostrzeżeń a dla laików będzie znakomitym sposobem na wdrożenie się w temat testów.

^{Szkic tej noty czekał na publikację ponad rok, stąd może być on troszkę nieskładny.}

W tym miejscu bazuję na swoim bądź co bądź skromnym doświadczeniu, które nabyłem pracując w AGI. Była to pierwsza firma, w której spotkałem się z wykorzystaniem testów jednostkowych. Pamiętam do dzisiaj walki o 70% pokrycie kodu testami. :).
Nie mniej, nie robiliśmy tego tylko po to by zobaczyć zielone słupki w raporcie wygenerowanym przez PHP Unit. Takie pokrycie kodu testami gwarantuje znaczne ograniczenie błędów wychodzących z czasem, głównie dlatego, że znajduje się już podczas pisania testów.

Zasadniczo możemy wyróżnić dwa podejścia do testów – bardzo inwazyjne – projektowanie sterowane testami (ang.Test Driven Development), czyli opieranie się w całości na testach. Wygląda to mniej więcej w ten sposób, że tworzymy interfejs, do niego test i testujemy przy użyciu mock objects (w wolnym przekładzie można to traktować jako obiekty pozorne). Jednym z założeń jest to, że testy nie mogą się zmieniać.
Drugie podejście, z którego korzystaliśmy to, w sumie nienazwane, wspomaganie testami. W skrócie, pisząc klasę piszemy również test do niej, tak by na bieżąco sprawdzać poprawność działania kodu. Jeśli zmieni się interfejs etc, testy również mogą się zmienić.

Korzyści

Nie pozwól błędom zawładnąć Twoją aplikacją

Tak jak wcześniej wspominałem korzyści, które niosą ze sobą testy jednostkowe to wyłapywanie błędów nim mają szansę coś popsuć. Ile razy szukałeś błędu, który był zakopany tak niewiarygodnie głęboko zakopany, że jego lokalizacja zajęła Ci kilka dni? Ile razy po prostu zrezygnowałeś z walki stosując jakąś brudną protezę? Testy, które sprawdzają niewielkie fragmenty kodu (po prostu pojedyncze metody) lokalizują błędy z dużą dokładnością. Szukanie błędu gdy wiadomo gdzie on tkwi jest znacznie łatwiejsze i mniej czasochłonne. Zwykle to lokalizacja miejsca, gdzie błąd powstaje zajmuje więcej czasu niż jego naprawienie. Jedna metoda, która generuje błędny wynik prowadzi do błędnej implementacji kolejnej, ta z kolei determinuje błąd w innym algorytmie.

Łatwiejszy refaktoring i wprowadzanie zmian w kodzie

Refaktoryzacja ma to do siebie, że źle przeprowadzona, a co gorsza nie sprawdzona potrafi zrodzić spore zamieszanie. Testy jednostkowe pozwalają sprawdzić czy zmiany, które wprowadziliśmy w celu usprawnienia kodu nie niosą ze sobą błędów.
Często zmiany, które wprowadzamy nie mogą być nazwane refaktoryzacją, po prostu dodajemy spory fragment kodu, który może ingerować już w istniejącym. Wybitnym przykładem mogą być tu aspekty (najprościej można to określić jako modyfikowanie zachowania kodu z zewnątrz). Innym po prostu poszerzenie implementacji jakiejś klasy pomocniczej o jedną metodę i na prawdę drobna zmiana w dwóch warunkach istniejącej. Czy masz pewność, że Twój kod działa? Zazwyczaj tak, bo testujesz go “manualnie”, ale czy wiesz, jaki wpływ mają Twoje zmiany na inne fragmenty aplikacji? Być może zmieniona metoda generowała w pewnych okolicznościach błędny wynik, który stał się początkiem wspomnianej lawiny?

Praca w grupie

Testy są szczególnie ważne gdy nad kodem pracuje cały zespół zapanowanie nad całością przedsięwzięcia wymaga wielkiego zaangażowania. Można je ograniczyć wprowadzając konieczność sprawdzania kodu pod kontem jego spójności z pozostałymi fragmentami aplikacji (akapit wyżej). To, że kod działa u Ciebie, nie znaczy, że zadziała u kogoś innego. Są różne platformy sprzętowe, jeszcze różniejsze konfiguracje środowisk. Czy jesteś w stanie zagwarantować, że kod bazujący na jakiejś strukturze katalogów zadziała? Czy zastanawiałeś się jak zareaguje aplikacja gdy jest uruchomiona ze złą konfiguracją? Zapewnij sobie neutralne środowisko testowym, nieskażone niczyim IDE by być pewnym, że to zadziała też u klienta jak i prezesa.

Automatyzacja

Automatyzacja całego procesu jest ważna. Nikt nie będzie siedział non stop i sprawdzał co godzina czy testy są ok bądź się wywalają. Nikt nie ma na to czasu i pieniędzy. Kierownik projektu ma na głowie więcej rzeczy niż tylko testy a programiści “robią swoje”. Nikt nie chce uruchamiać testów, niech zrobi to zatem maszyna. Maszyna, na której będzie stało oddzielne, gołe środowisko specjalnie pod testy. Automat pobierze aktualną wersję kodu i uruchomi testy do niego. Może robić to co godzinę bądź co dwie, ale najlepiej by robił to po każdej zmianie w repozytorium. Programista to zwierz leniwy i zdarza mu się zapomnieć o uruchomieniu testów. Przypomnienie mu o nich przez automat będzie milsze niż reprymenda dwa tygodnie po tym, jak aplikacja przestała działać u wszystkich i znaleziono winnego (vide kozła ofiarnego).

Redukcja kosztów

Jak to określił Ross, testy to jeden ze sposobów na wyprzedzenie kosztów, swoistego rodzaju zapłata dzierżawy. Tracimy czas (pojęcie względne) inwestując w pisanie testów, ale zyskujemy z jego biegiem, ponieważ kod naszej aplikacji po prostu działa. Nie musi nad nim czuwać sztab testerów, którzy klikają i zaznaczają w formularzach “to nie działa” z opisem typu “pole ‘nazwa firmy’ jest ignorowane przy próbie zmiany jego wartości”. Wskazanie miejsc, gdzie rodzi się błąd nie wydaje się trudne. Albo niepodpięte mapowanie do pola, albo źle wygenerowane zapytanie. Banał. Ale spytaj kogoś, kto powie od razu który fragment kodu to robi? Sytuacja nie jest najgorsza, wykryli ją testerzy, ale bywają gorsze, znacznie gorsze. To, że kod się kompiluje nie znaczy, że działa.

Studium pewnego błędu

Załóżmy, że aplikacja działa od 3 miesięcy w środowisku produkcyjnym, u klienta. Nagle okazuje się, że to samo pole nie może zawierać apostrofów, ponieważ powstaje błąd zapytania SQL. Inna sytuacja – dorzucenie & w nazwie powoduje błąd w wyświetlaniu strony. Wpisanie specyficznej wartości w formularzu powoduje pokazanie się białej strony. Esteci się cieszą, ale klienci już nie. Padają gromy ze strony klienta. Obrywają wszyscy od góry do dołu. Warto poświęcić czas na to by mieć komfortowe warunki pracy, z minimalną ilością negatywnych emocji i tarć na linii Ty – Twój zwierzchnik.
Wyeliminowanie błędu pojawiającego się u klienta jest drogie a koszt jest wprost proporcjonalny do ilości klientów. Na błędach tracą wszyscy. Firma traci pieniądze, ponieważ programista musi zlokalizować i naprawić błąd. Programista traci werwę. Nikt z nas nie lubi babrać się w czyimś kodzie, nie wiadomo jaki by on nie był, w poszukiwaniu jakiejś niedoróbki. Jednak najgorsza może być strata wizerunku. Na rynku jest pełno firm. Czy może poszczycić się Twoja? Wszyscy kochają jakość i wszyscy się nią chwalą, dopóki nie dojdzie do konfrontacji z rzeczywistością. Zadbaj by Twój produkt był dostarczony z minimalną ilością błędów, a możesz liczyć na to, że klient wróci i być może pociągnie za sobą swoich partnerów biznesowych.

Zaproszenie do dyskusji

Na końcu pragnę zachęcić wszystkich do zadawania pytań jak i dzielenia się swoimi doświadczeniami. Jakie są Twoje doświadczenia z testami jednostkowymi? W jaki sposób przebiegało ich wdrożenie? Czy jesteś sceptycznie nastawiony? Może jesteś przeciwko? To tylko część z tematów, które możemy poruszyć.