IDZ DO

PRZYKADOWY ROZDZIA
SPIS TRECI

KATALOG KSIEK
KATALOG ONLINE
ZAMW DRUKOWANY KATALOG

TWJ KOSZYK
DODAJ DO KOSZYKA

CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK

CZYTELNIA
FRAGMENTY KSIEK ONLINE

JUnit. Pragmatyczne
testy jednostkowe w Javie
Autorzy: Andy Hunt, Dave Thomas
Tumaczenie: Jaromir Senczyk
ISBN: 83-246-0406-5
Tytu oryginau: Pragmatic Unit Testing in Java with JUnit
Format: B5, stron: 192

Przetestuj swoje aplikacje podczas ich tworzenia

Poznaj struktur testw jednostkowych
Stwrz poprawne testy jednostkowe
Wykorzystaj moduy testowe w projekcie
Testy jednostkowe s niezwykle wanym narzdziem programisty. Przeprowadzane
podczas pisania aplikacji pozwalaj na sprawdzenie poprawnoci kodu, wyapanie
bdw i szybkie usunicie ich. W nowoczesnych metodykach wytwarzania
oprogramowania testy jednostkowe s jednymi z najwaniejszych elementw procesu.
Tworzenie systemw bez korzystania z testw jednostkowych czsto porwnywane
jest do pisania programw na kartce. Nowoczesne narzdzia takie, jak JUnit bardzo
uatwiaj przeprowadzanie testw jednostkowych, integrujc si ze rodowiskami
programistycznymi.
Ksika JUnit. Pragmatyczne testy jednostkowe w Javie to wprowadzenie do tematyki
testw jednostkowych. Czytajc j poznasz ich znaczenie i nauczysz si stosowa JUnit
do projektowania i wykorzystywania testw. Dowiesz si, jak projektowa testy
jednostkowe w oparciu JUnit, co testowa za ich pomoc i gdzie umieszcza kod
testowy. W ksice przeczytasz te o zasadach projektowania atwego do testowania
kodu oraz programowaniu sterowanym testami.
Cele przeprowadzania testw jednostkowych
Planowanie testw
Implementacja testw z wykorzystaniem JUnit
Zasady stosowania testw
Automatyzowanie testw
Okrelanie czstotliwoci testowania
Projektowanie kodu pod ktem testowania

Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl

Przekonaj si, jak bardzo testy jednostkowe uatwi Ci prac

Przedmowa ..............................................................................................7
Rozdzia 1. Wprowadzenie ..................................................................11
Zaufanie do tworzonego kodu .......................................................................... 12
Na czym polegaj testy jednostkowe? ................................................................ 13
Po co zajmowa si testami jednostkowymi? ...................................................... 14
Co chcemy osign? ....................................................................................... 15
Jak testowa? ................................................................................................... 17
Wymwki od testowania .................................................................................. 18
Zawarto ksiki ............................................................................................ 23
Rozdzia 2. Najprostsze testy jednostkowe ......................................25
Planowanie testw ........................................................................................... 26
Testowanie prostej metody ............................................................................... 28
Wicej testw .................................................................................................. 33
Rozdzia 3. Implementacja testw JUnit ..........................................35
Struktura testw jednostkowych ........................................................................ 35
Asercje JUnit .................................................................................................. 37
Szkielet JUnit ................................................................................................. 40

JUnit. Pragmatyczne testy jednostkowe w Javie

Kompozycja testw JUnit ................................................................................ 42

Niestandardowe asercje JUnit .......................................................................... 47
JUnit i wyjtki ................................................................................................. 49
Jeszcze o nazwach ............................................................................................ 51
Szkielet JUnit ................................................................................................. 52
Rozdzia 4. Co testowa? .....................................................................53
Czy wyniki s poprawne? ................................................................................. 54
Warunki brzegowe ........................................................................................... 57
Sprawdzanie relacji zachodzcych w odwrotnym kierunku .................................. 59
Kontrola wynikw na wiele sposobw ............................................................... 60
Wymuszanie warunkw powstawania bdw .................................................... 61
Charakterystyka efektywnociowa ..................................................................... 61
Rozdzia 5. Warunki brzegowe ...........................................................65
Zgodno ....................................................................................................... 66
Uporzdkowanie ............................................................................................. 68
Zakres ............................................................................................................ 69
Referencja ...................................................................................................... 73
Istnienie .......................................................................................................... 74
Liczno ......................................................................................................... 75
Czas ............................................................................................................... 78
Zrb to sam .................................................................................................... 79
Rozdzia 6. Stosowanie obiektw imitacji ........................................85
Proste namiastki .............................................................................................. 86
Obiekty imitacji ............................................................................................... 87
Testowanie serwletu ........................................................................................ 92
Easy Mock ..................................................................................................... 96
Rozdzia 7. Waciwoci poprawnych testw jednostkowych ....101
Automatyzacja .............................................................................................. 102
Kompletno ................................................................................................. 103
Powtarzalno ............................................................................................... 105

Spis treci

Niezaleno ................................................................................................. 106

Profesjonalizm .............................................................................................. 107
Testowanie testw ......................................................................................... 109
Rozdzia 8. Projekt i testowanie ......................................................113
Gdzie umieci kod testowy ............................................................................ 113
Testowanie i kurtuazja ................................................................................... 117
Czstotliwo testw ...................................................................................... 119
Testy i istniejcy kod ..................................................................................... 120
Testy i recenzje ............................................................................................. 123
Rozdzia 9. Zagadnienia projektowania ..........................................127
Projektowanie atwo testowalnego kodu .......................................................... 128
Refaktoring i testowanie ................................................................................. 130
Testowanie niezmiennikw klas ...................................................................... 143
Projektowanie sterowane testami .................................................................... 145
Testowanie poprawnoci parametrw ............................................................. 147
Dodatek A Puapki .............................................................................149
Dopki kod dziaa ......................................................................................... 149
Test ognia ................................................................................................. 150
Dziaa na mojej maszynie ........................................................................... 150
Problemy arytmetyki zmiennoprzecinkowej ...................................................... 151
Testy zajmuj zbyt wiele czasu ....................................................................... 152
Testy cigle zawodz ..................................................................................... 152
Testy zawodz na niektrych maszynach ......................................................... 153
Metoda main nie jest wykonywana .................................................................. 153
Dodatek B Instalacja JUnit ...............................................................155
Instalacja z wiersza polece ............................................................................ 156
Czy JUnit dziaa? .......................................................................................... 157
Dodatek C Szkielet testw JUnit .....................................................159
Klasa pomocnicza ......................................................................................... 161
Podstawowy szablon ...................................................................................... 163

JUnit. Pragmatyczne testy jednostkowe w Javie

Dodatek D Zasoby ...............................................................................165

W internecie ................................................................................................. 165
Bibliografia ................................................................................................... 168
Dodatek E Pragmatyczne testy jednostkowe
podsumowanie ............................................................................169
Dodatek F Rozwizania wicze ......................................................173
Skorowidz ............................................................................................185

rudno przewidzie wszystkie moliwe bdy w dziaaniu klasy lub

metody. Jeli mamy sporo dowiadczenia w tym zakresie, to intuicyjnie rozpoznajemy miejsca, w ktrych mog pojawi si kopoty, i dziki temu koncentrujemy si najpierw na przetestowaniu wanie tych miejsc.
Jednak dla mniej dowiadczonych programistw wykrywanie kopotliwych
obszarw czsto jest frustrujcym zadaniem. Tym bardziej e szczeglnie
atwo przychodzi ono uytkownikom kocowym, co jest nie tylko irytujce,
ale moe stanowi take gwd do trumny niejednej kariery programisty.
Dlatego niezwykle cenne s wszelkie wskazwki mogce nam wskaza lub
choby przypomnie obszary, na ktre szczeglnie naley zwrci uwag podczas testowania.
Przyjrzyjmy si zatem szeciu rnym obszarom testowania, ktrych wykorzystanie powinno zwikszy nasz skuteczno w wykrywaniu bdw:
t

Czy wyniki s poprawne?

Czy warunki brzegowe zostay prawidowo okrelone?

Czy mona sprawdzi relacje zachodzce w odwrotnym

kierunku?

Czy mona sprawdzi wyniki, uzyskujc je w alternatywny

sposb?

54

JUnit. Pragmatyczne testy jednostkowe w Javie

t

Czy mona wymusi warunki zajcia bdu?

Czy charakterystyka efektywnociowa jest poprawna?

Czy wyniki s poprawne?

Pierwszy, najbardziej oczywisty obszar testowania to sprawdzenie, czy
wyniki dziaania testowanych metod s poprawne.
Kontrol wynikw przedstawilimy w rozdziale 2. na przykadzie prostej
metody zwracajcej najwikszy element listy.
Testy te s zwykle najatwiejsze do przeprowadzenia, a wiele spodziewanych wynikw czsto okrelonych jest w specyfikacji wymaga. Jeli nie,
musisz odpowiedzie sobie na pytanie:
Skd mam wiedzie, czy kod dziaa poprawnie?
Jeli znalezienie satysfakcjonujcej odpowiedzi na to pytanie nie jest moliwe, tworzenie kodu i jego testw moe okaza si kompletnym marnotrawstwem czasu. A co w przypadku, gdy wymagania dopiero si krystalizuj?
Czy oznacza to, e nie moemy rozpocz pisania kodu, dopki wymagania nie zostan dokadnie sprecyzowane?
Nie, wcale nie. Jeli ostateczne wymaganie nie s jeszcze znane lub kompletne, zawsze moesz wymyli wasne wymagania jako punkt odniesienia.
Moe okaza si, e nie s one poprawne z punktu widzenia uytkownika,
ale dziki nim wiesz, jak powinien wedug Ciebie dziaa kod, i potrafisz
odpowiedzie na postawione wczeniej pytanie.
Oczywicie musisz potem, wsplnie z uytkownikami, zweryfikowa swoje
zaoenia. Definicja poprawnoci wynikw moe zmienia si w trakcie
powstawania kodu, ale na kadym etapie jego tworzenia powiniene mc
stwierdzi, czy kod dziaa tak, jak zaoye.

Rozdzia 4. Co testowa?

55

Stosowanie plikw zawierajcych dane testowe

W przypadku zestaww testw wymagajcych duej iloci danych wejciowych mona rozway ich umieszczenie (by moe wraz z oczekiwanymi
wynikami) w osobnych plikach wczytywanych przez testy jednostkowe.
Implementacja takiego rozwizania nie jest skomplikowana i niekoniecznie
musi od razu wymaga zastosowania jzyka XML1. Poniej przedstawiona zostaa wersja testu TestLargest, ktra wczytuje wszystkie testy z pliku.
import
import
import
import

junit.framework.*;
java.io.*;
java.util.ArrayList;
java.util.StringTokenizer;

public class TestLargestDataFile extends TestCase {

public TestLargestDataFile(String name) {
super(name);
}
/* Wykonuje testy zapisane w pliku testdata.txt (nie testuje
* przypadku wyjtku). Wyrzuca wyjtek w przypadku,
* gdy ktra operacja wejcia i wyjcia zakoczy si bdem.
*/
public void testFromFile() throws Exception {
String line;
BufferedReader rdr = new BufferedReader(
new FileReader(
"testdata.txt"));
while ((line = rdr.readLine()) != null) {
if (line.startsWith("#")) { // Ignoruje komentarz
continue;
}
StringTokenizer st = new StringTokenizer(line);
if (!st.hasMoreTokens()) {
continue; // Pusty wiersz
}
// Pobiera spodziewany wynik
String val = st.nextToken();
int expected = Integer.valueOf(val).intValue();

To jest oczywicie art, przecie zastosowanie jzyka XML jest obligatoryjne we wszystkich
wspczesnych projektach?

56

JUnit. Pragmatyczne testy jednostkowe w Javie

// Oraz argumenty dla testowanej metody
ArrayList argument_list = new ArrayList();

TestLargestDataFile.java

while (st.hasMoreTokens()) {
argument_list.add(Integer.valueOf(
st.nextToken()));
}
// Zamienia list obiektw w tablic typu podstawowego
int[] arguments = new int[argument_list.size()];
for (int i=0; i < argument_list.size(); i++) {
arguments[i] = ((Integer)argument_list.
get(i)).intValue();
}
// Wykonuje asercj
assertEquals(expected,
Largest.largest(arguments));
}
}
}

Plik danych testowych ma bardzo prosty format kady wiersz zawiera

zbir wartoci. Pierwsza z nich jest oczekiwanym wynikiem, a pozostae argumentami testowanej metody. Dodatkowo zastosowanie znaku # na pocztku wiersza umoliwia wprowadzanie komentarzy.

testdata.txt

A oto przykad zawartoci takiego pliku:

#
# Proste testy:
#
9 7 8 9
9 9 8 7
9 9 8 9
#
# Testy z uyciem wartoci ujemnych:
#
-7 -7 -8 -9
-7 -8 -7 -8
-7 -9 -7 -8
#
# Testy mieszane:
#
7 -9 -7 -8 7 6 4
9 -1 0 9 -7 4
#
# Warunki brzegowe:
#
1 1
0 0
2147483647 2147483647
-2147483648 -2147483648

Rozdzia 4. Co testowa?

57

W przypadku kilku testw jak choby w powyszym przykadzie

wysiek woony w opracowanie odpowiedniego rozwizania nie zwrci si.
Jednak w przypadku zaawansowanej aplikacji wymagajcej przeprowadzenia setek takich testw rozwizanie wykorzystujce pliki danych na pewno
warte jest zainteresowania.
Naley przy tym pamita, e dane testowe obojtnie, czy umieszczone
bezporednio w kodzie, czy w pliku danych testowych same mog by
niepoprawne. Dowiadczenie podpowiada nawet, e prawdopodobiestwo
tego, i dane testowe s nieprawidowe, jest wiksze ni tego, e testowany
kod jest niepoprawny. Zwaszcza jeli dane testowe zostay przygotowane
drog rcznych oblicze lub uzyskane z systemu, ktry zastpujemy naszym
oprogramowaniem (poniewa jego nowe moliwoci mog mie wpyw na
uzyskiwane wyniki). Jeli wyniki testw s niepomylne, warto najpierw
sprawdzi kilka razy poprawno danych testowych, zanim zabierzemy si
do poszukiwania bdu w kodzie.
Przedstawiony powyej kod nie umoliwia testowania wyjtkw. Zastanw
si, w jaki sposb zaimplementowa tak moliwo.
Wybierz taki sposb testowania, ktry pozwoli najatwiej sprawdzi, czy
metoda dziaa poprawnie.

Warunki brzegowe
W przykadzie z wyszukiwaniem najwikszego elementu listy udao nam si
zidentyfikowa szereg warunkw brzegowych: gdy najwikszy element
znajdowa si na kocu listy, gdy lista zawieraa warto ujemn, gdy lista
bya pusta i tak dalej.
Identyfikacja warunkw brzegowych jest jednym z najwartociowszych
aspektw testowania, poniewa pozwala wykry i przetestowa obszary,
w ktrych prawdopodobiestwo niepoprawnego dziaania kodu jest najwiksze. Typowe warunki brzegowe powstaj na skutek:

58

JUnit. Pragmatyczne testy jednostkowe w Javie

t

wprowadzenia cakowicie bdnych lub niespjnych danych

wejciowych, na przykad acucha "!*W:X\&Gi/w~>g/h#WQ@"
jako nazwy pliku;

nieprawidowo sformatowanych danych, takich jak adres e-mail,

ktry nie zawiera gwnej domeny ("fred@foobar.");

niewprowadzenia odpowiednich wartoci (wtedy pojawiaj si

wartoci 0, 0.0, "" lub null);

pojawienia si wartoci znacznie przekraczajcych oczekiwania

(na przykad wiek osoby rwny 10 000 lat);

pojawienia si duplikatw na listach, ktre nie powinny

ich zawiera;

wystpienia list nieuporzdkowanych zamiast uporzdkowanych

i na odwrt; sprbuj na przykad przekaza algorytmowi
sortowania list, ktra jest ju posortowana, albo nawet posortuj
j w odwrotnym porzdku;

zakcenia przewidywanego porzdku zdarze, na przykad

prby wydrukowania dokumentu przed zalogowaniem si.

Warunkw brzegowych mona poszukiwa w przedstawionych poniej

obszarach. W przypadku kadego z podanych niej warunkw naley zastanowi si, czy dotyczy on testowanej metody, a jeli tak, to co si stanie,
gdy zostanie naruszony:
t

Zgodno czy warto jest zgodna z oczekiwanym formatem?

Uporzdkowanie czy zbir wartoci jest odpowiednio

uporzdkowany?

Zakres czy warto naley do przedziau oczekiwanych

wartoci?

Odwoanie czy kod odwouje si do zewntrznych obiektw,

ktre s poza jego kontrol?

Istnienie czy warto istnieje (czyli jest rna od null, zera,

obecna w zbiorze itd.)?

Rozdzia 4. Co testowa?
t

Liczno czy wystpuje dokadnie tyle wartoci, ile jest

oczekiwanych?

Czas (absolutny i wzgldny) czy wszystkie zdarzenia

zachodz w oczekiwanej kolejnoci i we waciwym czasie?

59

Wymienione obszary warunkw brzegowych omwimy w nastpnym rozdziale.

Sprawdzanie relacji
zachodzcych w odwrotnym kierunku
Dziaanie niektrych metod mona przetestowa, uywajc logiki ich
dziaania w odwrotnym kierunku. Na przykad dziaanie metody wyznaczajcej pierwiastek kwadratowy moemy sprawdzi, podnoszc
wynik do kwadratu i porwnujc go z wartoci wejciow:
public void testSquareRootUsingInverse() {
double x = mySquareRoot(4.0);
assertEquals(4.0, x * x, 0.0001);
}

Na podobnej zasadzie, wyszukujc rekord w bazie danych, moesz

sprawdzi dziaanie metody, ktra go tam wstawia.
Jednak implementujc odwrotn logik dziaania metody, naley zachowa
szczegln ostrono, poniewa niepoprawne dziaanie metody moe nie
zosta wykryte z powodu tych samych bdw w implementacjach obu metod. Dlatego te tam, gdzie jest to tylko moliwe, najlepiej uy innego
kodu rdowego do implementacji metody dziaajcej w kierunku odwrotnym. W naszym przykadzie testu metody pierwiastkowania wykorzystalimy w tym celu zwyky operator mnoenia. W przypadku testowania metody
wstawiajcej rekord do bazy danych najlepiej uy metody wyszukiwania
dostarczonej przez producenta systemu zarzdzania baz danych.

60

JUnit. Pragmatyczne testy jednostkowe w Javie

Kontrola wynikw na wiele sposobw

Wyniki dziaania testowanych metod moemy sprawdza na wiele sposobw.
Zwykle bowiem istnieje wicej ni jeden sposb wyznaczenia interesujcej
nas wartoci. Podczas implementacji kodu produkcyjnego wybieramy ten
algorytm, ktry jest najefektywniejszy lub ma charakterystyk interesujc
pod innym wzgldem. Natomiast pozostae moemy wykorzysta w celu
sprawdzenia wynikw podczas testowania. Technika ta jest szczeglnie
pomocna, gdy istnieje oglnie znany, sprawdzony sposb uzyskania wynikw, ktry jednak jest zbyt mao efektywny lub elastyczny, by mg zosta
uyty w kodzie produkcyjnym.
Mniej efektywnego algorytmu moemy uy do sprawdzenia, czy algorytm
zastosowany w wersji produkcyjnej daje takie same wyniki2:
public void testSquareRootUsingStd() {
double number = 3880900.0;
double root1 = mySquareRoot(number);
double root2 = Math.sqrt(number);
assertEquals(root2, root1, 0.0001);
}

Inny sposb zastosowania tej techniki polega na sprawdzeniu, czy rne

dane sumuj si we waciwy sposb. Zamy na przykad, e pracujemy
nad systemem obsugi biblioteki. W takim systemie liczba egzemplarzy
danej ksiki powinna zawsze zgadza si z sum egzemplarzy znajdujcych
si na pkach biblioteki i egzemplarzy wypoyczonych. Liczba poszczeglnych egzemplarzy stanowi osobne dane, ktre mog nawet by raportowane przez obiekty rnych klas, ale musz by ze sob zgodne i wobec
tego mog by uywane podczas testowania.

Niektre arkusze kalkulacyjne (na przykad Microsoft Excel) stosuj podobn technik w celu
sprawdzenia, czy do rozwizania danego problemu uyte zostay odpowiednie modele i metody
i czy wyniki dziaania rnych metod s ze sob zgodne.

Rozdzia 4. Co testowa?

61

Wymuszanie warunkw
powstawania bdw
Gdy kod produkcyjny pracuje ju w rzeczywistym systemie, naraony jest
na sytuacje zwizane z rnego rodzaju bdami, takimi jak brak miejsca
na dysku, awarie sieci czy niepoprawna praca innych aplikacji. Aby przetestowa zachowanie kodu w takich sytuacjach, musimy umie je wywoa.
Nie jest to trudne, gdy dotyczy na przykad przekazania kodowi niepoprawnych parametrw, ale ju symulacja bdw sieci wymaga zastosowania odpowiednich technik. Jedn z nich polegajc na uyciu obiektw
imitujcych omwimy w rozdziale 6. Zanim tam dotrzesz, sprbuj zastanowi si, jakie rodzaje bdw lub ogranicze wprowadzanych przez
rodowisko wykonywania kodu naley przetestowa? Sporzd krtk ich
list, zanim przejdziesz do dalszej lektury.
Zastanw si nad tym, zanim przejdziesz do dalszej lektury...

A oto kilka typowych problemw, ktre udao nam si wymyli.

t

Brak wolnej pamici.

Brak wolnego miejsca na dysku.

Nieprawidowy czas systemu.

Brak dostpu do sieci i bdy transmisji.

Przecienie systemu.

Ograniczona paleta kolorw.

Zbyt dua lub zbyt maa rozdzielczo obrazu.

Charakterystyka efektywnociowa
Kolejnym obszarem wartym przetestowania jest charakterystyka efektywnociowa. Nie chodzi tutaj o sam efektywno dziaania kodu, lecz o sposb
jej zmiany w odpowiedzi na zwikszajc si ilo danych wejciowych,
rosncy poziom komplikacji rozwizywanego problemu i tym podobne.

62

JUnit. Pragmatyczne testy jednostkowe w Javie

W tym przypadku zaley nam przede wszystkim na przeprowadzeniu testu

regresji charakterystyki efektywnociowej. Czsto bowiem zdarza si, e
pewna wersja systemu pracuje poprawnie, ale ju nastpna okazuje si zaskakujco wolna. Zwykle nie wiemy wtedy, jaka jest tego przyczyna, kto,
kiedy i dlaczego wprowadzi modyfikacje, ktre pogorszyy efektywno
kodu. A uytkownicy zniecierpliwieni czekaj na rozwizanie problemu.
Aby unikn takiego scenariusza, moemy wykona kilka podstawowych
testw, ktre upewni nas, e krzywa efektywnoci jest stabilna w nowej
wersji kodu. Zamy na przykad, e napisalimy filtr pozwalajcy identyfikowa witryny internetowe, do ktrych dostp chcemy zablokowa.
Stworzony kod dziaa poprawnie w przypadku kilkudziesiciu witryn, ale
czy rwnie efektywnie bdzie si zachowywa w przypadku 10 000 lub
nawet 100 000 witryn? Aby si o tym przekona, musimy napisa odpowiedni test jednostkowy.
public void testURLFilter() {
Timer timer = new Timer();
String naughty_url = "http://www.xxxxxxxxxxx.com";
// Najpierw wyszukaj niedozwolony URL na maej licie
URLFilter filter = new URLFilter(small_list);
timer.start();
filter.check(naughty_url);
timer.end();
assertTrue(timer.elapsedTime() < 1.0);
// Nastpnie wyszukaj niedozwolony URL na wikszej licie
filter = new URLFilter(big_list);
timer.start();
filter.check(naughty_url);
timer.end();
assertTrue(timer.elapsedTime() < 2.0);
// Na koniec wyszukaj niedozwolony URL na licie o jak najwikszym rozmiarze
filter = new URLFilter(huge_list);
timer.start();
filter.check(naughty_url);
timer.end();
assertTrue(timer.elapsedTime() < 3.0);
}

Rozdzia 4. Co testowa?

63

Przeprowadzenie takiego testu daje nam gwarancj, e kod spenia wymagania odnonie do jego efektywnoci. Poniewa jego wykonanie zajmuje kilka
sekund, nie musimy uruchamia go za kadym razem. Wystarczy, e bdziemy go wykonywa wraz z innymi testami w nocy lub co kilka dni, a zostaniemy zaalarmowani o pojawiajcych si problemach z efektywnoci kodu
wystarczajco wczenie, aby poprawi je na czas.
Istnieje wiele dekoratorw umoliwiajcych dokadniejsze pomiary efektywnoci poszczeglnych metod, symulacj warunkw silnego obcienia i tym
podobne. Jednym z takich produktw jest dostpny bezpatnie JUnitPerf3.

http://www.clarkware.com