informatyka java praktyczne narzedzia john ferguson smart ebook

Java.
Praktyczne narzêdzia

Autor: John Ferguson Smart
T³umaczenie: Miko³aj Szczepaniak
ISBN: 978-83-246-1932-0
Tytu³ orygina³u:

Java Power Tools

Format: 168x237, stron: 888

Poznaj narzêdzia, które oka¿¹ siê niezbêdne!

• Jak zapewniæ wysok¹ jakoœæ tworzonego rozwi¹zania?
• Jak wprowadziæ proces ci¹g³ej integracji?
• Jak testowaæ kod?

Mo¿liwoœci jêzyka Java znaj¹ ju¿ chyba wszyscy. Dlatego warto jedynie wspomnieæ
o tym, ¿e oprócz podstawowych narzêdzi do tworzenia oprogramowania w tym jêzyku,
które zna ka¿dy programista, istnieje wiele innych — przydatnych i u¿ytecznych
— aplikacji. Potrafi¹ one w niezwykle skuteczny sposób przyœpieszyæ oraz u³atwiæ
programowanie w jêzyku Java i sprawiæ, ¿e bêdzie to zajêcie jeszcze przyjemniejsze.
W ¿adnej innej ksi¹¿ce nie znajdziesz tak szczegó³owego omówienia tych narzêdzi.
Zatem jeœli wykorzystujesz jêzyk Java na co dzieñ, musisz j¹ mieæ!

Dziêki tej ksi¹¿ce poznasz 33 praktyczne narzêdzia, które u³atwi¹ Twoj¹ pracê
— narzêdzia, które zwiêksz¹ niezawodnoœæ Twojego kodu, poprawi¹ wydajnoœæ
oraz zapewni¹ bezpieczeñstwo Twoim plikom Ÿród³owym. Autor ksi¹¿ki omawia kilka
grup narzêdzi, a wœród nich aplikacje takie, jak Maven, Subversion, JUnit czy te¿
Hudson. Dziêki ksi¹¿ce „Java. Praktyczne narzêdzia” dowiesz siê, jak bardzo na jakoœæ
Twojego rozwi¹zania mo¿e wp³yn¹æ proces ci¹g³ej integracji oraz jak wa¿ne s¹ testy
jednostkowe czy integracyjne. Ponadto autor ksi¹¿ki omawia 29 innych narzêdzi,
które zwiêkszaj¹ komfort pracy. Otwórz spis treœci i spójrz, jak cenne informacje s¹
zawarte w tej ksi¹¿ce!

• Wykorzystanie narzêdzi kompiluj¹cych (Ant, Maven2)
• Zastosowanie systemów kontroli wersji (CVS, Subversion)
• Sposoby oceny jakoœci kodu (CheckStyle, PMD, FindBugs, Jupiter)
• Tworzenie wysokiej jakoœci dokumentacji
• Przygotowanie testów jednostkowych (JUnit, TestNG)
• Przeprowadzanie testów integracyjnych
• Systemy raportowania i œledzenia b³êdów (Bugzilla, Trac)
• Narzêdzia pozwalaj¹ce na wprowadzenie procesu ci¹g³ej integracji
(Continuum, Hudson)
• Sposoby przeprowadzania testów obci¹¿eniowych
• Profilowanie i monitorowanie aplikacji za pomoc¹ narzêdzi dostêpnych
w pakiecie JDK oraz Eclipse

Zobacz, jak ³atwo mo¿na wykonaæ skomplikowane zadania!

Spis tre&ci

S'owo wst*pne ........................................................................................................................17

Przedmowa ............................................................................................................................. 19

Wprowadzenie .......................................................................................................................33

I Narz*dzia kompiluj7ce ...........................................................................37

1. Przygotowywanie projektu z wykorzystaniem Anta ................................................ 41

1.1. Rola narz!dzia Ant w procesie kompilacji

1.2. Instalacja Anta

1.3. P"ynne wprowadzenie w $wiat Anta

1.4. Kompilowanie kodu Javy za pomoc% Anta

1.5. Dostosowywanie skryptów kompilacji za pomoc% w"a$ciwo$ci

1.6. Przeprowadzanie testów jednostkowych za pomoc% Anta

1.7. Generowanie dokumentacji za pomoc% narz!dzia Javadoc

1.8. Pakowanie gotowej aplikacji

1.9. Wdra'anie aplikacji

1.10.Automatyczne przygotowywanie $rodowiska dla uruchamianych

skryptów kompilacji

1.11. Stosowanie zale'no$ci narz!dzia Maven w Ancie wraz z zadaniami Mavena

1.12. Stosowanie Anta w $rodowisku Eclipse

1.13. Stosowanie Anta w $rodowisku NetBeans

1.14. Modyfikowanie kodu XML-a za pomoc% zadania XMLTask

1.15. Konkluzja

2. Przygotowywanie projektu z wykorzystaniem Mavena 2 ........................................ 97

2.1. Rola narz!dzia Maven w procesie kompilacji

2.2. Maven i Ant

2.3. Instalacja Mavena

2.4. Kompilacje deklaratywne i model obiektu projektu Mavena

101

Spis tre&ci

2.5. Zrozumie* cykl 'ycia Mavena 2

112

2.6. Struktura katalogów Mavena

114

2.7. Konfigurowanie Mavena pod k%tem naszego $rodowiska

115

2.8. Zarz%dzanie zale'no$ciami w Mavenie 2

118

2.9. Poszukiwanie zale'no$ci za po$rednictwem witryny Maven Repository

126

2.10. Dziedziczenie i agregacja projektów

127

2.11. Tworzenie szablonu projektu za pomoc% tzw. archetypów

131

2.12. Kompilacja kodu

135

2.13. Testowanie kodu

136

2.14. Pakowanie i wdra'anie naszej aplikacji

138

2.15. Wdra'anie aplikacji z wykorzystaniem narz!dzia Cargo

140

2.16. Stosowanie Mavena w $rodowisku Eclipse

144

2.17. Stosowanie Mavena w $rodowisku NetBeans

147

2.18. Dostosowywanie procesu kompilacji do specyficznych potrzeb projektu

za pomoc% w"asnych modu"ów rozszerze+

147

2.19. Konfigurowanie repozytorium korporacyjnego za pomoc% narz!dzia Archiva

154

2.20. Konfigurowanie repozytorium korporacyjnego z wykorzystaniem narz!dzia

Artifactory

166

2.21. Stosowanie narz!dzia Ant w Mavenie

178

2.22. Archetypy zaawansowane

183

2.23. Stosowanie podzespo"ów

187

II Narz*dzia kontroli wersji......................................................................193

3. Kontrola wersji z wykorzystaniem systemu CVS ..................................................... 195

3.1. Wprowadzenie do systemu CVS

195

3.2. Konfigurowanie repozytorium systemu CVS

196

3.3. Tworzenie nowego projektu w systemie CVS

196

3.4. Wypo'yczanie projektu

198

3.5. Praca na plikach — aktualizowanie i zatwierdzanie plików z kodem 5ród"owym

200

3.6. Blokowanie repozytorium

204

3.7. Praca z mechanizmem zast!powania s"ów kluczowych

204

3.8. Praca z plikami binarnymi

205

3.9. Znaczniki systemu CVS

207

3.10. Tworzenie odga"!zie+ w systemie CVS

208

3.11. Scalanie zmian z odga"!zienia

210

3.12. Przegl%danie historii zmian

211

3.13. Wycofywanie zmian

213

3.14. Stosowanie CVS-a w systemie Windows

214

Spis tre&ci

4. Kontrola wersji z wykorzystaniem systemu Subversion ..........................................217

4.1. Wprowadzenie do systemu Subversion

217

4.2. Instalacja systemu Subversion

221

4.3. Typy repozytoriów systemu Subversion

221

4.4. Konfigurowanie repozytorium systemu Subversion

223

4.5. Tworzenie nowego projektu w systemie Subversion

225

4.6. Wypo'yczanie kopii roboczej

227

4.7. Importowanie istniej%cych plików do repozytorium systemu Subversion

228

4.8. Zrozumie* adresy URL repozytorium systemu Subversion

230

4.9. Praca z plikami

231

4.10. Sprawdzanie bie'%cej sytuacji — polecenie status

235

4.11. Rozwi%zywanie konfliktów

237

4.12. Stosowanie znaczników, odga"!zie+ i operacji scalania

239

4.13. Przywracanie poprzedniej rewizji

243

4.14. Blokowanie dost!pu do plików binarnych

244

4.15. Zdejmowanie i przechwytywanie blokad

246

4.16. Udost!pnianie zablokowanych plików tylko do odczytu za pomoc%

w"a$ciwo$ci svn:needs-lock

248

4.17. Stosowanie w"a$ciwo$ci

249

4.18. Historia zmian w systemie Subversion — rejestrowanie zdarze+ i okre$lanie

odpowiedzialno$ci za zmiany

252

4.19.Konfigurowanie serwera systemu Subversion z wykorzystaniem

serwera svnserve

253

4.20. Konfigurowanie bezpiecznego serwera svnserve

257

4.21. Konfigurowanie serwera Subversion z obs"ug% protoko"u WebDAV/DeltaV

258

4.22. Konfigurowanie bezpiecznego serwera WebDAV/DeltaV

263

4.23. Dostosowywanie dzia"ania systemu Subversion za pomoc% skryptów

przechwytuj%cych

264

4.24. Instalacja systemu Subversion w formie us"ugi systemu operacyjnego Windows

266

4.25. Sporz%dzanie kopii zapasowej i przywracanie repozytorium systemu Subversion 268
4.26. Stosowanie systemu Subversion w $rodowisku Eclipse

268

4.27. Stosowanie systemu Subversion w $rodowisku NetBeans

275

4.28. Stosowanie systemu Subversion w systemie operacyjnym Windows

281

4.29. >ledzenie usterek i kontrola zmian

287

4.30. Stosowanie systemu Subversion w Ancie

290

4.31. Konkluzja

292

III Ci7g'a integracja .................................................................................. 293

5. Konfigurowanie serwera ci7g'ej integracji za pomoc7 narz*dzia Continuum ...... 297

5.1. Wprowadzenie do narz!dzia Continuum

297

5.2. Instalacja serwera narz!dzia Continuum

297

Spis tre&ci

5.3. R!czne uruchamianie i zatrzymywanie serwera

301

5.4. Sprawdzanie stanu serwera

302

5.5. Uruchamianie serwera narz!dzia Continuum w trybie ze szczegó"owymi

komunikatami

302

5.6. Dodawanie grupy projektów

303

5.7. Dodawanie projektu Mavena

303

5.8. Dodawanie projektu Anta

306

5.9. Dodawanie projektu kompilowanego za pomoc% skryptu pow"oki

307

5.10. Zarz%dzanie kompilacjami projektu

307

5.11. Zarz%dzanie u'ytkownikami

309

5.12. Konfigurowanie mechanizmów powiadomie+

311

5.13. Konfigurowanie planowanych kompilacji

311

5.14. Diagnozowanie procesu kompilacji

314

5.15. Konfigurowanie serwera poczty elektronicznej narz!dzia Continuum

314

5.16. Konfigurowanie portów witryny internetowej serwera Continuum

315

5.17. Automatyczne generowanie witryny Mavena za pomoc% narz!dzia Continuum

316

5.18. Konfigurowanie zadania r!cznej kompilacji

317

5.19. Konkluzja

319

6. Konfigurowanie serwera ci7g'ej integracji za pomoc7 narz*dzia CruiseControl ......... 321

6.1. Wprowadzenie do narz!dzia CruiseControl

321

6.2. Instalacja narz!dzia CruiseControl

322

6.3. Konfigurowanie projektu Anta

323

6.4. Powiadamianie cz"onków zespo"u za pomoc% mechanizmów publikuj%cych

329

6.5. Konfigurowanie projektu Mavena 2 w narz!dziu CruiseControl

336

6.6. Panel administracyjny narz!dzia CruiseControl

338

6.7. Dodatkowe narz!dzia

339

6.8. Konkluzja

340

7. LuntBuild — serwer ci7g'ej integracji z interfejsem WWW .................................... 341

7.1. Wprowadzenie do narz!dzia LuntBuild

341

7.2. Instalowanie narz!dzia LuntBuild

341

7.3. Konfigurowanie serwera LuntBuild

343

7.4. Dodawanie projektu

345

7.5. Wykorzystywanie zmiennych projektowych do numerowania wersji

352

7.6. Diagnostyka wyników kompilacji

353

7.7. Stosowanie narz!dzia LuntBuild w $rodowisku Eclipse

355

7.8. Raportowanie w systemie LuntBuild o pokryciu testami z wykorzystaniem

narz!dzia Cobertura

359

7.9. Integrowanie narz!dzia LuntBuild z Mavenem

365

7.10. Konkluzja

370

Spis tre&ci

8. Ci7g'a integracja z wykorzystaniem narz*dzia Hudson ...........................................371

8.1. Wprowadzenie do narz!dzia Hudson

371

8.2. Instalacja narz!dzia Hudson

371

8.3. Zarz%dzanie katalogiem domowym Hudsona

372

8.4. Instalacja aktualizacji

373

8.5. Konfigurowanie Hudsona

374

8.6. Dodawanie nowego zadania kompilacji

376

8.7. Organizowanie zada+

381

8.8. Monitorowanie kompilacji

382

8.9. Przegl%danie i awansowanie wybranych kompilacji

383

8.10. Zarz%dzanie u'ytkownikami

385

8.11. Uwierzytelnianie i bezpiecze+stwo

386

8.12. Przegl%danie zmian

386

8.13. Modu"y rozszerze+ Hudsona

387

8.14. >ledzenie wyników testów

388

8.15. >ledzenie mierników kodu 5ród"owego

388

8.16. Raportowanie o pokryciu kodu

390

9. Konfigurowanie platformy natychmiastowej komunikacji

za pomoc7 serwera Openfire ....................................................................................393

9.1. Natychmiastowa komunikacja w projekcie informatycznym

393

9.2. Instalacja serwera Openfire

394

9.3. Konfigurowanie u'ytkowników i kont u'ytkowników serwera Openfire

394

9.4. Uwierzytelnianie u'ytkowników z wykorzystaniem zewn!trznej bazy danych

396

9.5. Uwierzytelnianie u'ytkowników na serwerze POP3

397

9.6. Organizowanie wirtualnych spotka+ zespo"u z wykorzystaniem czatu grupowego

398

9.7. Rozszerzanie funkcjonalno$ci serwera Openfire za pomoc% modu"ów rozszerze+

400

9.8. Stosowanie serwera Openfire z systemem Continuum

400

9.9. Stosowanie serwera Openfire z systemem CruiseControl

401

9.10. Stosowanie serwera Openfire z narz!dziem LuntBuild

402

9.11. Wysy"anie komunikatów Jabbera z poziomu aplikacji Javy

za po$rednictwem interfejsu API Smack

402

9.12. Wykrywanie obecno$ci interfejsu API Smack

405

9.13. Otrzymywanie wiadomo$ci z wykorzystaniem interfejsu API Smack

405

IV Testy jednostkowe .............................................................................. 407

10. Testowanie kodu z wykorzystaniem frameworku JUnit .........................................409

10.1. Frameworki JUnit 3.8 i JUnit 4

409

10.2. Testowanie jednostkowe z wykorzystaniem frameworku JUnit 4

410

10.3. Konfigurowanie i optymalizacja przypadków testów jednostkowych

412

Spis tre&ci

10.4. Proste testy wydajno$ci z wykorzystaniem limitów czasowych

414

10.5. Prosta weryfikacja wyst!powania wyj%tków

415

10.6. Stosowanie testów sparametryzowanych

415

10.7. Stosowanie metody assertThat() i biblioteki Hamcrest

418

10.8. Teorie we frameworku JUnit 4

421

10.9. Stosowanie frameworku JUnit 4 w projektach Mavena 2

423

10.10. Stosowanie frameworku JUnit 4 w projektach Anta

423

10.11. Selektywne wykonywanie testów frameworku JUnit 4 w Ancie

426

10.12. Testy integracyjne

428

10.13. Korzystanie z frameworku JUnit 4 w $rodowisku Eclipse

429

11. Testowanie nowej generacji z wykorzystaniem frameworku TestNG ...................433

11.1. Wprowadzenie do frameworku TestNG

433

11.2. Tworzenie prostych testów jednostkowych za pomoc% frameworku TestNG

433

11.3. Definiowanie pakietów testów frameworku TestNG

435

11.4. Modu" rozszerzenia frameworku TestNG dla $rodowiska Eclipse

437

11.5. Stosowanie frameworku TestNG w Ancie

440

11.6. Korzystanie z frameworku TestNG w Mavenie 2

443

11.7. Zarz%dzanie cyklem 'ycia testów

444

11.8. Stosowanie grup testów

449

11.9. Zarz%dzanie zale'no$ciami

451

11.10. Testowanie równoleg"e

454

11.11. Parametry testów i testowanie sterowane danymi

455

11.12. Weryfikacja wyj%tków

456

11.13. Obs"uga b"!dów cz!$ciowych

456

11.14. Ponowne wykonywanie testów zako+czonych niepowodzeniem

457

12. Maksymalizacja pokrycia testami za pomoc7 narz*dzia Cobertura .......................459

12.1. Pokrycie testami

459

12.2. Uruchamianie narz!dzia Cobertura za po$rednictwem Anta

460

12.3. Weryfikacja pokrycia kodu testami frameworku TestNG

463

12.4. Interpretacja raportu narz!dzia Cobertura

465

12.5. Wymuszanie du'ego pokrycia kodu

467

12.6. Generowanie raportów narz!dzia Cobertura w Mavenie

469

12.7. Integracja testów pokrycia kodu z procesem kompilacji Mavena

471

12.8. Badanie pokrycia kodu w $rodowisku Eclipse

473

12.9. Konkluzja

475

Spis tre&ci

V Testy integracyjne, funkcjonalne, obci7Qeniowe i wydajno&ciowe ...477

13. Testowanie aplikacji frameworku Struts

z wykorzystaniem frameworku StrutsTestCase ...................................................... 481

13.1. Wprowadzenie

481

13.2. Testowanie aplikacji frameworku Struts

482

13.3. Wprowadzenie do frameworku StrutsTestCase

483

13.4. Testy obiektów zast!pczych z wykorzystaniem frameworku StrutsTestCase

483

13.5. Testowanie mechanizmów obs"ugi b"!dów w aplikacji frameworku Struts

488

13.6. Dostosowywanie $rodowiska testowego

489

13.7. Testy wydajno$ciowe pierwszego stopnia

489

13.8. Konkluzja

490

14. Testy integracyjne baz danych z wykorzystaniem frameworku DbUnit ................ 491

14.1. Wprowadzenie

491

14.2. Przegl%d

491

14.3. Struktura frameworku DbUnit

493

14.4. Przyk"adowa aplikacja

497

14.5. Wype"nianie bazy danych

498

14.6. Weryfikacja bazy danych

506

14.7. Zast!powanie warto$ci

510

14.8. Alternatywne formaty zbiorów danych

516

14.9. Obs"uga niestandardowych testów danych

520

14.10. Pozosta"e zastosowania

524

15. Testy wydajno&ciowe z wykorzystaniem frameworku JUnitPerf ...........................533

15.1. Wprowadzenie do frameworku JUnitPerf

533

15.2. Badanie wydajno$ci za pomoc% klasy TimedTest

534

15.3. Symulowanie obci%'enia za pomoc% klasy LoadTest

536

15.4. Przeprowadzanie testów wydajno$ciowych, które nie gwarantuj%

bezpiecze+stwa przetwarzania wielow%tkowego

539

15.5. Oddzielanie testów wydajno$ciowych od testów jednostkowych w Ancie

540

15.6. Oddzielanie testów wydajno$ciowych od testów jednostkowych w Mavenie

541

16. Wykonywanie testów obci7Qeniowych i wydajno&ciowych

za pomoc7 narz*dzia JMeter .....................................................................................543

16.1. Wprowadzenie

543

16.2. Instalacja narz!dzia JMeter

544

16.3. Testowanie prostej aplikacji internetowej

544

16.4. Projektowanie struktury naszego przypadku testowego

550

16.5. Rejestrowanie i wy$wietlanie wyników testu

553

Spis tre&ci

16.6. Rejestrowanie przypadku testowego za pomoc% serwera proxy narz!dzia JMeter 556
16.7. Testowanie z wykorzystaniem zmiennych

558

16.8. Testowanie na wielu komputerach

560

17. Testowanie us'ug sieciowych za pomoc7 narz*dzia SoapUI ..................................563

17.1. Wprowadzenie

563

17.2. Wprowadzenie do narz!dzia SoapUI

563

17.3. Instalacja narz!dzia SoapUI

565

17.4. Instalacja lokalnej us"ugi sieciowej

565

17.5.Testowanie us"ug sieciowych za pomoc% narz!dzia SoapUI

567

17.6. Przeprowadzanie testów obci%'eniowych za pomoc% narz!dzia SoapUI

573

17.7. Uruchamianie narz!dzia SoapUI z poziomu wiersza polece+

576

17.8. Uruchamianie narz!dzia SoapUI za po$rednictwem Anta

578

17.9. Uruchamianie narz!dzia SoapUI za po$rednictwem Mavena

579

17.10. Testy ci%g"e

580

17.11. Konkluzja

581

18. Profilowanie i monitorowanie aplikacji Javy

za pomoc7 narz*dzi pakietu Sun JDK .......................................................................583

18.1. Narz!dzia profiluj%ce i monitoruj%ce pakietu Sun JDK

583

18.2. Nawi%zywanie po"%czenia z aplikacj% Javy i monitorowanie jej dzia"ania

za pomoc% narz!dzia JConsole

583

18.3. Monitorowanie zdalnej aplikacji na serwerze Tomcat za pomoc%

narz!dzia JConsole

587

18.4. Wykrywanie i identyfikacja wycieków pami!ci za pomoc% narz!dzi pakietu JDK

588

18.5. Diagnozowanie wycieków pami!ci z wykorzystaniem zrzutów sterty

oraz narz!dzi jmap i jhat

593

18.6. Wykrywanie zakleszcze+

595

19. Profilowanie aplikacji Javy w &rodowisku Eclipse ...................................................599

19.1. Profilowanie aplikacji z poziomu $rodowiska IDE

599

19.2. Platforma TPTP $rodowiska Eclipse

599

19.3. Instalacja platformy TPTP

601

19.4. Platformy TPTP i Java 6

601

19.5. Podstawowe techniki profilowania z wykorzystaniem platformy TPTP

602

19.6. Ocena u'ycia pami!ci na podstawie wyników podstawowej analizy pami!ci

607

19.7. Analiza czasu wykonywania

609

19.8. Wy$wietlanie statystyk pokrycia

610

19.9. Stosowanie filtrów zaw!'aj%cych uzyskiwane wyniki

611

19.10. Profilowanie aplikacji internetowej

613

19.11. Konkluzja

613

Spis tre&ci

20. Testowanie interfejsów uQytkownika ...................................................................... 615

20.1. Wprowadzenie

615

20.2. Testowanie aplikacji internetowej za pomoc% narz!dzia Selenium

615

20.3. Testowanie graficznych interfejsów Swinga za pomoc% narz!dzia FEST

642

20.4. Konkluzja

651

VI Narz*dzia pomiaru jako&ci................................................................... 653

21. Wykrywanie i wymuszanie standardów kodowania

za pomoc7 narz*dzia Checkstyle .............................................................................. 657

21.1. Wymuszanie standardów kodowania za pomoc% narz!dzia Checkstyle

657

21.2. Stosowanie narz!dzia Checkstyle w $rodowisku Eclipse

659

21.3. Modyfikowanie regu" narz!dzia Checkstyle w $rodowisku Eclipse

663

21.4. Dostosowywanie regu" narz!dzia Checkstyle z wykorzystaniem plików

konfiguracyjnych w formacie XML

665

21.5. Dostosowywanie pracy narz!dzia Checkstyle — regu"y,

bez których mo'emy sobie poradzi*, i kilka regu", z których warto korzysta*

667

21.6. Stosowanie narz!dzia Checkstyle do definiowania regu"

dla nag"ówków w kodzie 5ród"owym

671

21.7. Wstrzymywanie testów narz!dzia Checkstyle

672

21.8. Korzystanie z narz!dzia Checkstyle w Ancie

673

21.9. Korzystanie z narz!dzia Checkstyle w Mavenie

674

22. Wst*pne wykrywanie b'*dów za pomoc7 narz*dzia PMD ..................................... 677

22.1. Narz!dzie PMD i statyczna analiza kodu

677

22.2. Korzystanie z narz!dzia PMD w $rodowisku Eclipse

677

22.3.Konfiguracja regu" narz!dzia PMD w $rodowisku Eclipse

680

22.4. Wi!cej o zbiorach regu" narz!dzia PMD

681

22.5. Pisanie w"asnych zbiorów regu" narz!dzia

684

22.6. Generowanie raportu narz!dzia PMD w $rodowisku Eclipse

685

22.7. Wstrzymywanie regu" narz!dzia PMD

686

22.8. Wykrywanie praktyki „wytnij i wklej” za pomoc% narz!dzia CPD

687

22.9. Stosowanie narz!dzia PMD w Ancie

688

22.10. Stosowanie narz!dzia PMD w Mavenie

691

23. Wst*pne wykrywanie b'*dów za pomoc7 narz*dzia FindBugs ..............................693

23.1. FindBugs jako wyspecjalizowany zabójca b"!dów

693

23.2.Stosowanie narz!dzia FindBugs w $rodowisku Eclipse

695

23.3. Wybiórcze zawieszanie stosowania regu" za pomoc% filtrów narz!dzia FindBugs 697
23.4. Stosowanie adnotacji narz!dzia FindBugs

698

Spis tre&ci

23.5. Korzystanie z narz!dzia FindBugs w Ancie

700

23.6. Korzystanie z narz!dzia FindBugs w Mavenie

702

23.7. Konkluzja

704

24. Analiza wyników — pó'automatyczne przegl7dy kodu

za pomoc7 narz*dzia Jupiter .................................................................................... 705

24.1. Wprowadzenie do Jupitera — narz!dzia do przegl%dania kodu

w $rodowisku Eclipse

705

24.2. Instalacja narz!dzia Jupiter w $rodowisku Eclipse

706

24.3.Zrozumie* proces przegl%dów kodu narz!dzia Jupiter

706

24.4. Prowadzenie przegl%dów w"asnego kodu

708

24.5. Konfiguracja

709

24.6. Ustawianie domy$lnych warto$ci konfiguracyjnych

713

24.7. Przegl%dy indywidualne

714

24.8. Przegl%dy zespo"owe

716

24.9. Faza wprowadzania poprawek

719

24.10. Wewn!trzne dzia"ania Jupitera

719

24.11. Konkluzja

721

25. Koncentrujmy si* na tym, co naprawd* waQne — narz*dzie Mylyn ...................... 723

25.1. Wprowadzenie do narz!dzia Mylyn

723

25.2. Instalacja rozszerzenia Mylyn

724

25.3. >ledzenie zada+ i problemów

725

25.4. Korzystanie z repozytoriów zada+

727

25.5.Koncentrowanie si! na wybranych zadaniach z wykorzystaniem

mechanizmów zarz%dzania kontekstami

731

25.6. Korzystanie ze zbiorów zmian $rodowiska Eclipse

734

25.7. Wspó"dzielenie kontekstu z pozosta"ymi programistami

736

25.8. Konkluzja

737

26. Monitorowanie statystyk kompilacji......................................................................... 739

26.1. Wprowadzenie

739

26.2. Narz!dzie QALab

739

26.3. Mierzenie ilo$ci kodu 5ród"owego za pomoc% modu"u rozszerzenia StatSCM

747

26.4. Statystyki narz!dzia StatSVN w Ancie

748

VII Narz*dzia do zarz7dzania problemami .............................................. 751

27. Bugzilla ...................................................................................................................... 753

27.1. Wprowadzenie do narz!dzia Bugzilla

753

27.2. Instalacja narz!dzia Bugzilla

753

27.3. Konfigurowanie $rodowiska narz!dzia Bugzilla

757

Spis tre&ci

27.4. Zarz%dzanie kontami u'ytkowników

758

27.5. Ograniczanie dost!pu do bazy danych z wykorzystaniem grup u'ytkowników

760

27.6. Konfigurowanie produktu

762

27.7. >ledzenie post!pu z wykorzystaniem tzw. kamieni milowych

764

27.8. Zarz%dzanie grupami produktów z wykorzystaniem klasyfikacji

764

27.9. Przeszukiwanie b"!dów

765

27.10. Tworzenie nowego b"!du

767

27.11. Cykl 'ycia b"!du reprezentowanego w systemie Bugzilla

768

27.12. Tworzenie harmonogramu rozsy"ania powiadomie+ (poj!kiwania)

770

27.13. Dostosowywanie pól systemu Bugzilla do potrzeb konkretnego projektu

771

27.14. Konkluzja

772

28. Trac — lekkie zarz7dzanie projektami ..................................................................... 773

28.1. Wprowadzenie do narz!dzia Trac

773

28.2. Instalacja narz!dzia Trac

774

28.3. Definiowanie projektu narz!dzia Trac

776

28.4. Uruchamianie narz!dzia Trac w formie autonomicznego serwera

778

28.5 Konfiguracja polecenia tracd jako us"ugi systemu Windows

779

28.6. Instalacja narz!dzia Trac na serwerze Apache

780

28.7. Administrowanie witryn% internetow% Traca

781

28.8. Zarz%dzanie kontami u'ytkowników

783

28.9. Dostosowywanie witryny internetowej narz!dzia Trac

— korzystanie z funkcji witryn typu wiki

786

28.10. Stosowanie systemu zarz%dzania biletami Traca

790

28.11. Aktualizowanie b"!dów reprezentowanych w narz!dziu Trac na podstawie

zawarto$ci repozytorium systemu Subversion

794

28.12. Modyfikowanie pól biletów Traca

795

28.13. Konfigurowanie powiadomie+ wysy"anych poczt% elektroniczn%

797

28.14. Raportowanie z wykorzystaniem zapyta+ i raportów Traca

797

28.15. Zarz%dzanie post!pami prac za pomoc% map drogowych

i diagramów linii czasu

800

28.16. Przegl%danie repozytorium z kodem 5ród"owym

802

28.17. Stosowanie kana"ów RSS i formatu iCalendar

802

28.18. Dostosowywanie stron witryny wiki za pomoc% skryptów Pythona

805

28.19. Konkluzja

806

VIII Narz*dzia do dokumentacji technicznej ............................................ 807

29. Komunikacja w ramach zespo'u projektowego

za po&rednictwem witryny Mavena 2 ......................................................................809

29.1.Witryna internetowa Mavena 2 jako narz!dzie komunikacyjne

809

29.2. Konfigurowanie mechanizmu generowania witryny o projekcie Mavena

810

Spis tre&ci

29.3. W"%czanie do witryny Mavena raportów generowanych przez inne narz!dzia

815

29.4. Tworzenie dedykowanego projektu witryny Mavena

819

29.5. Definiowanie szkicu witryny

821

29.6. Architektura mechanizmu generuj%cego witryny Mavena

822

29.7. Stosowanie fragmentów kodu

826

29.8. Modyfikowanie wygl%du i sposobu obs"ugi witryny Mavena

827

29.9. Udost!pnianie witryny

830

30. Automatyczne generowanie dokumentacji technicznej .........................................833

30.1. Wprowadzenie

833

30.2. Wizualizacja struktury bazy danych za pomoc% narz!dzia SchemaSpy

833

30.3. Generowanie dokumentacji kodu 5ród"owego za pomoc% Doxygena

841

30.4. Umieszczanie diagramów notacji UML w dokumentacji narz!dzia Javadoc

z wykorzystaniem narz!dzia UmlGraph

850

30.5. Konkluzja

854

Bibliografia ...........................................................................................................................855

Skorowidz............................................................................................................................. 857

409

ROZDZIAX 10.

Testowanie kodu

z wykorzystaniem frameworku JUnit

10.1. Frameworki JUnit 3.8 i JUnit 4

JUnit w chwili wprowadzenia na rynek by" naprawd! rewolucyjnym oprogramowaniem
— od tego czasu powsta"o mnóstwo przydatnych rozszerze+ tego frameworku u"atwiaj%cych
nam wykonywanie testów jednostkowych w najbardziej wyspecjalizowanych obszarach.
Wiele z tych rozszerze+ do tej pory bazuje na frameworku JUnit 3.x. Kilka takich rozszerze+
omówimy w dalszej cz!$ci tej ksi%'ki. W niniejszym podrozdziale spróbujemy sobie przy-
pomnie* framework 3.8, aby lepiej rozumie* dalszy materia" po$wi!cony zmianom wprowadzo-
nym w nowszych frameworkach, jak JUnit 4 czy TestNG (patrz rozdzia" 20.).

We frameworku JUnit 3 pisane przez nas testy jednostkowe maj% posta* klas Javy okre$lanych
mianem przypadków testowych. Wszystkie przypadki testowe tego frameworku musz% rozsze-
rza* klas!

TestCase

. Testy jednostkowe implementujemy w formie metod tych klas — definiuj%c

te metody, musimy przestrzega* specjalnych konwencji nazewniczych: metody testowe musz%
zwraca*

void

, nie mog% pobiera* 'adnych parametrów, a ich nazwy musz% si! rozpoczyna*

od s"owa

test

. Tak'e nazwy klas testowych musz% by* zgodne z prost% konwencj% — nazwa

ka'dej takiej klasy musi si! ko+czy* s"owem

Test

Poni'ej przedstawiono prost% klas! testow% frameworku JUnit 3.8 testuj%c% inn% klas!, która
z kolei odpowiada za obliczanie podatku od warto$ci dodanej (ang. Value Added Tax — VAT),
nazywanego te' podatkiem od towarów i us"ug. Przyjmijmy, 'e podstawowa stawka podatku
VAT wynosi 22 procent. Nasz klasa testu jednostkowego mo'e mie* nast!puj%c% posta*:

public class PriceCalculatorTest extends TestCase {

public void testCalculateVAT() {
calculator = new PriceCalculator();
double amountWithVat = calculator.calculatePriceWithVAT(100.00);
assertEquals("Podstawowa stawka VAT wynosi 22%", 122.00, amountWithVat, 0.0);
}
}

Klasa bazowa

TestCase

oferuje mnóstwo metod z rodziny

assert

assertEquals()

assert

True()

assertNotNull()

i wiele innych. W"a$nie wymienione metody sk"adaj% si! na j%dro

testów jednostkowych, poniewa' za ich po$rednictwem wykonujemy nasze testy. Metody

assert

s"u'% do sprawdzania, czy uzyskiwane wyniki s% zgodne z warto$ciami oczekiwanymi.

410

Rozdzia' 10. Testowanie kodu z wykorzystaniem frameworku JUnit

Za po$rednictwem pierwszego parametru metody

assert

mo'emy przekaza* opcjonalny

komunikat, który w przysz"o$ci powinien nam u"atwi* identyfikacj! b"!du (szczególnie je$li
korzystamy z du'ej liczby testów jednostkowych).

Metody

setUp()

tearDown()

(zwró*my uwag! na wielkie litery!) mo'na przykry* wersjami

odpowiednio inicjalizuj%cymi i przywracaj%cymi (przed i po ka'dym te$cie) stan $rodowiska
testowego, w którym wykonujemy nasz kod. Je$li na przyk"ad korzystamy z wielu przypadków
testowych operuj%cych na obiekcie

calculator

, mo'emy zdecydowa* o jego jednorazowym

utworzeniu w kodzie metody

setUp()

public class PriceCalculatorTest extends TestCase {

PriceCalculator calculator;

protected void setUp() throws Exception {
calculator = new PriceCalculator();
}

public void testCalculateVAT() {
double amountWithVat = calculator.calculatePriceWithVAT(100.00);
assertEquals("Podstawowa stawka VAT wynosi 22%", 122.00, amountWithVat, 0.0);
}
// Pozosta$e testy obiektu calculator...
}

Mo'liwo$ci frameworku JUnit 3 oczywi$cie nie ograniczaj% si! do zaprezentowanych mecha-
nizmów, jednak uzyskana wiedza o architekturze tego frameworku powinna w zupe"no$ci
wystarczy* do zrozumienia innowacji wprowadzonych w nowszych frameworkach i rozszerze+
frameworku JUnit 3 omawianych w pozosta"ych rozdzia"ach. Framework JUnit 4 pod wieloma
wzgl!dami przewy'sza framework JUnit 3, jednak wersja 3.8 wci%' cieszy si! du'% popularno-
$ci%, a wiele atrakcyjnych modu"ów rozszerze+ nadal nie doczeka"o si! aktualizacji do wersji
4. W kolejnych podrozdzia"ach tego rozdzia"u skoncentrujemy si! wy"%cznie na frameworku
JUnit 4.

10.2. Testowanie jednostkowe

z wykorzystaniem frameworku JUnit 4

W $wiecie frameworków testów jednostkowych JUnit jest de facto standardem. Jest powszechnie
stosowany i doskonale znany niemal ka'demu programi$cie. JUnit oferuje te' wiele przydatnych
rozszerze+ stworzonych z my$l% o bardziej wyspecjalizowanych procesach testowych. Frame-
work JUnit (w oryginalnej wersji autorstwa Kenta Becka i Ericha Gammy) jest uwa'any
za rozwi%zanie, które (przynajmniej teoretycznie) spopularyzowa"o praktyki testów jednostko-
wych w$ród programistów Javy. Okazuje si! jednak, 'e wskutek spadku dynamiki zmian
wprowadzanych w podstawowym interfejsie API w ostatnich latach powsta"o i zyska"o
popularno$* kilka innych, jeszcze bardziej innowacyjnych frameworków, na przyk"ad TestNG
(patrz rozdzia" 20.).

JUnit 3 nak"ada na programistów wiele ogranicze+, które nie znajduj% 'adnego uzasadnienia
w dobie Javy 5, adnotacji i paradygmatu odwrócenia sterowania (ang. Inversion of Control — IoC).
We frameworku JUnit 3 klasy testów musz% rozszerza* klas! bazow% samego frameworku
JUnit, a testy musz% by* definiowane zgodnie ze specjalnymi konwencjami nazewnictwa
— nie mo'emy u'y* w roli klasy testu dowolnej klasy Javy. Klasy testów frameworku JUnit 3

10.2. Testowanie jednostkowe z wykorzystaniem frameworku JUnit 4

411

s% inicjalizowane za ka'dym razem, gdy wykonujemy jaki$ test, co znacznie utrudnia refaktory-
zacj! i optymalizacj! kodu testowego. JUnit 3 w 'aden sposób nie wspiera na przyk"ad testowa-
nia sterowanego danymi (czyli wykonywania testów na danych pochodz%cych z zewn%trz).
We frameworku JUnit 3 brakuje te' takich mechanizmów jak funkcje zarz%dzania zale'no$ciami
pomi!dzy testami czy grupami testów.

JUnit 4 jest niemal ca"kowicie przebudowanym interfejsem API JUnit, który ma na celu wyko-
rzystanie post!pu obserwowanego w $wiecie technologii Javy w ci%gu ostatnich kilku lat.
Framework JUnit 4 jest prostszy, "atwiejszy w u'yciu i bardziej elastyczny od swojego poprzed-
nika; oferuje te' kilka nowych funkcji! JUnit 4 wprowadza mnóstwo nowych mechanizmów,
które mog% nam znacznie u"atwi* pisanie testów jednostkowych, w tym obs"ug! adnotacji
i bardziej elastyczny model inicjalizacji klas testów. We frameworku JUnit test mo'e mie*
posta* dowolnej klasy Javy, a metody testów nie musz% by* zgodne z 'adnymi konwencjami
nazewniczymi.

Sprawd5my wi!c, jak nasze testy kalkulatora podatkowego (patrz podrozdzia" 10.1) wygl%da"yby
we frameworku JUnit 4:

import org.junit.Before;
import org.junit.Test;
import static org.junit.Assert.*;

public class PriceCalculatorTest {

@Test
public void calculateStandardVAT() {
PriceCalculator calculator = new PriceCalculator();
double vat = calculator.calculatePriceWithVAT(100.00);
assertEquals(vat, 122.00 , 0.0);
}

@Test
public void calculateReducedVAT() {
PriceCalculator calculator = new PriceCalculator();
double vat = calculator.calculatePriceWithReducedVAT(100.00);
assertEquals(vat, 105.00 , 0.0);
}

}

Warto w pierwszej kolejno$ci zwróci* uwag! na brak konieczno$ci rozszerzania konkretnej
klasy przez przypadki testowe frameworku JUnit 4 (takie wymaganie obowi%zywa"o we frame-
worku JUnit 3). Podobnie jak TestNG, framework JUnit 4 wykorzystuje adnotacje do oznaczania
metod, które powinny by* traktowane jako testy jednostkowe. Za testy jednostkowe uwa'a si!
wszystkie metody oznaczone adnotacj%

@Test

. JUnit 4 co prawda nie narzuca nam 'adnej kon-

wencji nazewniczej (metody testów nie musz% si! rozpoczyna* od s"owa

test

, jak

testThis()

czy

testThat()

), ale wymaga, by metody testów jednostkowych zwraca"y

void

i nie pobiera"y

'adnych parametrów. Teoretycznie mo'na by nawet umieszcza* testy jednostkowe w tej
samej klasie, w której znajduje si! testowany kod, jednak w praktyce lepszym rozwi%zaniem
jest definiowanie kodu testowego w odr!bnych klasach.

Klasa

org.junit.Assert

zawiera tradycyjne metody

assert

frameworku JUnit 3.x, do których

zd%'yli$my si! przyzwyczai* i które tak lubimy. We frameworku JUnit 3 metody

assert

by"y

definiowane w klasie

TestCase

, czyli klasie bazowej dla wszystkich klas testów tego frameworku

— dzi!ki temu mo'na by"o z nich korzysta* w dowolnych testach. Z zupe"nie inn% sytuacj%
mamy do czynienia w przypadku frameworku JUnit 4, gdzie klasy testów nie musz% dzie-
dziczy* po klasie

TestCase

. Nie ma jednak powodów do zmartwie+ — mo'emy dla tej klasy

412

Rozdzia' 10. Testowanie kodu z wykorzystaniem frameworku JUnit

u'y* operacji statycznego importowania, aby korzysta* z niezb!dnych klas

assert

(w tym

assertEquals

assertNotNull

itp.; patrz przyk"ady w dalszej cz!$ci tego rozdzia"u) w dok"adnie

taki sam sposób jak w testach jednostkowych frameworku JUnit 3.x.

Alternatywnym rozwi%zaniem jest stosowanie wyra'e+

assert

dost!pnych w Javie 5:

assert (vat == 100*PriceCalculator.DEFAULT_VAT_RATE);

Wyra'enie w tej formie sprawia wra'enie bardziej eleganckiego, jednak musimy pami!ta*
o pewnej pu"apce — Java ignoruje nasze wyra'enia

assert

, chyba 'e w wierszu polece+ u'yjemy

opcji

-ea

(od ang. enable assertions).

10.3. Konfigurowanie i optymalizacja przypadków

testów jednostkowych

Jak ka'dy kod 5ród"owy, testy jednostkowe wymagaj% efektywnego kodowania i — w razie
konieczno$ci — refaktoryzacji. Framework JUnit 4 oferuje kilka adnotacji, które mog% nam
to zadanie bardzo u"atwi*. Adnotacja

@Before

wskazuje metod!, która musi by* wywo"ana

przed ka'dym testem, czyli w praktyce zast!puje znan% z frameworku JUnit 3.x metod!

setup()

. Mo'emy te' u'y* adnotacji

@After

do wskazania metod przywracaj%cych stan

$rodowiska testowego po ka'dym wykonanym te$cie. W tym przypadku metoda

initialize()

b!dzie wywo"ywana przed, a metoda

tidyup()

po ka'dym te$cie jednostkowym:

import org.junit.Before;
import org.junit.Test;
import static org.junit.Assert.*;

public class PriceCalculatorTest {

private PriceCalculator calculator;

@Before
public void initialize() {
calculator = new PriceCalculator();
}

@Test
public void calculateStandardVAT() {
PriceCalculator calculator = new PriceCalculator();
double vat = calculator.calculatePriceWithVAT(100.00);
assertEquals(vat, 122.00 , 0.0);
}

@Test
public void calculateReducedVAT() {
PriceCalculator calculator = new PriceCalculator();
double vat = calculator.calculatePriceWithReducedVAT(100.00);
assertEquals(vat, 105 , 0.0);
}

@After
public void tidyup() {
calculator.close();
calculator = null;
}

}

10.3. Konfigurowanie i optymalizacja przypadków testów jednostkowych

413

Takie rozwi%zanie wci%' nie jest optymalne. JUnit oferuje kilka innych adnotacji, których
mo'na z powodzeniem u'ywa* do dodatkowego doskonalenia kodu naszych testów jednostko-
wych. W pewnych sytuacjach warto poprawi* efektywno$* testów przez skonfigurowanie
niektórych zasobów przed wykonaniem któregokolwiek z testów jednostkowych zdefinio-
wanych w danej klasie i ich zwolnienie po zako+czeniu wykonywania testów tej klasy. Cel ten
mo'na osi%gn%* odpowiednio za pomoc% adnotacji

@BeforeClass

@AfterClass

. Metody

oznaczone adnotacj%

@BeforeClass

zostan% wywo"ane tylko raz, przed wykonaniem którego-

kolwiek z testów jednostkowych definiowanych przez dan% klas!. Jak "atwo si! domy$li*,
metody oznaczone adnotacj%

@AfterClass

zostan% wywo"ane dopiero po zako+czeniu wszyst-

kich testów. W powy'szym przyk"adzie obiekt

calculator

zosta"by utworzony tylko raz (na

pocz%tku testów jednostkowych) i zniszczony dopiero po wykonaniu wszystkich testów.
Klas! t! mo'na uzupe"ni* o metod!

reset()

wywo"ywan% przed ka'dym testem jednostkowym

i odpowiedzialn% za ka'dorazowe ponowne inicjalizowanie testowanego obiektu

calculator

Mo'liwy sposób implementacji tak zoptymalizowanej klasy testów jednostkowych przedstawio-
no poni'ej:

import org.junit.Before;
import org.junit.Test;
import static org.junit.Assert.*;

public class PriceCalculatorTest {

private PriceCalculator calculator;

@BeforeClass
public void initialize() {
calculator = new PriceCalculator();
}

@Before
public void resetCalculator() {
calculator.reset();
}

@Test
public void calculateStandardVAT() {
PriceCalculator calculator = new PriceCalculator();
double vat = calculator.calculatePriceWithVAT(100.00);
assertEquals(vat, 122.00 , 0.0);
}

@Test
public void calculateReducedVAT() {
PriceCalculator calculator = new PriceCalculator();
double vat = calculator.calculatePriceWithReducedVAT(100.00);
assertEquals(vat, 105 , 0.0);
}

@AfterClass
public void tidyup() {
calculator.close();
}

}

414

Rozdzia' 10. Testowanie kodu z wykorzystaniem frameworku JUnit

10.4. Proste testy wydajno&ci

z wykorzystaniem limitów czasowych

Jednym z najprostszych sposobów przeprowadzania testów wydajno$ci jest sprawdzanie, czy
okre$lony test zawsze jest wykonywany w okre$lonych ramach czasowych. Takie rozwi%zanie
bywa szczególnie przydatne w przypadku zapyta+ wykonywanych na bazie danych z u'yciem
takich narz!dzi odwzorowa+ obiektowo-relacyjnych jak Hibernate. Nawet proste b"!dy
w plikach odwzorowa+ tego narz!dzia mog% skutkowa* znacznie wyd"u'onymi czasami
odpowiedzi (tak'e w przypadku stosunkowo prostych zapyta+). W przeciwie+stwie do trady-
cyjnego testu jednostkowego, test z okre$lonym limitem czasowym umo'liwia wykrywanie
tego rodzaju b"!dów.

Tego rodzaju testy sprawdzaj% si! tak'e w roli mechanizmów wykrywaj%cych p!tle niesko+czo-
ne, chocia' wskazanie fragmentów kodu, które mog% zawiera* tego rodzaju konstrukcje, jest
oczywi$cie nieporównanie trudniejsze.

Opisan% technik! zintegrowano bezpo$rednio z adnotacj%

@Test

, która umo'liwia ustawianie

górnego limitu czasu, w którym dany test musi si! zako+czy* — w przeciwnym razie po up"y-
ni!ciu tego czasu test ko+czy si! b"!dem. W tym celu nale'y zdefiniowa* parametr

timeout

(reprezentuj%cy limit czasowy wyra'ony w milisekundach) adnotacji

@Test

@Test(timeout=100)
public void lookupVAT() {
double vat = calculator.lookupRateForYear(2006);
assertEquals(vat, VAT_RATE_IN_2006 , 0.0);
}

Je$li u'yte zapytanie zajmuje testowanej funkcji wi!cej ni' 100 milisekund, nasz test ko+czy
si! niepowodzeniem:

Testsuite: com.wakaleo.jpt.alexandria.services.PriceCalculatorTest
Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 0.136 sec

Testcase: calculateStandardVAT took 0.009 sec
Testcase: lookupVAT took 0.128 sec
Caused an ERROR
test timed out after 100 milliseconds
java.lang.Exception: test timed out after 100 milliseconds

W przypadku niektórych metod, od których oczekujemy wysokiej wydajno$ci i których
efektywno$* ma kluczowe znaczenie dla funkcjonowania naszej aplikacji, warto dodatkowo
sprawdzi*, czy oferowana przepustowo$* spe"nia nasze oczekiwania. Oczywi$cie im mniejsza
b!dzie warto$* limitu czasowego, tym wi!ksze b!dzie ryzyko wyst%pienia sytuacji, w której
jaki$ czynnik zewn!trzny spowalniaj%cy nasze testy doprowadzi do nieuzasadnionego przekro-
czenia tego limitu. Na przyk"ad w poni'szym przypadku testowym sprawdzamy, czy $redni
czas wykonywania metody

calculateInterest()

nie przekracza milisekundy:

@Test(timeout=50)
public void perfTestCalculateInterest() {
InterestCalculator calc = new InterestCalculatorImpl();
for(int i = 0 ; i < 50; i++) {
calc.calculateInterest(principal, interestRate, startDate, periodInDays);
}
}

10.6. Stosowanie testów sparametryzowanych

415

Tego rodzaju testy gwarantuj% nam, 'e uzyskiwane wyniki b!d% zbli'one do rzeczywisto$ci
i 'e badane metody nie s% szczególnie powolne — nie powinni$my by* zbyt wymagaj%cy.

10.5. Prosta weryfikacja wyst*powania wyj7tków

W niektórych przypadkach warto sprawdza*, czy w okre$lonych okoliczno$ciach nast!puje
prawid"owe generowanie wyj%tków. We frameworku JUnit 3.x to do$* pracoch"onne zadanie
wi%'e si! z konieczno$ci% przechwytywania wyj%tku — je$li wyj%tek uda si! przechwyci*,
przyjmujemy, 'e test zako+czy" si! pomy$lnie; w przeciwnym razie test ko+czy si! niepowo-
dzeniem. We frameworku JUnit 4 mamy do dyspozycji parametr

expected

adnotacji

@Test

któremu nale'y przypisa* klas! oczekiwanego wyj%tku (w"a$nie ten wyj%tek powinien zosta*
wygenerowany zgodnie z naszym planem). W poni'szym (do$* ma"o realistycznym) przyk"adzie
oczekujemy od aplikacji wygenerowania wyj%tku

IllegalArgumentException

, je$li dany rok

jest mniejszy od przyj!tego progu. We frameworku JUnit 4 odpowiedni test jest bardzo prosty:

@Test(expected = IllegalArgumentException.class)
public void lookupIllegalVATYear() {
double vat = calculator.lookupRateForYear(1066);
}

Je$li badana metoda nie wygeneruje wyj%tku

IllegalArgumentException

, nasz test zako+czy

si! niepowodzeniem:

Testsuite: com.wakaleo.jpt.alexandria.services.PriceCalculatorTest
Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 0.114 sec

Testcase: calculateStandardVAT took 0.009 sec
Testcase: lookupVAT took 0.01 sec
Testcase: lookupIllegalVATYear took 0.003 sec
FAILED
Expected exception: java.lang.IllegalArgumentException
junit.framework.AssertionFailedError: Expected exception:
java.lang.IllegalArgumentException

10.6. Stosowanie testów sparametryzowanych

Pisanie testów jednostkowych jest do$* nu'%ce, zatem wielu programistów próbuje i$* na skróty.
Okazuje si! jednak, 'e od pewnych czynno$ci nie uciekniemy — dobre testy jednostkowe
musz% weryfikowa* dzia"anie funkcji biznesowych dla rozmaitych danych, jak przypadki
skrajne, klasy danych itp. Ten sam test mo'e si! zako+czy* pomy$lnie dla jednego zbioru danych,
by chwil! pó5niej wykaza* powa'ne b"!dy dla innego zbioru. Je$li jednak programista musi
napisa* odr!bny przypadek testowy dla ka'dej warto$ci (zgodnie z najlepszymi praktykami
testowania), najprawdopodobniej jego kod b!dzie weryfikowa" stosunkowo niewielki zbiór
warto$ci. Czy' nie by"oby wspaniale, gdyby$my mogli wielokrotnie wykonywa* ten sam test
jednostkowy z wykorzystaniem ró'nych danych?

Okazuje si!, 'e JUnit 4 oferuje dopracowany mechanizm u"atwiaj%cy nam testowanie kodu na
dowolnych zbiorach danych. Za pomoc% tego mechanizmu mo'emy zdefiniowa* kolekcj!
danych testowych i wymusi* jej automatyczne wype"nianie w ramach naszych metod testów
jednostkowych. Przeanalizujmy teraz prosty przyk"ad. Przypu$*my, 'e musimy napisa* klas!
wyznaczaj%c% wysoko$* podatku dochodowego dla okre$lonych dochodów we wskazanym
roku. Interfejs naszej klasy biznesowej mo'e mie* nast!puj%c% posta*:

416

Rozdzia' 10. Testowanie kodu z wykorzystaniem frameworku JUnit

public interface TaxCalculator {
public double calculateIncomeTax(int year, double taxableIncome);
}

Wyznaczanie podatku dochodowego z regu"y wymaga wykonywania kilku nie"atwych oblicze+.
W wi!kszo$ci krajów stosuje si! system podatków progresywnych, gdzie stawki podatkowe
rosn% wraz ze wzrostem opodatkowanych dochodów. Stawki definiuje si! dla odr!bnych
przedzia"ów dochodów. Co wi!cej, same progi podatkowe (a wi!c tak'e przedzia"y dochodów)
nierzadko s% zmieniane w kolejnych latach. W przypadku aplikacji odpowiedzialnej za tego
rodzaju obliczenia niezwykle wa'ne jest przetestowanie warto$ci z ka'dego przedzia"u, a tak'e
przypadków skrajnych. W tej sytuacji powinni$my opracowa* kolekcj! danych testowych
obejmuj%cych mo'liwie wiele dochodów, lat i oczekiwanych obci%'e+ podatkowych. Sprawd5my,
jak mo'na to zrobi*.

JUnit 4 umo'liwia nam definiowanie zbiorów danych testowych, które mo'na nast!pnie
przekazywa* do naszych testów jednostkowych. W tym przypadku musimy przetestowa*
ró'ne dochody podlegaj%ce opodatkowaniu w ró'nych przedzia"ach podatkowych. W prezento-
wanym przyk"adzie skoncentrujemy si! tylko na roku 2006, jednak w rzeczywistej aplikacji
powinni$my podda* testom wiele lat podatkowych. Nasze zbiory testowe b!d% wi!c zawiera*
po trzy warto$ci: opodatkowane dochody, rok podatkowy oraz prawid"ow% wysoko$* podatku
dochodowego.

Korzystanie z tych danych testowych wymaga skonfigurowania sparametryzowanej klasy
testowej. Mo'e to by* zwyk"a klasa testowa z konstruktorem otrzymuj%cym na wej$ciu kilka
parametrów, a konkretnie po jednym parametrze dla ka'dej warto$ci naszego zbioru danych.
Oznacza to, 'e w analizowanym przypadku wspomniany konstruktor b!dzie pobiera" trzy
parametry: opodatkowane dochody, rok podatkowy i oczekiwan% wysoko$* podatku docho-
dowego. Sparametryzowana klasa testowa z regu"y obejmuje zmienne sk"adowe reprezentu-
j%ce ka'de z tych pól. Za inicjalizacj! tych pól odpowiada konstruktor, a w"a$ciwe metody
testów jednostkowych wykorzystuj% je w czasie testowania.

JUnit tworzy odr!bny obiekt naszej klasy testów dla ka'dego wiersza danych testowych,
po czym wykonuje na tych danych testy jednostkowe (metody) tej klasy. Oznacza to, 'e je$li
nasze dane testowe obejmuj% 20 wierszy, JUnit utworzy obiekt naszej klasy 20 razy i ka'dorazo-
wo wykona testy jednostkowe na innym wierszu tego zbioru danych.

Sprawd5my teraz, jak mo'na ten mechanizm zaimplementowa*. Kompletny kod naszej klasy
testowej (dla fikcyjnych progów podatkowych) przedstawiono poni'ej:

@RunWith(Parameterized.class)
public class TaxCalculatorTest {

@Parameters
public static Collection data() {
return Arrays.asList(new Object[][]{
/* Dochód Rok Podatek */
{ 0.00, 2006, 0.00},
{ 10000.00, 2006, 1950.00},
{ 20000.00, 2006, 3900.00},
{ 38000.00, 2006, 7410.00},
{ 38001.00, 2006, 7410.33},
{ 40000.00, 2006, 8070.00},
{ 60000.00, 2006, 14670.00},
{100000.00, 2006, 30270.00},
});
}

10.6. Stosowanie testów sparametryzowanych

417

private double revenue;
private int year;
private double expectedTax;

public TaxCalculatorTest(double input, int year, double expectedTax) {
this.revenue = revenue;
this.year = year;
this.expectedTax = expectedTax;
}

@Test public void calculateTax() {
TaxCalculator calculator = getTaxCalculator();
double calculatedTax = calculator.calculateIncomeTax(year, revenue);
assertEquals(expectedTax, calculatedTax);
}

private TaxCalculator getTaxCalculator() {
TaxCalculator calculator = new TaxCalculatorImpl();
return calculator;
}
}

Przeanalizujmy teraz poszczególne fragmenty tej klasy. Po pierwsze, musimy u'y* adnotacji

@RunWith

wskazuj%cej na klas!

Parameterized

, aby zasygnalizowa* frameworkowi JUnit,

'e nasza klasa testowa zawiera sparametryzowane przypadki testowe:

@RunWith(Parameterized.class)
public class TaxCalculatorTest {...

Musimy teraz sporz%dzi* kolekcj! naszych danych testowych. W tym celu definiujemy funkcj!
oznaczon% adnotacj%

@Parameters

i zwracaj%c% dane testowe w formie kolekcji. Dane testowe

wewn!trznie cz!sto maj% posta* listy tablic. W naszym przypadku dane testowe przyjmuj%
form! listy tablic warto$ci, gdzie ka'da tablica obejmuje trzy elementy: dochód, rok i oczekiwan%
wysoko$* podatku dochodowego (od danego dochodu osi%gni!tego we wskazanym roku
podatkowym):

Jak ju' wspomniano, kiedy framework JUnit 4 wykonuje nasz% klas! testow%, w rzeczywisto$ci
tworzy po jednym obiekcie tej klasy dla ka'dego wiersza kolekcji danych testowych. W tej
sytuacji musimy zdefiniowa* zmienne sk"adowe reprezentuj%ce te warto$ci, a tak'e konstruk-
tor publiczny odpowiedzialny za ich inicjalizacj!, aby framework JUnit móg" tworzy* kolejne
obiekty z w"a$ciwymi danymi testowymi:

private double revenue;
private int year;
private double expectedTax;

418

Rozdzia' 10. Testowanie kodu z wykorzystaniem frameworku JUnit

public TaxCalculatorTest(double revenue, int year, double expectedTax) {
this.revenue = revenue;
this.year = year;
this.expectedTax = expectedTax;
}

Mo'emy teraz przetestowa* nasz kod z wykorzystaniem tych warto$ci:

@Test
public void calculateTax() {
TaxCalculator calculator = getTaxCalculator();
double calculatedTax = calculator.calculateIncomeTax(year, revenue);
assertEquals(expectedTax, calculatedTax);
}

Kiedy uruchomimy te testy jednostkowe, oka'e si!, 'e nasze testy zostan% wykonane wielokrot-
nie — osobno dla ka'dego wiersza u'ytych danych testowych:

Testsuite: com.wakaleo.jpt.alexandria.services.TaxCalculatorTest
Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.119 sec

Testcase: calculateTax[0] took 0.012 sec
Testcase: calculateTax[1] took 0.001 sec
Testcase: calculateTax[2] took 0.002 sec
Testcase: calculateTax[3] took 0.001 sec
Testcase: calculateTax[4] took 0.001 sec
Testcase: calculateTax[5] took 0.001 sec
Testcase: calculateTax[6] took 0.002 sec
Testcase: calculateTax[7] took 0.003 sec

Warto pami!ta* o mo'liwo$ci umieszczania wielu testów jednostkowych w jednej sparame-
tryzowanej klasie testów (podobnie jak w przypadku tradycyjnych klas testów jednostkowych).
Ka'da metoda testu jednostkowego b!dzie wywo"ywana osobno dla ka'dego wiersza danych
testowych.

10.7. Stosowanie metody assertThat()

i biblioteki Hamcrest

We frameworku JUnit 4.4 wprowadzono nowe poj!cie dla wyra'e+ asercji, aby intencje
programistów by"y bardziej zrozumia"e i "atwiejsze w interpretacji. Opisywana koncepcja,
której oryginalnym pomys"odawc% by" Joe Walnes

, sprowadza si! do stosowania metody

assertThat

"%cznie ze zbiorem wyra'e+ dopasowuj%cych (okre$lanych te' mianem ogranicze+

lub predykatów), co w wielu przypadkach znacznie poprawia czytelno$* testów. Na przyk"ad
poni'sza klasa sprawdza, czy w danej sytuacji testowana funkcja wyznacza zerowy podatek
dochodowy:

import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;

public class TaxCalculatorTest {

@Test
public void calculateTax() {
TaxCalculator calculator = getTaxCalculator();

Patrz http://joe.truemesh.com/blog/000511.html.

10.7. Stosowanie metody assertThat() i biblioteki Hamcrest

419

double calculatedTax = calculator.calculateIncomeTax(2007, 0);
assertThat(calculatedTax, is(0.0));
}
}

Wywo"anie

assertThat(calculatedTax, is(0.0))

jest du'o bardziej czytelne ni' wywo"anie

assertEquals(calculatedTax, 0.0, 0.0)

, cho* oczywi$cie wszystko zale'y od osobistych

preferencji programisty. Sam uwa'am wywo"anie w tej formie za bardziej naturalne. Jest krótsze
i nie zmusza nas do pod$wiadomego t"umaczenia samego wyra'enia

assertsEquals

na zdanie

„no dobrze, zatem wyznaczany podatek musi by* równy zero”. W przypadku pierwszego
wyra'enia nasz mózg od razu dochodzi do interpretacji: „$wietnie, zak"adamy, 'e podatek
b!dzie zerowy”, co zajmuje nieporównanie mniej czasu.

Bardziej czytelne testy oznaczaj% te' wi!ksz% niezawodno$* i "atwo$* w utrzymaniu. Je$li
interpretacja naszych testów jest prostsza, du'o "atwiej i szybciej mo'emy stwierdzi*, czy
s% prawid"owe.

Wyra'enie dopasowuj%ce

equalTo

(lub

, czyli jego skrócona forma) mo'e by* z powodzeniem

wykorzystywane w roli bardziej czytelnej wersji metody

assertEquals

String result = "czerwony";

assertThat(result, equalTo("czerwony"));

Opisywane wyra'enia mo'na te' "%czy* w bardziej z"o'one zadania. Mo'emy na przyk"ad
wykorzysta* wyra'enie dopasowuj%ce

anyOf

do sprawdzenia, czy zmienna

color

zawiera

"a+cuch

"czerwony"

"zielony"

lub

"niebieski"

assertThat(color, anyOf(is("czerwony"),is("zielony"),is("niebieski")));

W razie konieczno$ci mo'emy skojarzy* z naszym testem opis, który dodatkowo u"atwi jego
interpretacj!:

String color = "hebanowy";
assertThat("czarny to czarny", color, is("czarny"));

Powy'sze wyra'enie spowoduje wygenerowanie komunikatu o b"!dzie uzupe"nionego o nasz
opis:

<<< FAILURE!
java.lang.AssertionError: czarny to czarny
Expected: "czarny"
got: "hebanowy"
...

Mo'emy te' u'y* intuicyjnego wyra'enia dopasowuj%cego

not

, które neguje wszystkie pozosta"e

wyra'enia dopasowuj%ce:

String color = "czarny";
assertThat(color, is(not(("biaKy"))));

Te nowe metody w rzeczywisto$ci pochodz% z zewn!trznej biblioteki nazwanej Hamcrest.
Wachlarz wyra'e+ dopasowuj%cych oferowanych w ramach frameworku JUnit 4.4 jest do$*
ograniczony. Mo'na jednak ten zbiór uzupe"ni*, do"%czaj%c do realizowanego projektu bibliotek!
hamcrest-all.jar

. Wspomniany interfejs API mo'na pobra* z witryny internetowej biblioteki

Hamcrest

. Je$li korzystamy z Mavena, mo'emy po prostu doda* odpowiedni% referencj!

do pliku POM:

Patrz http://code.google.com/p/hamcrest/downloads/list.

420

Rozdzia' 10. Testowanie kodu z wykorzystaniem frameworku JUnit

<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-all</artifactId>
<version>1.1</version>
<scope>test</scope>
</dependency>

W ten sposób zast!pujemy statyczne wyra'enie importuj%ce bibliotek!

org.hamcrest.Core

Matchers

wyra'eniem importuj%cym bardziej rozbudowan% bibliotek!

org.hamcrest.

Matchers

. Prezentowane rozwi%zanie daje nam dost!p do znacznie bogatszego zbioru

wyra'e+ dopasowuj%cych. Niektóre z tych dodatkowych wyra'e+ zostan% omówione w dal-
szej cz!$ci tego podrozdzia"u.

Do najbardziej interesuj%cych wyra'e+ dopasowuj%cych nale'% mechanizmy upraszczaj%ce
operacje na kolekcjach. Na przyk"ad wyra'enie

hasItem

mo'na z powodzeniem wykorzystywa*

do przeszukiwania zawarto$ci struktury typu

List

(w przypadku struktur tablicowych ten sam

efekt mo'na uzyska*, stosuj%c wyra'enie

hasItemInArray

List<String> colors = new ArrayList<String>();
colors.add("czerwony");
colors.add("zielony");
colors.add("niebieski");
...
assertThat(colors, hasItem("czerwony"));

Wyra'e+ dopasowuj%cych

hasItem

hasItemInArray

mo'na u'ywa* do konstruowania

skomplikowanych testów operuj%cych na listach warto$ci. Poni'ej przedstawiono przyk"ad
sprawdzania, czy dana lista nie zawiera 'adnych elementów:

List<Integer> ages = new ArrayList<Integer>();
ages.add(20);
ages.add(30);
ages.add(40);
...
assertThat(ages, not(hasItem(lessThan(18))));

I odwrotnie, wyra'enie dopasowuj%ce

isIn

umo'liwia nam sprawdzanie, czy interesuj%ca nas

lista zawiera konkretny obiekt:

assertThat(20, isIn(ages));

Obs"uga kolekcji nie ogranicza si! tylko do list. Wyra'e+ dopasowuj%cych

hasKey

hasValue

mo'na u'ywa* do sprawdzania, czy dana mapa (struktura typu

Map

) zawiera odpowiednio

interesuj%cy nas klucz lub warto$*:

Map map = new HashMap();
map.put("color", "czerwony");
...
assertThat(map, hasValue("czerwony"));

Istnieje nawet wyra'enie dopasowuj%ce

hasProperty

, które umo'liwia nam testowanie w"a-

$ciwo$ci obiektów:

Client client = new Client();
client.setClientName("Janina");
...
assertThat(client, hasProperty("clientName", is("Janina")));

W tym podrozdziale dokonali$my przegl%du zaledwie kilku mo'liwych zastosowa+ tego rodzaju
wyra'e+. Inne dost!pne rozwi%zania mo'na znale5* w dokumentacji najnowszej wersji tego
API. Wyra'enia dopasowuj%ce w tej formie umo'liwiaj% nam tworzenie bardziej czytelnych

10.8. Teorie we frameworku JUnit 4

421

i "atwiejszych w utrzymaniu testów, co z kolei stwarza szans! lepszego, szybszego i prostszego
kodowania naszych testów.

10.8. Teorie we frameworku JUnit 4

Inn% now% i niezwykle przydatn% (cho* wci%' uwa'an% za element eksperymentalny) funkcj%
wprowadzon% we frameworku 4.4 jest poj!cie teorii (przypuszczenia). Teoria wyra'a ogólne
przekonanie, które pozostaje prawdziwe dla wielu (by* mo'e niesko+czenie wielu) zbiorów
danych. Wszelkie ograniczenia zbiorów danych, dla których stosuje si! dan% teori!, okre$la
si! mianem za"o'e+.

Programista w pierwszej kolejno$ci definiuje zbiór punktów danych na potrzeby testów swojej
teorii. Punkt danych jest (z regu"y sta"ym) elementem danych testowych identyfikowanym
przez adnotacj!

@DataPoint

. Alternatywnym rozwi%zaniem jest u'ycie zautomatyzowanych

narz!dzi analizuj%cych nasz kod i automatycznie tworz%cych zbiory danych wzmacniaj%cych
lub obalaj%cych teori!. Na przyk"ad poni'ej definiujemy prawid"owe warto$ci dla lat 2007
i 2008:

@DataPoint public static int YEAR_2007 = 2007;
@DataPoint public static int YEAR_2008 = 2008;

Mo'emy teraz u'y* innego zbioru danych do zdefiniowania danych testowych wykorzysty-
wanych w roli potencjalnych dochodów podatników:

@DataPoint public static double INCOME_1 = 0.0;
@DataPoint public static double INCOME_2 = 0.01;
@DataPoint public static double INCOME_3 = 100.0;
@DataPoint public static double INCOME_4 = 13999.99;
@DataPoint public static double INCOME_5 = 14000.0;

Aby zdefiniowa* test wykorzystuj%cy teori!, nale'y w miejsce standardowej adnotacji

@Test

u'y* adnotacji

@Theory

. Teoria jest zwyk"% metod% otrzymuj%c% na wej$ciu pewn% liczb!

parametrów. Framework sam okre$la, których punktów danych nale'y u'y* dla poszczególnych
parametrów naszych metod testowych, na podstawie ich typów. Ka'dy punkt danych jest
przekazywany za po$rednictwem ka'dego parametru tego samego typu. Takie rozwi%zanie
stwarza pewne problemy, je$li stosujemy wiele parametrów tego samego typu. Jak si! za chwil!
przekonamy, do ograniczania mo'liwych warto$ci przypisywanych poszczególnym parametrom
s"u'% tzw. za"o'enia.

Kolejnym krokiem jest zdefiniowanie wspomnianych za"o'e+ za pomoc% adnotacji

@assumeThat

Stosuj%c za"o'enia w ramach przypadku testowego wykorzystuj%cego teori!, mo'emy "atwo
ograniczy* dane testowe, które b!d% u'ywane podczas wykonywania tego przypadku testowego.
W poni'szym przyk"adzie ograniczamy zakres testów naszego przypadku do roku 2007
i dochodów z przedzia"u od 0 do 14 tys. z"otych:

assumeThat(year, is(2007));

oraz

assumeThat(income, both(greaterThan(0.00)).and(lessThan(14000.00)));

Modu" rozszerzenia JUnitRunner wykonuje dany test dla wszystkich mo'liwych kombinacji
punktów danych zgodnych z za"o'eniami, czyli w tym przypadku dla kombinacji sta"ej

YEAR_2007

i sta"ych

INCOME_2

INCOME_3

oraz

INCOME_4

422

Rozdzia' 10. Testowanie kodu z wykorzystaniem frameworku JUnit

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.*;
import static org.junit.Assume.assumeThat;

import java.math.BigDecimal;

import org.junit.experimental.theories.DataPoint;
import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.runner.RunWith;

@RunWith(Theories.class)
public class TaxCalculatorTheoryTest {

@DataPoint public static int YEAR_2007 = 2007;
@DataPoint public static int YEAR_2008 = 2008;
@DataPoint public static BigDecimal INCOME_1 = new BigDecimal(0.0);
@DataPoint public static double INCOME_2 = 0.01;
@DataPoint public static double INCOME_3 = 100.0;
@DataPoint public static double INCOME_4 = 13999.99;
@DataPoint public static double INCOME_5 = 14000.0;

@SuppressWarnings("unchecked")
@Theory
public void lowTaxRateIsNineteenPercent(int year, double income) {
assumeThat(year, is(2007));
assumeThat(income, allOf(greaterThan(0.00),lessThan(14000.00)));

TaxCalculator calculator = getTaxCalculator();
double calculatedTax = calculator.calculateIncomeTax(year, income);
double expectedIncome = calculatedTax * 1000/195;
assertThat(expectedIncome, closeTo(income,0.001));
System.out.println("Rok: " + year + ", Dochód: " + income + ", Podatek: "
+ calculatedTax);
}

private TaxCalculator getTaxCalculator() {
return new TaxCalculatorImpl();
}
}

W wyniku wykonania tego kodu otrzymamy nast!puj%ce dane:

Rok: 2007, Dochód: 0.01, Podatek: 0.0019500000000000001
Rok: 2007, Dochód: 100.0, Podatek: 19.5
Rok: 2007, Dochód: 13999.99, Podatek: 2729.99805

Dla uproszczenia wykorzystujemy warto$ci typu

double

. W prawdziwej aplikacji biznesowej

prawdopodobnie nale'a"oby u'y* typu gwarantuj%cego wi!ksz% precyzj! operacji na danych
pieni!'nych, czyli typu

BigDecimal

lub dedykowanej klasy

Money

W razie niepowodzenia tego testu zostanie wy$wietlony opisowy komunikat obejmuj%cy
szczegó"y punktów danych, które doprowadzi"y do b"!du:

org.junit.experimental.theories.internal.ParameterizedAssertionError:
lowTaxRateIsNineteenPercent(2007, 0.01)
Caused by: java.lang.AssertionError:
Expected: is <0.01>
Got: is <0.0>

Mo'emy teraz doda* do tego testu inne teorie, aby zweryfikowa* inne podzbiory naszych
danych testowych. Mo'liwy zbiór punktów danych (po zastosowaniu za"o'e+) jest stosowany
osobno dla ka'dej takiej teorii.

10.10. Stosowanie frameworku JUnit 4 w projektach Anta

423

10.9. Stosowanie frameworku JUnit 4

w projektach Mavena 2

Maven 2 do wykonywania testów jednostkowych wykorzystuje modu" rozszerzenia Surefire
(patrz podrozdzia" 2.13). Modu" rozszerzenia obs"uguje testy jednostkowe zarówno frameworku
JUnit 3, jak i frameworku JUnit 4 — klasy testów musz% si! znajdowa* w katalogu test, a Maven
automatycznie je wykrywa i uruchamia. Mo'na nawet "%czy* testy frameworków JUnit 3
i JUnit 4 w ramach tej samej aplikacji. Testy jednostkowe wykonujemy dok"adnie tak samo jak
pozosta"e testy Mavena, czyli za pomoc% polecenia

mvn test

$ mvn test
[INFO] Scanning for projects...
...
-------------------------------------------------------
T E S T S
-------------------------------------------------------
...
Results :

Tests run: 68, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 seconds
[INFO] Finished at: Tue Aug 14 22:28:51 GMT+12:00 2007
[INFO] Final Memory: 7M/67M
[INFO] ------------------------------------------------------------------------

Polecenie

mvn test

wykonuje zarówno testy frameworku JUnit 3, jak i frameworku JUnit 4,

po czym generuje standardowy zbiór raportów modu"u rozszerzenia Surefire, obejmuj%cy
zebrane wyniki wszystkich naszych testów. Takie rozwi%zanie jest bardzo korzystne w sytuacji,
gdy chcemy korzysta* z unikatowych funkcji frameworku JUnit 4 w normalnych testach jednost-
kowych i jednocze$nie zachowa* mo'liwo$* stosowania kilku doskona"ych bibliotek testuj%cych
napisanych dla frameworku JUnit 3, na przyk"ad ze StrutsTestCase’a (patrz rozdzia" 19.),
frameworku testowego Spring MVC lub rozszerzenia DBUnit.

10.10. Stosowanie frameworku JUnit 4

w projektach Anta

Obs"uga frameworku JUnit 4 w wersjach Anta sprzed wydania 1.7.0 pozostawia"a wiele
do 'yczenia. Okazuje si! jednak, 'e pocz%wszy od wspomnianej wersji, testy frameworku JUnit 4
s% w pe"ni obs"ugiwane i "atwe w konfiguracji. W tym podrozdziale przeanalizujemy kroki
sk"adaj%ce si! na procesy konfiguracji, kompilacji i wykonywania testów JUnit 4 za po$red-
nictwem Anta.

Aby nasze rozwa'ania by"y kompletne, przeanalizujemy ca"y skrypt kompilacji Anta. Wi!ksza
cz!$* tego pliku powinna by* zrozumia"a dla programistów obeznanych z Antem (patrz
rozdzia" 1.). W pierwszej cz!$ci tego pliku definiujemy katalogi projektu i typowe zadania:

424

Rozdzia' 10. Testowanie kodu z wykorzystaniem frameworku JUnit

Nast!pnie musimy zdefiniowa* zadanie odpowiedzialne za kompilacj! naszego kodu Javy:

Tak'e w tym przypadku mamy do czynienia ze standardowymi konstrukcjami skryptu kom-
pilacji — ograniczamy si! do kompilowania kodu Javy za pomoc% standardowego zadania

<javac>

. Bardziej interesuj%ce elementy mo'na znale5* w kolejnym fragmencie tego pliku, gdzie

ustawiamy $cie'k! do klas wskazuj%c% na plik JAR frameworku JUnit 4.1 i skompilowane
klasy naszej aplikacji. Obie $cie'ki wykorzystujemy nast!pnie do skompilowania testów jed-
nostkowych frameworku JUnit 4. Poniewa' framework JUnit 4 zapewnia zgodno$* wstecz
z frameworkiem JUnit 3, testy jednostkowe napisane w obu tych interfejsach API mo'na z powo-
dzeniem stosowa* "%cznie (bez ryzyka wyst!powania konfliktów) w ramach tego samego
projektu:

Jeste$my wreszcie gotowi do w"a$ciwego uruchomienia naszych testów jednostkowych. Ant
1.7.0 oferuje nowe, udoskonalone zadanie stworzone z my$l% o obs"udze zarówno testów
frameworku JUnit 3, jak i testów frameworku JUnit 4. Typowe zadanie testu frameworku
JUnit u'yte w skrypcie kompilacji Anta 1.7.0 ma nast!puj%c% posta*:

10.10. Stosowanie frameworku JUnit 4 w projektach Anta

425

Pierwszym interesuj%cym elementem (przynajmniej z perspektywy u'ytkowników frameworku
JUnit korzystaj%cych ze starszych wersji Anta) jest $cie'ka do klas. W"a$nie za po$rednictwem
tego elementu sygnalizujemy Antowi, gdzie nale'y szuka* pliku JAR frameworku JUnit 4.
Warto o tym wspomnie* cho*by dlatego, 'e a' do wydania Anta 1.6.5 u'ytkownicy zaintere-
sowani korzystaniem z zadania frameworku JUnit musieli umieszcza* kopi! pliku junit.jar
w katalogu lib Anta. Mimo 'e przytoczone wymaganie by"o udokumentowane w podr!czniku
u'ytkownika Anta i oficjalnie zadeklarowane jako zgodne z zamierzeniami twórców tego
narz!dzia, w najlepszym razie mo'na je uzna* za niefortunne. Pocz%wszy od Anta 1.7.0,
wystarczy zadeklarowa* plik JAR frameworku JUnit 4 w zagnie'd'onym elemencie

<class

path>

W kolejnej cz!$ci nale'y zdefiniowa* list! obiektów formatuj%cych. Wyniki testów mo'na
generowa* w wielu ró'nych formatach — opcja

plain

oznacza zwyk"e pliki testowe, natomiast

opcja

xml

oznacza bardziej szczegó"owe raporty w popularnym formacie XML.

Za w"a$ciwe wykonywanie testów odpowiada element

, który uruchamia wszystkie

testy frameworku JUnit odnalezione we wskazanym zbiorze plików. W tym kontek$cie testy
jednostkowe frameworku JUnit 3 s% traktowane tak samo jak testy frameworku JUnit 4.

Po wywo"aniu tego celu powinni$my otrzyma* dane wynikowe podobne do poni'szych:

$ ant runtests
Buildfile: build.xml

init:

compile:
[javac] Compiling 11 source files to
/home/john/Documents/book/java-power-tools/src/sample-
code/alexandria/target/classes

compiletests:
[javac] Compiling 4 source files to
/home/john/Documents/book/java-power-tools/src/sample-code/alexandria/target/
test-classes

runtests:
[junit] Running com.wakaleo.jpt.alexandria.domain.CatalogTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 4.493 sec
[junit] Running com.wakaleo.jpt.alexandria.domain.LegacyJUnit3CatalogTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.041 sec
[junit] Running com.wakaleo.jpt.alexandria.services.PriceCalculatorTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.048 sec
[junit] Running com.wakaleo.jpt.alexandria.services.TaxCalculatorTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.054 sec

BUILD SUCCESSFUL

426

Rozdzia' 10. Testowanie kodu z wykorzystaniem frameworku JUnit

10.11. Selektywne wykonywanie testów

frameworku JUnit 4 w Ancie

Zadanie

<junit>

Anta jest narz!dziem wyj%tkowo elastycznym — za jego po$rednictwem

mo'emy mi!dzy innymi wskazywa* testy jednostkowe, które maj% by* wykonywane. W tym
podrozdziale zostan% omówione rozmaite techniki wyboru takich testów.

Wykonywanie pojedynczych testów

Testy jednostkowe najcz!$ciej wykonuje si! ca"ymi pakietami za pomoc% elementu

Okazuje si! jednak, 'e mo'na te testy wykonywa* tak'e pojedynczo z u'yciem elementu

<test>

Wywo"anie tego celu spowoduje wykonanie tylko testów jednostkowych zawartych we
wskazanej klasie:

$ ant runtest
Buildfile: build.xml

init:

compile:

compiletests:

runtest:
[junit] Running com.wakaleo.jpt.alexandria.domain.CatalogTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 9.02 sec

BUILD SUCCESSFUL

Mo'emy te' zdecydowa* o wy"%czeniu jakiego$ testu ze zbioru g"ównych testów jednostkowych
za pomoc% elementu

Warunkowe wykonywanie testów

W pewnych sytuacjach warto zrezygnowa* z wykonywania wszystkich klas testów przy okazji
ka'dej procedury przeprowadzania testów jednostkowych. Niektóre rodzaje testów — w tym
testy obci%'eniowe, integracyjne i wydajno$ciowe — mog% by* do$* czasoch"onne, zatem ich

10.11. Selektywne wykonywanie testów frameworku JUnit 4 w Ancie

427

wykonywanie po ka'dej kompilacji aplikacji bywa k"opotliwe. Testy jednostkowe powinny
by* krótkie i tre$ciwe. Testy wymagaj%ce wi!cej czasu i mocy obliczeniowej procesora nale'y
stosowa* tylko wtedy, gdy jest to naprawd! konieczne. Na komputerze programistów tego
rodzaju testy s% wykonywane tylko na '%danie; za ich systematyczne przeprowadzanie z regu"y
odpowiada serwer integracji.

Jednym ze sposobów realizacji tego celu jest u'ycie atrybutu

elementu

. Atrybut

okre$la w"a$ciwo$*, której ustawienie jest warunkiem wykonania wskazanych testów

jednostkowych; w przeciwnym przypadku testy zostan% po prostu pomini!te.

Poni'szy cel zostanie przetworzony, pod warunkiem 'e b!dzie ustawiona w"a$ciwo$*

perf

tests

Je$li w"a$ciwo$*

perftests

nie zostanie ustawiona, testy wydajno$ciowe nigdy nie zostan%

wykonane, nawet je$li nasz cel zostanie wywo"any wprost (wed"ug nazwy):

$ ant runperftests
Buildfile: build.xml

init:

compile:

compiletests:

runperftests:

BUILD SUCCESSFUL
Total time: 1 second

Je$li jednak ustawimy w"a$ciwo$*

perftests

(przypisuj%c jej dowoln% warto$*), testy wydaj-

no$ciowe zostan% prawid"owo wykonane. W"a$ciwo$ci mo'na ustawia* na wiele ró'nych
sposobów: bezpo$rednio w pliku kompilacji, w pliku w"a$ciwo$ci "adowanym przez skrypt
kompilacji (za pomoc% zadania

) lub z poziomu wiersza polece+:

$ ant runperftests -Dperftests=true
Buildfile: build.xml

init:

compile:

compiletests:

runperftests:
[junit] Running com.wakaleo.jpt.alexandria.domain.CatalogPerfTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 7.227 sec
[junit] Running com.wakaleo.jpt.alexandria.services.PriceCalculatorPerfTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.192 sec

BUILD SUCCESSFUL

428

Rozdzia' 10. Testowanie kodu z wykorzystaniem frameworku JUnit

Typowym zastosowaniem w"a$ciwo$ci w tej formie (ustawianej z poziomu wiersza polece+)
jest stosowanie naszego zadania na serwerze integracyjnym — testy wydajno$ciowe i integracyj-
ne z regu"y wykonywane s% tylko na tym serwerze, nie na komputerach programistów.

Stosuj%c t! technik!, nie mo'emy zapomina* o konieczno$ci wy"%czenia tych testów z g"ównego
testu jednostkowego za pomoc% omówionego wcze$niej elementu

10.12. Testy integracyjne

Testy jednostkowe nie tylko powinny by* krótkie i tre$ciwe, ale te' powinny generowa* intere-
suj%ce nas wyniki mo'liwie szybko. Testy jednostkowe nie powinny korzysta* z takich zasobów
zewn!trznych jak bazy danych czy frameworki aplikacji internetowych. W"a$nie dlatego cz!sto
stosuje si! interfejsy, obiekty zast!pcze i rozmaite inne techniki gwarantuj%ce, 'e ka'dy kom-
ponent b!dzie testowany niezale'nie od pozosta"ych.

Pr!dzej czy pó5niej b!dziemy jednak chcieli sprawdzi*, jak nasze komponenty ze sob% wspó"pra-
cuj%. Weryfikacj! tego aspektu projektu okre$la si! mianem testów integracyjnych. Na tym
etapie mo'emy sprawdzi* obiekty DAO frameworku Hibernate, korzystaj%c z prawdziwej
bazy danych (zamiast z bazy wbudowanej), wykona* zapytania pokonuj%ce ca"% drog!
od warstwy us"ug do bazy danych i z powrotem lub zasymulowa* dzia"anie przegl%darki
u'ytkownika z u'yciem specjalnego narz!dzia, na przyk"ad Selenium. Mo'na te' sprawdzi*,
jak nasza aplikacja radzi sobie z du'ym obci%'eniem i czy jest w"a$ciwie przygotowana
do obs"ugi wielu jednoczesnych '%da+. Tego rodzaju testy s% oczywi$cie bardzo wa'ne, jednak
z regu"y okazuj% si! zdecydowanie zbyt czasoch"onne, aby programi$ci mogli je ka'dorazowo
wykonywa* wraz ze zwyk"ymi testami jednostkowymi. Zbyt wolne testy jednostkowe zniech!-
caj% programistów do testowania, zatem powinni$my znale5* skuteczny sposób wyodr!bnienia
szybkich testów jednostkowych z grupy wolnych testów integracyjnych.

W Mavenie mo'na tak skonfigurowa* modu" rozszerzenia Surefire, aby sam okre$la", które
testy nale'y wykonywa* w fazie testów jednostkowych (w odpowiedzi na polecenie

mvn test

aktóre powinny by* wykonywane na etapie testów integracyjnych (w odpowiedzi na polecenie

mvn integration-test

). W poni'szym przyk"adzie nazwy testów integracyjnych ko+cz% si!

wyra'eniem

IntegrationTest

. Mamy wi!c do czynienia z wyj%tkowo prost% konwencj%

— w razie potrzeby mo'na oczywi$cie zdefiniowa* alternatywn%, w"asn% konwencj!. Poni'szy
plik konfiguracyjny wy"%cza testy integracyjne ze zbioru zwyk"ych testów jednostkowych
(skojarzonych z faz%

test

) i kojarzy je z odr!bn% faz%

integration-test

<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>unit-tests</id>
<phase>test</phase>

Czytaj dalej...

10.13. Korzystanie z frameworku JUnit 4 w &rodowisku Eclipse

429

<goals>
<goal>test</goal>
</goals>
<configuration>
<excludes>
<exclude>**/*IntegrationTest.java</exclude>
</excludes>
</configuration>
</execution>
<execution>
<id>integration-tests</id>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<includes>
<include>**/*IntegrationTest.java</include>
</includes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>

Aby wykona* testy wydajno$ciowe, wystarczy wywo"a* faz! testów integracyjnych:

$ mvn integration-test

10.13. Korzystanie z frameworku JUnit 4

w &rodowisku Eclipse

Korzystanie z po$rednictwa zintegrowanego $rodowiska wytwarzania (IDE) jest bodaj najprost-
szym i najbardziej efektywnym sposobem wykonywania testów jednostkowych. Framework
JUnit 4 wprost doskonale integruje si! ze $rodowiskiem Eclipse — testy tego frameworku
mo'na wywo"ywa* w dok"adnie taki sam sposób jak testy frameworku JUnit 3, czyli za pomoc%
opcji Run As… i JUnit Test. Je$li korzystamy z asercji Javy 5, powinni$my dodatkowo u'y* opcji

-ea

(od ang. enable assertions) w oknie konfiguracyjnym Run (patrz rysunek 10.1). W przeciwnym

razie nasze asercje zostan% po prostu zignorowane.

Co wi!cej, Eclipse prawid"owo obs"uguje te' takie mechanizmy frameworku JUnit 4 jak testy
sparametryzowane (patrz rysunek 10.1).

>rodowisko Eclipse dodatkowo oferuje mo'liwo$* tworzenia nowych przypadków testowych
frameworku JUnit 4 za pomoc% opcji New… i JUnit Unit Test (patrz rysunek 10.3). Za po$rednic-
twem tego okna dialogowego mo'emy tworzy* klasy testów frameworków JUnit 3.8 lub JUnit 4
(oba typy testów jednostkowych mo'na stosowa* jednocze$nie w ramach tego samego projektu).

Wyszukiwarka

Podobne podstrony:
Java Praktyczne narzedzia javapn
informatyka java ee 6 leksykon kieszonkowy arun gupta ebook
informatyka java i xml wydanie iii brett d mclaughlin ebook
informatyka e biznes poradnik praktyka wydanie ii maciej dutko ebook
informatyka programowanie w jezyku java zbior zadan z p odpowiedziami wieslaw rychlicki ebook
informatyka java zadania z programowania z przykladowymi rozwiazaniami miroslaw j kubiak ebook
informatyka okablowanie strukturalne sieci teoria i praktyka wydanie ii rafal pawlak ebook
informatyka usb praktyczne programowanie z windows api w c andrzej daniluk ebook
informatyka praktyczny kurs sql danuta mendrala ebook
informatyka usb praktyczne programowanie z windows api w c wydanie ii andrzej daniluk ebook
informatyka java ee 6 programowanie aplikacji www krzysztof rychlicki kicior ebook
informatyka joomla praktyczne projekty witold wrotek ebook
informatyka j2me praktyczne projekty wydanie ii krzysztof rychlicki kicior ebook

więcej podobnych podstron