jUnit i mockowanie, część 1.

W moim projekcie do pisania testów jednostkowych będę używać biblioteki jUnit. Ale czym tak właściwie są testy jUnitowe? Jak sama nazwa wskazuje są to pojedyncze testy, które sprawdzają nam naszą funkcjonalność w jak największej izolacji. Może to być testowanie pojedynczej metody, czy klasy. Wystrzegamy się tutaj testów, które wykorzystują więcej niż jedną klasę, a (o zgrozo!), tym bardziej zależności między jednym testem a drugim. W przeciwnym wypadku takie testy narobią nam więcej kłopotu niż pożytku.

Testy jednostkowe są testami niskiego poziomu, pozwalające wykryć wiele błędów logicznych naszych klas/metod. Pozwalają również na refaktorowanie naszego kodu z większą pewnością, ponieważ dobre testy powiedzą nam, kiedy nasze zmiany wpłynęły na działanie fragmentu kodu i oczekiwany wynik. Testy jednostkowe są testami pisanymi przez programistów w danym języku, więc każdy z osobna jest za nie odpowiedzialny.

Jako, że sam piszę moją aplikację w Eclipse, tak i tutaj będę opierał się właśnie na tym IDE, proponując i polecając różne ciekawe i pomocne wtyczki, tym razem, do testowania.

Wszystko fajnie, pięknie, ale jak właściwie napisać swój pierwszy jUnitowy test? Opierając się na projekcie mavenowym, pierwsze co trzeba zrobić, to dopisać do swojego POM’a zależności, które pozwolą nam użyć bibliotek wspomagających testowanie:

Prosta klasa Item, która będziemy testować :

 

Antek w komentarzu wspomniał o fajnej bibliotece do asercji poprawiającej czytelność. Poniżej przykład tej samej klasy testowej napisanej przy użyciu biblioteki AssertJ. Prawda, że przyjemniej się czyta ?
Przy okazji wspomnę, że do implementacji metod hashCode i equals użyłem biblioteki commons-lang3, o czym więcej ciekawych rzeczy możecie przeczytać Tutaj.

 

I tu trafiamy na miejsce, w którym wspomnę o pierwszej wtyczce do Eclipse – moreUnit. Dodaje ona kilka bardzo fajnych funkcjonalności. Te, z których osobiście korzystam to: przejście od razu do klasy testującej ( a zarazem do konkretnego, wybranego przez nas testu ) od klasy implementacji – skrót    ctrl+ j. Skrót ten ma też jeszcze jedną funkcję. Jeśli dana klasa nie ma swojej klasy testowej, proponuje stworzenie (i tworzy) klasę testową i automatycznie umieszcza ją w odpowiednim katalogu.
Drugi bardzo ważny skrót : ctrl + r – uruchamia testy w obrębie klasy, w której się znajdujemy.

Test naszej klasy Item mógłby wyglądać następująco :

Adnotacja @Before oznacza metodę, która będzie wykonywać się przed każdym testem, który z kolei oznacza się adnotacją @Test. Pozwala nam to zachować izolację wykonywanych testów. Asercje pozwalają nam przetestować oczekiwania z rzeczywistością i w razie rozbieżności, nasz test się zaczerwieni i nie przejdzie.

Wspomniałem już niejednokrotnie o tym, jak istotne jest testowanie w izolacji, czyli bez dotykania klas z zewnątrz. Co jednak zrobić w przypadku, kiedy funkjonalność jednej klasy opiera się na funkjonalności drugiej klasy? O tym w części drugiej.

2 thoughts on “jUnit i mockowanie, część 1.

  1. Hej! Słyszałeś o bibliotece AssertJ? Bardzo przyjemna biblioteka do sprawdzania czy zwrócone wartości są takie, jakich oczekiwaliśmy. Polecam na nią zerknąć 🙂 imo dzięki niej testy są bardziej przejrzyste, a czasami zdecydowanie ułatwia nam nasz pracę 🙂

    • Hej! Faktycznie fajna biblioteka. Wydaje mi się, że gdzieś widziałem taki styl pisania testów, ale nie zgłębiałem tematu. Teraz, jak powiedziałeś to wydaje się, że jednak warto : D

Leave a Reply

Your email address will not be published. Required fields are marked *