Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

JUnit Test z Netbeansem

Jak mówiłem we wcześniejszym wpisie tak też robię – przedstawię, krótko czym są testy jednostkowe i jak je wykonać w środowisku NetBeans przy użyciu JUnit Test.

Testy jednostkowe służą do sprawdzania poprawności wykonywania takich struktur programowych, jakimi są metody i klasy. Najczęściej sprawdzamy jak wykonują się metody, porównując wyniki otrzymane po wykonaniu z oczekiwanymi wynikami. Jako osoby piszące programy musimy wiedzieć jaki rezultat powinniśmy otrzymać dla podanych przez nas danych wejściowych.
To krótki wstęp z teorii mamy za sobą. Przejdźmy dalej...

Czym jest JUnit Test? Narzędziem do tworzenia i wykonywania testów jednostkowych oprogramowania pisanego w języku Java... :P za krótko? Już dokładniej opisuję. Na JUnit test składa się biblioteka klas umożliwiająca wykonywanie specjalnie przygotowanych programów testowych. W IDE NetBeans, z którym JUnit jest zintegrowane, występuje kreator do generowania testów, które musimy sami uzupełnić o swój kod, ponieważ tworzy on tylko klasy testowe wraz z metodami. Kod w metodach musimy niestety sami uzupełnić :P.

Teraz warto wspomnieć o adnotacjach w klasach testowych. Są to między innymi:

  • @Test – występuję przed każdą metodą testową,
  • @BeforeClass – występuje przed metodą, która jest wykonywana przed uruchomieniem testów. Można w niej utworzyć obiekt klasy testowej, zainicjalizować jej atrybuty itp..
  • @AfterClass – oznacza metodę, która ma być wywołana po zakończeniu wszystkich testów. Można w niej np. zamknąć połączenie z bazą danych, zapisać plik lub po prostu wypisać na konsoli „Hura” lub coś innego co jest niezbędne po wykonaniu testów.
  • @Before – metoda oznaczona tą adnotacją, będzie wywoływana przed wykonaniem każdej metody testowej.
  • @After – oznacza metodę, która ma być wywoływana po każdej metodzie testowej.

Teraz druga ważna sprawa – asercje. To nic innego jak sprawdzenia poprawności.
W JUnit Test dostępnych jest wiele a najczęściej stosowane (przynajmniej przeze mnie) to:"assertEquals", "assertNotNull", "assertTrue", "assertFalse" itp. . Możliwe jest także zgłoszenie błędu wywołując "fail". Czym są te sprawdzenia?? To dzięki nim możemy sprawdzić w prosty sposób czy nasza metoda wykonała się prawidłowo i zwraca wyniki zgodne z oczekiwanymi.

Nie rozumiesz tego jeszcze?? Nie przekonuje Ciebie to jeszcze i nadal wolisz wypisywać na konsoli stan obiektów podczas wykonania programu. Może przykład Ci pomoże to zrozumieć.

W NetBeans`ie tworzymy nowy projekt z prostą klasę „Square”, zawierającą jeden atrybut typu „double” - "side", klasę uzupełniam o konstruktory i metody dostępowe do atrybutu. Dodatkowo dodaję metodę „getSquere” zwracającą pole kwadratu.

Teraz pora na tworzenie testów JUnti, a więc klikamy prawym klawiszem na klasę jak to jest pokazane na poniższym rysunku i wybieramy Tools › Create Junit Tests.

Następnie wybieramy JUnit Test 4.

Podajemy nazwę klasy testowej i zaznaczamy pola potrzebne wg. naszego uznania i w zależności o tego jakie testy będziemy prowadzić. Na rysunku powyższym widzimy, że możemy testować metody publiczne, chronione i prywatne. Po zakończeniu tworzy nam się nowy pakiet ("Test Packages" ).
Otwieramy nasz nowo utworzony plik i widzimy wygenerowane metody.
Gdybyśmy teraz chcili uruchomić test, wszystkie metody testowe zakończyłyby się błędem ze względu na obecność linijki „fail("The test case is a prototype.");”. Pokazane to zostało na zrzucie poniżej razem ze sposobem uruchomienia testu.
Trzeba wprowadzić zmiany w teście:
- dodajemy atrybut s klasy "Squere" ;
-w konstruktorze tworzymy nowy obiekt klasy „Squere” i przypisujemy refernecje do atrybutu „s”;
- w metodzie „setUp” ustawiamy bok kwadratu na 1;
-uzupełniamy metody tak jak przedstawiono na zrzucie i uruchamiamy test;

Jak widać test się zakończył błędem w metodzie zwracającej długość boku, mimo że wydaje się ona być zaimplementowana poprawnie. I tak jest. Jeżeli ktoś nieuważnie śledził kod klasy testującej lub nie czytał ze zrozumieniem, to nie zwrócił uwagi na klasę oznaczoną adnotacją "@Before" , w której długość boku została zmieniona na 1.0, stąd ten błąd(w metodzie "testSetSide" należy jak rezultat oczekiwany ustawić 1.0). Ale chwila...w metodzie "testGetSquere" długość boku została ustawiona na -1.0 a metoda przeszła test.

Ponieważ (-1) * (-1) = 1. Proste i przedszkolak to wie. Problem leży w metodzie "setSide" klasy "Squere", ponieważ należy się sprawdzać czy długość nie jest ujemna, i albo przypisywać wartość bezwzględną lub wyrzucać wyjątek. Zmieniamy więc metodę "setSide" oraz metodę testującą "testGetSquere". Po uruchomieniu test wykonuje się poprawnie w 100 procentach.

Należy testy rozszerzyć i powtórzyć na różnych liczbach: np. "Double.MAX_VALUE" etc. , ponieważ do tego one służą.
Dzięki JUnit testy jednostkowe stają się łatwiejsze. Przy dużych projektach nie ma potrzeby kompilowania całego programu (może zajmować to dużo czasu) i wypisywać stan obiektów podczas wykonania. Łatwiej jest zrobić oddzielną klasę i wykonać testy.
Może (raczej na pewno ) podany przeze mnie prymitywny przykład nie przekona Wielu osób do korzystania z tego narzędzia, ale warto samemu spróbować, zobaczyć jak to działa.

Więcej może wyczytacie pod tym adresem natomiast dla osób korzystających z Eclipse przydatna może się okazać ta strona.

W następnym wpisie postaram się przybliżyć debugowanie w NetBeans`ie.

Pozdrawiam wszystkich, którzy przedarli się przez moje wypociny aż tutaj ;). 

oprogramowanie programowanie

Komentarze

0 nowych
GL1zdA   11 #1 31.01.2012 21:02

Dobry wpis, bardzo dobrze zilustrowany. Przydałoby się trochę więcej o samej teorii testowania (różne metody, dlaczego warto, mocki etc.).

jullo89   3 #2 31.01.2012 21:11

Dzięki, ujmę to w następnym wpisie "Debugowanie" ;]

NRN   9 #3 31.01.2012 22:06

W NetBeans'ie wygląda to nieco lepiej niż w Eclipse... nas uczyli na tym drugim, i przyznam, że nie do końca wszystko mi się udawało. Np. w starszej wersji Eclipse raz działało, raz nie ;p

Będziesz robił jeszcze o pokryciu kodu, sposobach pokrycia dla warunków, pętli i ogólnie kodu i o jakichś aplikacjach do badania tego na podstawie testów jednostkowych? :)

jullo89   3 #4 31.01.2012 22:45

Może zrobię jeszcze... W planach mam debugowanie w NetBeans`ie oraz użycie Profilera do sprawdzania wydajności (głównie zużycie pamięci, wykonanie wątków, działania GC etc.). Wszystko zależy od czasu, którego u Wszystkich jest coraz mniej...

Zulowski   8 #5 01.02.2012 14:18

moar!
Bardzo dobry wpis, przydało by się byś opisał to nawet szerzej.

jullo89   3 #6 01.02.2012 16:28

dzięki za zainteresowanie ;) nie chciałem rozwlekać, żeby nie zniechęcać czytających, chociaż jest ich nie wielu ;]

  #7 05.02.2012 19:26

zaczalem sie uczyc programowania w javie i powiem szczerze - jest ciezko :(
bardzo mi sie podoba blog, bede zagladal regularnie na strone :)

  #8 05.11.2012 00:24

Mam pytania (to mój pierwszy kontakt z JUnit więc może coś źle zrozumiałem)
- testy metod nie powinny być niezależne? Bo jeżeli w 'w metodzie „setUp” ustawiamy bok kwadratu na 1' to potem test metody getSide zakłada, że dobrze zadziałała metoda setSide
- w metodzie testSetSide nic nie jest sprawdzane (jakby z metody testGetSide usunąć linię z assertEquals... to test też by się powiódł...)
- czemu nie widać na żadnym zrzucie testów chyba najważniejszej tu metody czyli testGetSquare ?
- tego też nie rozumie - kiedy 'w metodzie "testGetSquere" długość boku została ustawiona na -1.0' ?
- czy ten artykuł jest skończony? :P

  #9 07.08.2015 19:48

Fajny artykuł. Przydał mi się, dziękuje.