Java Praktyczne narzedzia javapn

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 treci

Sowo wstpne ........................................................................................................................17

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

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

I Narzdzia kompilujce ...........................................................................37

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

1.1. Rola narzdzia Ant w procesie kompilacji

1.2. Instalacja Anta

1.3. Pynne wprowadzenie w wiat Anta

1.4. Kompilowanie kodu Javy za pomoc Anta

1.5. Dostosowywanie skryptów kompilacji za pomoc waciwoci

1.6. Przeprowadzanie testów jednostkowych za pomoc Anta

1.7. Generowanie dokumentacji za pomoc narzdzia Javadoc

1.8. Pakowanie gotowej aplikacji

1.9. Wdraanie aplikacji

1.10.Automatyczne przygotowywanie rodowiska dla uruchamianych

skryptów kompilacji

1.11. Stosowanie zalenoci narzdzia 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 narzdzia Maven w procesie kompilacji

2.2. Maven i Ant

2.3. Instalacja Mavena

2.4. Kompilacje deklaratywne i model obiektu projektu Mavena

101

Spis treci

2.5. Zrozumie cykl ycia Mavena 2

112

2.6. Struktura katalogów Mavena

114

2.7. Konfigurowanie Mavena pod ktem naszego rodowiska

115

2.8. Zarzdzanie zalenociami w Mavenie 2

118

2.9. Poszukiwanie zalenoci za porednictwem 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 wdraanie naszej aplikacji

138

2.15. Wdraanie aplikacji z wykorzystaniem narzdzia 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 wasnych moduów rozszerze

147

2.19. Konfigurowanie repozytorium korporacyjnego za pomoc narzdzia Archiva

154

2.20. Konfigurowanie repozytorium korporacyjnego z wykorzystaniem narzdzia

Artifactory

166

2.21. Stosowanie narzdzia Ant w Mavenie

178

2.22. Archetypy zaawansowane

183

2.23. Stosowanie podzespoów

187

II Narzdzia 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. Wypoyczanie projektu

198

3.5. Praca na plikach — aktualizowanie i zatwierdzanie plików z kodem ródowym

200

3.6. Blokowanie repozytorium

204

3.7. Praca z mechanizmem zastpowania sów kluczowych

204

3.8. Praca z plikami binarnymi

205

3.9. Znaczniki systemu CVS

207

3.10. Tworzenie odgazie w systemie CVS

208

3.11. Scalanie zmian z odgazienia

210

3.12. Przegldanie historii zmian

211

3.13. Wycofywanie zmian

213

3.14. Stosowanie CVS-a w systemie Windows

214

Spis treci

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. Wypoyczanie kopii roboczej

227

4.7. Importowanie istniejcych 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 biecej sytuacji — polecenie status

235

4.11. Rozwizywanie konfliktów

237

4.12. Stosowanie znaczników, odgazie i operacji scalania

239

4.13. Przywracanie poprzedniej rewizji

243

4.14. Blokowanie dostpu do plików binarnych

244

4.15. Zdejmowanie i przechwytywanie blokad

246

4.16. Udostpnianie zablokowanych plików tylko do odczytu za pomoc

waciwoci svn:needs-lock

248

4.17. Stosowanie waciwoci

249

4.18. Historia zmian w systemie Subversion — rejestrowanie zdarze i okrelanie

odpowiedzialnoci 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 obsug protokou WebDAV/DeltaV

258

4.22. Konfigurowanie bezpiecznego serwera WebDAV/DeltaV

263

4.23. Dostosowywanie dziaania systemu Subversion za pomoc skryptów

przechwytujcych

264

4.24. Instalacja systemu Subversion w formie usugi systemu operacyjnego Windows

266

4.25. Sporzdzanie 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 Ciga integracja .................................................................................. 293

5. Konfigurowanie serwera cigej integracji za pomoc narzdzia Continuum ...... 297

5.1. Wprowadzenie do narzdzia Continuum

297

5.2. Instalacja serwera narzdzia Continuum

297

Spis treci

5.3. Rczne uruchamianie i zatrzymywanie serwera

301

5.4. Sprawdzanie stanu serwera

302

5.5. Uruchamianie serwera narzdzia 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 powoki

307

5.10. Zarzdzanie kompilacjami projektu

307

5.11. Zarzdzanie uytkownikami

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 narzdzia Continuum

314

5.16. Konfigurowanie portów witryny internetowej serwera Continuum

315

5.17. Automatyczne generowanie witryny Mavena za pomoc narzdzia Continuum

316

5.18. Konfigurowanie zadania rcznej kompilacji

317

5.19. Konkluzja

319

6. Konfigurowanie serwera cigej integracji za pomoc narzdzia CruiseControl ......... 321

6.1. Wprowadzenie do narzdzia CruiseControl

321

6.2. Instalacja narzdzia CruiseControl

322

6.3. Konfigurowanie projektu Anta

323

6.4. Powiadamianie czonków zespou za pomoc mechanizmów publikujcych

329

6.5. Konfigurowanie projektu Mavena 2 w narzdziu CruiseControl

336

6.6. Panel administracyjny narzdzia CruiseControl

338

6.7. Dodatkowe narzdzia

339

6.8. Konkluzja

340

7. LuntBuild — serwer cigej integracji z interfejsem WWW .................................... 341

7.1. Wprowadzenie do narzdzia LuntBuild

341

7.2. Instalowanie narzdzia 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 narzdzia LuntBuild w rodowisku Eclipse

355

7.8. Raportowanie w systemie LuntBuild o pokryciu testami z wykorzystaniem

narzdzia Cobertura

359

7.9. Integrowanie narzdzia LuntBuild z Mavenem

365

7.10. Konkluzja

370

Spis treci

8. Ciga integracja z wykorzystaniem narzdzia Hudson ...........................................371

8.1. Wprowadzenie do narzdzia Hudson

371

8.2. Instalacja narzdzia Hudson

371

8.3. Zarzdzanie 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. Przegldanie i awansowanie wybranych kompilacji

383

8.10. Zarzdzanie uytkownikami

385

8.11. Uwierzytelnianie i bezpieczestwo

386

8.12. Przegldanie zmian

386

8.13. Moduy rozszerze Hudsona

387

8.14. ledzenie wyników testów

388

8.15. ledzenie mierników kodu ródowego

388

8.16. Raportowanie o pokryciu kodu

390

9. Konfigurowanie platformy natychmiastowej komunikacji

za pomoc serwera Openfire ....................................................................................393

9.1. Natychmiastowa komunikacja w projekcie informatycznym

393

9.2. Instalacja serwera Openfire

394

9.3. Konfigurowanie uytkowników i kont uytkowników serwera Openfire

394

9.4. Uwierzytelnianie uytkowników z wykorzystaniem zewntrznej bazy danych

396

9.5. Uwierzytelnianie uytkowników na serwerze POP3

397

9.6. Organizowanie wirtualnych spotka zespou z wykorzystaniem czatu grupowego

398

9.7. Rozszerzanie funkcjonalnoci 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 narzdziem LuntBuild

402

9.11. Wysyanie komunikatów Jabbera z poziomu aplikacji Javy

za porednictwem interfejsu API Smack

402

9.12. Wykrywanie obecnoci interfejsu API Smack

405

9.13. Otrzymywanie wiadomoci 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 treci

10.4. Proste testy wydajnoci z wykorzystaniem limitów czasowych

414

10.5. Prosta weryfikacja wystpowania wyjtkó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. Zarzdzanie cyklem ycia testów

444

11.8. Stosowanie grup testów

449

11.9. Zarzdzanie zalenociami

451

11.10. Testowanie równolege

454

11.11. Parametry testów i testowanie sterowane danymi

455

11.12. Weryfikacja wyjtków

456

11.13. Obsuga bdów czciowych

456

11.14. Ponowne wykonywanie testów zakoczonych niepowodzeniem

457

12. Maksymalizacja pokrycia testami za pomoc narzdzia Cobertura .......................459

12.1. Pokrycie testami

459

12.2. Uruchamianie narzdzia Cobertura za porednictwem Anta

460

12.3. Weryfikacja pokrycia kodu testami frameworku TestNG

463

12.4. Interpretacja raportu narzdzia Cobertura

465

12.5. Wymuszanie duego pokrycia kodu

467

12.6. Generowanie raportów narzdzia 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 treci

V Testy integracyjne, funkcjonalne, obcieniowe i wydajnociowe ...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 zastpczych z wykorzystaniem frameworku StrutsTestCase

483

13.5. Testowanie mechanizmów obsugi bdów w aplikacji frameworku Struts

488

13.6. Dostosowywanie rodowiska testowego

489

13.7. Testy wydajnociowe pierwszego stopnia

489

13.8. Konkluzja

490

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

14.1. Wprowadzenie

491

14.2. Przegld

491

14.3. Struktura frameworku DbUnit

493

14.4. Przykadowa aplikacja

497

14.5. Wypenianie bazy danych

498

14.6. Weryfikacja bazy danych

506

14.7. Zastpowanie wartoci

510

14.8. Alternatywne formaty zbiorów danych

516

14.9. Obsuga niestandardowych testów danych

520

14.10. Pozostae zastosowania

524

15. Testy wydajnociowe z wykorzystaniem frameworku JUnitPerf ...........................533

15.1. Wprowadzenie do frameworku JUnitPerf

533

15.2. Badanie wydajnoci za pomoc klasy TimedTest

534

15.3. Symulowanie obcienia za pomoc klasy LoadTest

536

15.4. Przeprowadzanie testów wydajnociowych, które nie gwarantuj

bezpieczestwa przetwarzania wielowtkowego

539

15.5. Oddzielanie testów wydajnociowych od testów jednostkowych w Ancie

540

15.6. Oddzielanie testów wydajnociowych od testów jednostkowych w Mavenie

541

16. Wykonywanie testów obcieniowych i wydajnociowych

za pomoc narzdzia JMeter .....................................................................................543

16.1. Wprowadzenie

543

16.2. Instalacja narzdzia JMeter

544

16.3. Testowanie prostej aplikacji internetowej

544

16.4. Projektowanie struktury naszego przypadku testowego

550

16.5. Rejestrowanie i wywietlanie wyników testu

553

Spis treci

16.6. Rejestrowanie przypadku testowego za pomoc serwera proxy narzdzia JMeter 556
16.7. Testowanie z wykorzystaniem zmiennych

558

16.8. Testowanie na wielu komputerach

560

17. Testowanie usug sieciowych za pomoc narzdzia SoapUI ..................................563

17.1. Wprowadzenie

563

17.2. Wprowadzenie do narzdzia SoapUI

563

17.3. Instalacja narzdzia SoapUI

565

17.4. Instalacja lokalnej usugi sieciowej

565

17.5.Testowanie usug sieciowych za pomoc narzdzia SoapUI

567

17.6. Przeprowadzanie testów obcieniowych za pomoc narzdzia SoapUI

573

17.7. Uruchamianie narzdzia SoapUI z poziomu wiersza polece

576

17.8. Uruchamianie narzdzia SoapUI za porednictwem Anta

578

17.9. Uruchamianie narzdzia SoapUI za porednictwem Mavena

579

17.10. Testy cige

580

17.11. Konkluzja

581

18. Profilowanie i monitorowanie aplikacji Javy

za pomoc narzdzi pakietu Sun JDK .......................................................................583

18.1. Narzdzia profilujce i monitorujce pakietu Sun JDK

583

18.2. Nawizywanie poczenia z aplikacj Javy i monitorowanie jej dziaania

za pomoc narzdzia JConsole

583

18.3. Monitorowanie zdalnej aplikacji na serwerze Tomcat za pomoc

narzdzia JConsole

587

18.4. Wykrywanie i identyfikacja wycieków pamici za pomoc narzdzi pakietu JDK

588

18.5. Diagnozowanie wycieków pamici z wykorzystaniem zrzutów sterty

oraz narzdzi 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 uycia pamici na podstawie wyników podstawowej analizy pamici

607

19.7. Analiza czasu wykonywania

609

19.8. Wywietlanie statystyk pokrycia

610

19.9. Stosowanie filtrów zawajcych uzyskiwane wyniki

611

19.10. Profilowanie aplikacji internetowej

613

19.11. Konkluzja

613

Spis treci

20. Testowanie interfejsów uytkownika ...................................................................... 615

20.1. Wprowadzenie

615

20.2. Testowanie aplikacji internetowej za pomoc narzdzia Selenium

615

20.3. Testowanie graficznych interfejsów Swinga za pomoc narzdzia FEST

642

20.4. Konkluzja

651

VI Narzdzia pomiaru jakoci................................................................... 653

21. Wykrywanie i wymuszanie standardów kodowania

za pomoc narzdzia Checkstyle .............................................................................. 657

21.1. Wymuszanie standardów kodowania za pomoc narzdzia Checkstyle

657

21.2. Stosowanie narzdzia Checkstyle w rodowisku Eclipse

659

21.3. Modyfikowanie regu narzdzia Checkstyle w rodowisku Eclipse

663

21.4. Dostosowywanie regu narzdzia Checkstyle z wykorzystaniem plików

konfiguracyjnych w formacie XML

665

21.5. Dostosowywanie pracy narzdzia Checkstyle — reguy,

bez których moemy sobie poradzi , i kilka regu, z których warto korzysta

667

21.6. Stosowanie narzdzia Checkstyle do definiowania regu

dla nagówków w kodzie ródowym

671

21.7. Wstrzymywanie testów narzdzia Checkstyle

672

21.8. Korzystanie z narzdzia Checkstyle w Ancie

673

21.9. Korzystanie z narzdzia Checkstyle w Mavenie

674

22. Wstpne wykrywanie bdów za pomoc narzdzia PMD ..................................... 677

22.1. Narzdzie PMD i statyczna analiza kodu

677

22.2. Korzystanie z narzdzia PMD w rodowisku Eclipse

677

22.3.Konfiguracja regu narzdzia PMD w rodowisku Eclipse

680

22.4. Wicej o zbiorach regu narzdzia PMD

681

22.5. Pisanie wasnych zbiorów regu narzdzia

684

22.6. Generowanie raportu narzdzia PMD w rodowisku Eclipse

685

22.7. Wstrzymywanie regu narzdzia PMD

686

22.8. Wykrywanie praktyki „wytnij i wklej” za pomoc narzdzia CPD

687

22.9. Stosowanie narzdzia PMD w Ancie

688

22.10. Stosowanie narzdzia PMD w Mavenie

691

23. Wstpne wykrywanie bdów za pomoc narzdzia FindBugs ..............................693

23.1. FindBugs jako wyspecjalizowany zabójca bdów

693

23.2.Stosowanie narzdzia FindBugs w rodowisku Eclipse

695

23.3. Wybiórcze zawieszanie stosowania regu za pomoc filtrów narzdzia FindBugs

697

23.4. Stosowanie adnotacji narzdzia FindBugs

698

Spis treci

23.5. Korzystanie z narzdzia FindBugs w Ancie

700

23.6. Korzystanie z narzdzia FindBugs w Mavenie

702

23.7. Konkluzja

704

24. Analiza wyników — póautomatyczne przegldy kodu

za pomoc narzdzia Jupiter .................................................................................... 705

24.1. Wprowadzenie do Jupitera — narzdzia do przegldania kodu

w rodowisku Eclipse

705

24.2. Instalacja narzdzia Jupiter w rodowisku Eclipse

706

24.3.Zrozumie proces przegldów kodu narzdzia Jupiter

706

24.4. Prowadzenie przegldów wasnego kodu

708

24.5. Konfiguracja

709

24.6. Ustawianie domylnych wartoci konfiguracyjnych

713

24.7. Przegldy indywidualne

714

24.8. Przegldy zespoowe

716

24.9. Faza wprowadzania poprawek

719

24.10. Wewntrzne dziaania Jupitera

719

24.11. Konkluzja

721

25. Koncentrujmy si na tym, co naprawd wane — narzdzie Mylyn ...................... 723

25.1. Wprowadzenie do narzdzia 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 zarzdzania kontekstami

731

25.6. Korzystanie ze zbiorów zmian rodowiska Eclipse

734

25.7. Wspódzielenie kontekstu z pozostaymi programistami

736

25.8. Konkluzja

737

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

26.1. Wprowadzenie

739

26.2. Narzdzie QALab

739

26.3. Mierzenie iloci kodu ródowego za pomoc moduu rozszerzenia StatSCM

747

26.4. Statystyki narzdzia StatSVN w Ancie

748

VII Narzdzia do zarzdzania problemami .............................................. 751

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

27.1. Wprowadzenie do narzdzia Bugzilla

753

27.2. Instalacja narzdzia Bugzilla

753

27.3. Konfigurowanie rodowiska narzdzia Bugzilla

757

Spis treci

27.4. Zarzdzanie kontami uytkowników

758

27.5. Ograniczanie dostpu do bazy danych z wykorzystaniem grup uytkowników

760

27.6. Konfigurowanie produktu

762

27.7. ledzenie postpu z wykorzystaniem tzw. kamieni milowych

764

27.8. Zarzdzanie grupami produktów z wykorzystaniem klasyfikacji

764

27.9. Przeszukiwanie bdów

765

27.10. Tworzenie nowego bdu

767

27.11. Cykl ycia bdu reprezentowanego w systemie Bugzilla

768

27.12. Tworzenie harmonogramu rozsyania powiadomie (pojkiwania)

770

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

771

27.14. Konkluzja

772

28. Trac — lekkie zarzdzanie projektami ..................................................................... 773

28.1. Wprowadzenie do narzdzia Trac

773

28.2. Instalacja narzdzia Trac

774

28.3. Definiowanie projektu narzdzia Trac

776

28.4. Uruchamianie narzdzia Trac w formie autonomicznego serwera

778

28.5 Konfiguracja polecenia tracd jako usugi systemu Windows

779

28.6. Instalacja narzdzia Trac na serwerze Apache

780

28.7. Administrowanie witryn internetow Traca

781

28.8. Zarzdzanie kontami uytkowników

783

28.9. Dostosowywanie witryny internetowej narzdzia Trac

— korzystanie z funkcji witryn typu wiki

786

28.10. Stosowanie systemu zarzdzania biletami Traca

790

28.11. Aktualizowanie bdów reprezentowanych w narzdziu Trac na podstawie

zawartoci repozytorium systemu Subversion

794

28.12. Modyfikowanie pól biletów Traca

795

28.13. Konfigurowanie powiadomie wysyanych poczt elektroniczn

797

28.14. Raportowanie z wykorzystaniem zapyta i raportów Traca

797

28.15. Zarzdzanie postpami prac za pomoc map drogowych

i diagramów linii czasu

800

28.16. Przegldanie repozytorium z kodem ródowym

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 Narzdzia do dokumentacji technicznej ............................................ 807

29. Komunikacja w ramach zespou projektowego

za porednictwem witryny Mavena 2 ......................................................................809

29.1.Witryna internetowa Mavena 2 jako narzdzie komunikacyjne

809

29.2. Konfigurowanie mechanizmu generowania witryny o projekcie Mavena

810

Spis treci

29.3. Wczanie do witryny Mavena raportów generowanych przez inne narzdzia

815

29.4. Tworzenie dedykowanego projektu witryny Mavena

819

29.5. Definiowanie szkicu witryny

821

29.6. Architektura mechanizmu generujcego witryny Mavena

822

29.7. Stosowanie fragmentów kodu

826

29.8. Modyfikowanie wygldu i sposobu obsugi witryny Mavena

827

29.9. Udostpnianie witryny

830

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

30.1. Wprowadzenie

833

30.2. Wizualizacja struktury bazy danych za pomoc narzdzia SchemaSpy

833

30.3. Generowanie dokumentacji kodu ródowego za pomoc Doxygena

841

30.4. Umieszczanie diagramów notacji UML w dokumentacji narzdzia Javadoc

z wykorzystaniem narzdzia UmlGraph

850

30.5. Konkluzja

854

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

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

409

ROZDZIA 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 powstao mnóstwo przydatnych rozszerze tego frameworku uatwiajcych
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 czci tej ksiki. W niniejszym podrozdziale spróbujemy sobie przy-
pomnie framework 3.8, aby lepiej rozumie dalszy materia powicony 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 okrelanych
mianem przypadków testowych. Wszystkie przypadki testowe tego frameworku musz rozsze-
rza klas

TestCase

. Testy jednostkowe implementujemy w formie metod tych klas — definiujc

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 sowa

test

. Take nazwy klas testowych musz by zgodne z prost konwencj — nazwa

kadej takiej klasy musi si koczy sowem

Test

Poniej przedstawiono prost klas testow frameworku JUnit 3.8 testujc inn klas, która
z kolei odpowiada za obliczanie podatku od wartoci dodanej (ang. Value Added Tax — VAT),
nazywanego te podatkiem od towarów i usug. Przyjmijmy, e podstawowa stawka podatku
VAT wynosi 22 procent. Nasz klasa testu jednostkowego moe mie nastpujc 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. Wanie wymienione metody skadaj si na jdro

testów jednostkowych, poniewa za ich porednictwem wykonujemy nasze testy. Metody

assert

su do sprawdzania, czy uzyskiwane wyniki s zgodne z wartociami oczekiwanymi.

410

Rozdzia 10. Testowanie kodu z wykorzystaniem frameworku JUnit

Za porednictwem pierwszego parametru metody

assert

moemy przekaza opcjonalny

komunikat, który w przyszoci powinien nam uatwi identyfikacj bdu (szczególnie jeli
korzystamy z duej liczby testów jednostkowych).

Metody

setUp()

tearDown()

(zwró my uwag na wielkie litery!) mona przykry wersjami

odpowiednio inicjalizujcymi i przywracajcymi (przed i po kadym tecie) stan rodowiska
testowego, w którym wykonujemy nasz kod. Jeli na przykad korzystamy z wielu przypadków
testowych operujcych na obiekcie

calculator

, moemy 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);
}
// Pozostae testy obiektu calculator...
}

Moliwoci frameworku JUnit 3 oczywicie nie ograniczaj si do zaprezentowanych mecha-
nizmów, jednak uzyskana wiedza o architekturze tego frameworku powinna w zupenoci
wystarczy do zrozumienia innowacji wprowadzonych w nowszych frameworkach i rozszerze
frameworku JUnit 3 omawianych w pozostaych rozdziaach. Framework JUnit 4 pod wieloma
wzgldami przewysza framework JUnit 3, jednak wersja 3.8 wci cieszy si du popularno-
ci, a wiele atrakcyjnych moduów rozszerze nadal nie doczekao si aktualizacji do wersji
4. W kolejnych podrozdziaach tego rozdziau skoncentrujemy si wycznie 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 kademu programicie. JUnit oferuje te wiele przydatnych
rozszerze stworzonych z myl o bardziej wyspecjalizowanych procesach testowych. Frame-
work JUnit (w oryginalnej wersji autorstwa Kenta Becka i Ericha Gammy) jest uwaany
za rozwizanie, które (przynajmniej teoretycznie) spopularyzowao praktyki testów jednostko-
wych wród programistów Javy. Okazuje si jednak, e wskutek spadku dynamiki zmian
wprowadzanych w podstawowym interfejsie API w ostatnich latach powstao i zyskao
popularno kilka innych, jeszcze bardziej innowacyjnych frameworków, na przykad TestNG
(patrz rozdzia 20.).

JUnit 3 nakada 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 moemy uy 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 kadym razem, gdy wykonujemy jaki test, co znacznie utrudnia refaktory-
zacj i optymalizacj kodu testowego. JUnit 3 w aden sposób nie wspiera na przykad testowa-
nia sterowanego danymi (czyli wykonywania testów na danych pochodzcych z zewntrz).
We frameworku JUnit 3 brakuje te takich mechanizmów jak funkcje zarzdzania zalenociami
pomidzy testami czy grupami testów.

JUnit 4 jest niemal cakowicie przebudowanym interfejsem API JUnit, który ma na celu wyko-
rzystanie postpu obserwowanego w wiecie technologii Javy w cigu ostatnich kilku lat.
Framework JUnit 4 jest prostszy, atwiejszy w uyciu 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 uatwi pisanie testów jednostkowych, w tym obsug adnotacji
i bardziej elastyczny model inicjalizacji klas testów. We frameworku JUnit test moe mie
posta dowolnej klasy Javy, a metody testów nie musz by zgodne z adnymi konwencjami
nazewniczymi.

Sprawdmy wic, jak nasze testy kalkulatora podatkowego (patrz podrozdzia 10.1) wygldayby
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 kolejnoci zwróci uwag na brak koniecznoci rozszerzania konkretnej
klasy przez przypadki testowe frameworku JUnit 4 (takie wymaganie obowizywao 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 uwaa 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 sowa

test

, jak

testThis()

czy

testThat()

), ale wymaga, by metody testów jednostkowych zwracay

void

i nie pobieray

adnych parametrów. Teoretycznie mona by nawet umieszcza testy jednostkowe w tej
samej klasie, w której znajduje si testowany kod, jednak w praktyce lepszym rozwizaniem
jest definiowanie kodu testowego w odrbnych klasach.

Klasa

org.junit.Assert

zawiera tradycyjne metody

assert

frameworku JUnit 3.x, do których

zdylimy si przyzwyczai i które tak lubimy. We frameworku JUnit 3 metody

assert

byy

definiowane w klasie

TestCase

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

— dziki temu mona byo z nich korzysta w dowolnych testach. Z zupenie 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 — moemy dla tej klasy

412

Rozdzia 10. Testowanie kodu z wykorzystaniem frameworku JUnit

uy operacji statycznego importowania, aby korzysta z niezbdnych klas

assert

(w tym

assertEquals

assertNotNull

itp.; patrz przykady w dalszej czci tego rozdziau) w dokadnie

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

Alternatywnym rozwizaniem jest stosowanie wyrae

assert

dostpnych w Javie 5:

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

Wyraenie w tej formie sprawia wraenie bardziej eleganckiego, jednak musimy pamita
o pewnej puapce — Java ignoruje nasze wyraenia

assert

, chyba e w wierszu polece uyjemy

opcji

-ea

(od ang. enable assertions).

10.3. Konfigurowanie i optymalizacja przypadków

testów jednostkowych

Jak kady kod ródowy, testy jednostkowe wymagaj efektywnego kodowania i — w razie
koniecznoci — refaktoryzacji. Framework JUnit 4 oferuje kilka adnotacji, które mog nam
to zadanie bardzo uatwi . Adnotacja

@Before

wskazuje metod, która musi by wywoana

przed kadym testem, czyli w praktyce zastpuje znan z frameworku JUnit 3.x metod

setup()

. Moemy te uy adnotacji

@After

do wskazania metod przywracajcych stan

rodowiska testowego po kadym wykonanym tecie. W tym przypadku metoda

initialize()

bdzie wywoywana przed, a metoda

tidyup()

po kadym tecie 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 rozwizanie wci nie jest optymalne. JUnit oferuje kilka innych adnotacji, których
mona z powodzeniem uywa 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 zakoczeniu wykonywania testów tej klasy. Cel ten
mona osign odpowiednio za pomoc adnotacji

@BeforeClass

@AfterClass

. Metody

oznaczone adnotacj

@BeforeClass

zostan wywoane tylko raz, przed wykonaniem którego-

kolwiek z testów jednostkowych definiowanych przez dan klas. Jak atwo si domyli ,
metody oznaczone adnotacj

@AfterClass

zostan wywoane dopiero po zakoczeniu wszyst-

kich testów. W powyszym przykadzie obiekt

calculator

zostaby utworzony tylko raz (na

pocztku testów jednostkowych) i zniszczony dopiero po wykonaniu wszystkich testów.
Klas t mona uzupeni o metod

reset()

wywoywan przed kadym testem jednostkowym

i odpowiedzialn za kadorazowe ponowne inicjalizowanie testowanego obiektu

calculator

Moliwy sposób implementacji tak zoptymalizowanej klasy testów jednostkowych przedstawio-
no poniej:

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 wydajnoci

z wykorzystaniem limitów czasowych

Jednym z najprostszych sposobów przeprowadzania testów wydajnoci jest sprawdzanie, czy
okrelony test zawsze jest wykonywany w okrelonych ramach czasowych. Takie rozwizanie
bywa szczególnie przydatne w przypadku zapyta wykonywanych na bazie danych z uyciem
takich narzdzi odwzorowa obiektowo-relacyjnych jak Hibernate. Nawet proste bdy
w plikach odwzorowa tego narzdzia mog skutkowa znacznie wyduonymi czasami
odpowiedzi (take w przypadku stosunkowo prostych zapyta). W przeciwiestwie do trady-
cyjnego testu jednostkowego, test z okrelonym limitem czasowym umoliwia wykrywanie
tego rodzaju bdów.

Tego rodzaju testy sprawdzaj si take w roli mechanizmów wykrywajcych ptle nieskoczo-
ne, chocia wskazanie fragmentów kodu, które mog zawiera tego rodzaju konstrukcje, jest
oczywicie nieporównanie trudniejsze.

Opisan technik zintegrowano bezporednio z adnotacj

@Test

, która umoliwia ustawianie

górnego limitu czasu, w którym dany test musi si zakoczy — w przeciwnym razie po upy-
niciu tego czasu test koczy si bdem. W tym celu naley zdefiniowa parametr

timeout

(reprezentujcy limit czasowy wyraony w milisekundach) adnotacji

@Test

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

Jeli uyte zapytanie zajmuje testowanej funkcji wicej ni 100 milisekund, nasz test koczy
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 wydajnoci i których
efektywno ma kluczowe znaczenie dla funkcjonowania naszej aplikacji, warto dodatkowo
sprawdzi , czy oferowana przepustowo spenia nasze oczekiwania. Oczywicie im mniejsza
bdzie warto limitu czasowego, tym wiksze bdzie ryzyko wystpienia sytuacji, w której
jaki czynnik zewntrzny spowalniajcy nasze testy doprowadzi do nieuzasadnionego przekro-
czenia tego limitu. Na przykad w poniszym 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 bd zblione do rzeczywistoci
i e badane metody nie s szczególnie powolne — nie powinnimy by zbyt wymagajcy.

10.5. Prosta weryfikacja wystpowania wyjtków

W niektórych przypadkach warto sprawdza , czy w okrelonych okolicznociach nastpuje
prawidowe generowanie wyjtków. We frameworku JUnit 3.x to do pracochonne zadanie
wie si z koniecznoci przechwytywania wyjtku — jeli wyjtek uda si przechwyci ,
przyjmujemy, e test zakoczy si pomylnie; w przeciwnym razie test koczy si niepowo-
dzeniem. We frameworku JUnit 4 mamy do dyspozycji parametr

expected

adnotacji

@Test

któremu naley przypisa klas oczekiwanego wyjtku (wanie ten wyjtek powinien zosta
wygenerowany zgodnie z naszym planem). W poniszym (do mao realistycznym) przykadzie
oczekujemy od aplikacji wygenerowania wyjtku

IllegalArgumentException

, jeli dany rok

jest mniejszy od przyjtego progu. We frameworku JUnit 4 odpowiedni test jest bardzo prosty:

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

Jeli badana metoda nie wygeneruje wyjtku

IllegalArgumentException

, nasz test zakoczy

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 nuce, zatem wielu programistów próbuje i na skróty.
Okazuje si jednak, e od pewnych czynnoci nie uciekniemy — dobre testy jednostkowe
musz weryfikowa dziaanie funkcji biznesowych dla rozmaitych danych, jak przypadki
skrajne, klasy danych itp. Ten sam test moe si zakoczy pomylnie dla jednego zbioru danych,
by chwil póniej wykaza powane bdy dla innego zbioru. Jeli jednak programista musi
napisa odrbny przypadek testowy dla kadej wartoci (zgodnie z najlepszymi praktykami
testowania), najprawdopodobniej jego kod bdzie weryfikowa stosunkowo niewielki zbiór
wartoci. Czy nie byoby wspaniale, gdybymy mogli wielokrotnie wykonywa ten sam test
jednostkowy z wykorzystaniem rónych danych?

Okazuje si, e JUnit 4 oferuje dopracowany mechanizm uatwiajcy nam testowanie kodu na
dowolnych zbiorach danych. Za pomoc tego mechanizmu moemy zdefiniowa kolekcj
danych testowych i wymusi jej automatyczne wypenianie w ramach naszych metod testów
jednostkowych. Przeanalizujmy teraz prosty przykad. Przypu my, e musimy napisa klas
wyznaczajc wysoko podatku dochodowego dla okrelonych dochodów we wskazanym
roku. Interfejs naszej klasy biznesowej moe mie nastpujc posta :

416

Rozdzia 10. Testowanie kodu z wykorzystaniem frameworku JUnit

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

Wyznaczanie podatku dochodowego z reguy wymaga wykonywania kilku nieatwych oblicze.
W wikszoci krajów stosuje si system podatków progresywnych, gdzie stawki podatkowe
rosn wraz ze wzrostem opodatkowanych dochodów. Stawki definiuje si dla odrbnych
przedziaów dochodów. Co wicej, same progi podatkowe (a wic take przedziay dochodów)
nierzadko s zmieniane w kolejnych latach. W przypadku aplikacji odpowiedzialnej za tego
rodzaju obliczenia niezwykle wane jest przetestowanie wartoci z kadego przedziau, a take
przypadków skrajnych. W tej sytuacji powinnimy opracowa kolekcj danych testowych
obejmujcych moliwie wiele dochodów, lat i oczekiwanych obcie podatkowych. Sprawdmy,
jak mona to zrobi .

JUnit 4 umoliwia nam definiowanie zbiorów danych testowych, które mona nastpnie
przekazywa do naszych testów jednostkowych. W tym przypadku musimy przetestowa
róne dochody podlegajce opodatkowaniu w rónych przedziaach podatkowych. W prezento-
wanym przykadzie skoncentrujemy si tylko na roku 2006, jednak w rzeczywistej aplikacji
powinnimy podda testom wiele lat podatkowych. Nasze zbiory testowe bd wic zawiera
po trzy wartoci: opodatkowane dochody, rok podatkowy oraz prawidow wysoko podatku
dochodowego.

Korzystanie z tych danych testowych wymaga skonfigurowania sparametryzowanej klasy
testowej. Moe to by zwyka klasa testowa z konstruktorem otrzymujcym na wejciu kilka
parametrów, a konkretnie po jednym parametrze dla kadej wartoci naszego zbioru danych.
Oznacza to, e w analizowanym przypadku wspomniany konstruktor bdzie pobiera trzy
parametry: opodatkowane dochody, rok podatkowy i oczekiwan wysoko podatku docho-
dowego. Sparametryzowana klasa testowa z reguy obejmuje zmienne skadowe reprezentu-
jce kade z tych pól. Za inicjalizacj tych pól odpowiada konstruktor, a waciwe metody
testów jednostkowych wykorzystuj je w czasie testowania.

JUnit tworzy odrbny obiekt naszej klasy testów dla kadego wiersza danych testowych,
po czym wykonuje na tych danych testy jednostkowe (metody) tej klasy. Oznacza to, e jeli
nasze dane testowe obejmuj 20 wierszy, JUnit utworzy obiekt naszej klasy 20 razy i kadorazo-
wo wykona testy jednostkowe na innym wierszu tego zbioru danych.

Sprawdmy teraz, jak mona ten mechanizm zaimplementowa . Kompletny kod naszej klasy
testowej (dla fikcyjnych progów podatkowych) przedstawiono poniej:

@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 uy adnotacji

@RunWith

wskazujcej na klas

Parameterized

, aby zasygnalizowa frameworkowi JUnit,

e nasza klasa testowa zawiera sparametryzowane przypadki testowe:

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

Musimy teraz sporzdzi kolekcj naszych danych testowych. W tym celu definiujemy funkcj
oznaczon adnotacj

@Parameters

i zwracajc dane testowe w formie kolekcji. Dane testowe

wewntrznie czsto maj posta listy tablic. W naszym przypadku dane testowe przyjmuj
form listy tablic wartoci, gdzie kada tablica obejmuje trzy elementy: dochód, rok i oczekiwan
wysoko podatku dochodowego (od danego dochodu osignitego we wskazanym roku
podatkowym):

Jak ju wspomniano, kiedy framework JUnit 4 wykonuje nasz klas testow, w rzeczywistoci
tworzy po jednym obiekcie tej klasy dla kadego wiersza kolekcji danych testowych. W tej
sytuacji musimy zdefiniowa zmienne skadowe reprezentujce te wartoci, a take konstruk-
tor publiczny odpowiedzialny za ich inicjalizacj, aby framework JUnit móg tworzy kolejne
obiekty z waciwymi 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;
}

Moemy teraz przetestowa nasz kod z wykorzystaniem tych wartoci:

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

Kiedy uruchomimy te testy jednostkowe, okae si, e nasze testy zostan wykonane wielokrot-
nie — osobno dla kadego wiersza uytych 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 pamita o moliwoci umieszczania wielu testów jednostkowych w jednej sparame-
tryzowanej klasie testów (podobnie jak w przypadku tradycyjnych klas testów jednostkowych).
Kada metoda testu jednostkowego bdzie wywoywana osobno dla kadego wiersza danych
testowych.

10.7. Stosowanie metody assertThat()

i biblioteki Hamcrest

We frameworku JUnit 4.4 wprowadzono nowe pojcie dla wyrae asercji, aby intencje
programistów byy bardziej zrozumiae i atwiejsze w interpretacji. Opisywana koncepcja,
której oryginalnym pomysodawc by Joe Walnes

, sprowadza si do stosowania metody

assertThat

cznie ze zbiorem wyrae dopasowujcych (okrelanych te mianem ogranicze

lub predykatów), co w wielu przypadkach znacznie poprawia czytelno testów. Na przykad
ponisza 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));
}
}

Wywoanie

assertThat(calculatedTax, is(0.0))

jest duo bardziej czytelne ni wywoanie

assertEquals(calculatedTax, 0.0, 0.0)

, cho oczywicie wszystko zaley od osobistych

preferencji programisty. Sam uwaam wywoanie w tej formie za bardziej naturalne. Jest krótsze
i nie zmusza nas do podwiadomego tumaczenia samego wyraenia

assertsEquals

na zdanie

„no dobrze, zatem wyznaczany podatek musi by równy zero”. W przypadku pierwszego
wyraenia nasz mózg od razu dochodzi do interpretacji: „wietnie, zakadamy, e podatek
bdzie zerowy”, co zajmuje nieporównanie mniej czasu.

Bardziej czytelne testy oznaczaj te wiksz niezawodno i atwo w utrzymaniu. Jeli
interpretacja naszych testów jest prostsza, duo atwiej i szybciej moemy stwierdzi , czy
s prawidowe.

Wyraenie dopasowujce

equalTo

(lub

, czyli jego skrócona forma) moe by z powodzeniem

wykorzystywane w roli bardziej czytelnej wersji metody

assertEquals

String result = "czerwony";

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

Opisywane wyraenia mona te czy w bardziej zoone zadania. Moemy na przykad
wykorzysta wyraenie dopasowujce

anyOf

do sprawdzenia, czy zmienna

color

zawiera

acuch

"czerwony"

"zielony"

lub

"niebieski"

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

W razie koniecznoci moemy skojarzy z naszym testem opis, który dodatkowo uatwi jego
interpretacj:

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

Powysze wyraenie spowoduje wygenerowanie komunikatu o bdzie uzupenionego o nasz
opis:

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

Moemy te uy intuicyjnego wyraenia dopasowujcego

not

, które neguje wszystkie pozostae

wyraenia dopasowujce:

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

Te nowe metody w rzeczywistoci pochodz z zewntrznej biblioteki nazwanej Hamcrest.
Wachlarz wyrae dopasowujcych oferowanych w ramach frameworku JUnit 4.4 jest do
ograniczony. Mona jednak ten zbiór uzupeni , doczajc do realizowanego projektu bibliotek
hamcrest-all.jar. Wspomniany interfejs API mona pobra z witryny internetowej biblioteki
Hamcrest

. Jeli korzystamy z Mavena, moemy 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 zastpujemy statyczne wyraenie importujce bibliotek

org.hamcrest.Core

´Matchers

wyraeniem importujcym bardziej rozbudowan bibliotek

org.hamcrest.

´Matchers

. Prezentowane rozwizanie daje nam dostp do znacznie bogatszego zbioru

wyrae dopasowujcych. Niektóre z tych dodatkowych wyrae zostan omówione w dal-
szej czci tego podrozdziau.

Do najbardziej interesujcych wyrae dopasowujcych nale mechanizmy upraszczajce
operacje na kolekcjach. Na przykad wyraenie

hasItem

mona z powodzeniem wykorzystywa

do przeszukiwania zawartoci struktury typu

List

(w przypadku struktur tablicowych ten sam

efekt mona uzyska , stosujc wyraenie

hasItemInArray

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

Wyrae dopasowujcych

hasItem

hasItemInArray

mona uywa do konstruowania

skomplikowanych testów operujcych na listach wartoci. Poniej przedstawiono przykad
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, wyraenie dopasowujce

isIn

umoliwia nam sprawdzanie, czy interesujca nas

lista zawiera konkretny obiekt:

assertThat(20, isIn(ages));

Obsuga kolekcji nie ogranicza si tylko do list. Wyrae dopasowujcych

hasKey

hasValue

mona uywa do sprawdzania, czy dana mapa (struktura typu

Map

) zawiera odpowiednio

interesujcy nas klucz lub warto :

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

Istnieje nawet wyraenie dopasowujce

hasProperty

, które umoliwia nam testowanie wa-

ciwoci obiektów:

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

W tym podrozdziale dokonalimy przegldu zaledwie kilku moliwych zastosowa tego rodzaju
wyrae. Inne dostpne rozwizania mona znale w dokumentacji najnowszej wersji tego
API. Wyraenia dopasowujce w tej formie umoliwiaj 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 uwaan za element eksperymentalny) funkcj
wprowadzon we frameworku 4.4 jest pojcie teorii (przypuszczenia). Teoria wyraa ogólne
przekonanie, które pozostaje prawdziwe dla wielu (by moe nieskoczenie wielu) zbiorów
danych. Wszelkie ograniczenia zbiorów danych, dla których stosuje si dan teori, okrela
si mianem zaoe.

Programista w pierwszej kolejnoci definiuje zbiór punktów danych na potrzeby testów swojej
teorii. Punkt danych jest (z reguy staym) elementem danych testowych identyfikowanym
przez adnotacj

@DataPoint

. Alternatywnym rozwizaniem jest uycie zautomatyzowanych

narzdzi analizujcych nasz kod i automatycznie tworzcych zbiory danych wzmacniajcych
lub obalajcych teori. Na przykad poniej definiujemy prawidowe wartoci dla lat 2007
i 2008:

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

Moemy teraz uy 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 wykorzystujcy teori, naley w miejsce standardowej adnotacji

@Test

uy adnotacji

@Theory

. Teoria jest zwyk metod otrzymujc na wejciu pewn liczb

parametrów. Framework sam okrela, których punktów danych naley uy dla poszczególnych
parametrów naszych metod testowych, na podstawie ich typów. Kady punkt danych jest
przekazywany za porednictwem kadego parametru tego samego typu. Takie rozwizanie
stwarza pewne problemy, jeli stosujemy wiele parametrów tego samego typu. Jak si za chwil
przekonamy, do ograniczania moliwych wartoci przypisywanych poszczególnym parametrom
su tzw. zaoenia.

Kolejnym krokiem jest zdefiniowanie wspomnianych zaoe za pomoc adnotacji

@assumeThat

Stosujc zaoenia w ramach przypadku testowego wykorzystujcego teori, moemy atwo
ograniczy dane testowe, które bd uywane podczas wykonywania tego przypadku testowego.
W poniszym przykadzie ograniczamy zakres testów naszego przypadku do roku 2007
i dochodów z przedziau od 0 do 14 tys. zotych:

assumeThat(year, is(2007));

oraz

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

Modu rozszerzenia JUnitRunner wykonuje dany test dla wszystkich moliwych kombinacji
punktów danych zgodnych z zaoeniami, czyli w tym przypadku dla kombinacji staej

YEAR_2007

i staych

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 nastpujce 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 wartoci typu

double

. W prawdziwej aplikacji biznesowej

prawdopodobnie naleaoby uy typu gwarantujcego wiksz precyzj operacji na danych
pieninych, czyli typu

BigDecimal

lub dedykowanej klasy

Money

W razie niepowodzenia tego testu zostanie wywietlony opisowy komunikat obejmujcy
szczegóy punktów danych, które doprowadziy do bdu:

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

Moemy teraz doda do tego testu inne teorie, aby zweryfikowa inne podzbiory naszych
danych testowych. Moliwy zbiór punktów danych (po zastosowaniu zaoe) jest stosowany
osobno dla kadej 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 obsuguje 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. Mona nawet czy testy frameworków JUnit 3
i JUnit 4 w ramach tej samej aplikacji. Testy jednostkowe wykonujemy dokadnie tak samo jak
pozostae 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 moduu rozszerzenia Surefire, obejmujcy
zebrane wyniki wszystkich naszych testów. Takie rozwizanie jest bardzo korzystne w sytuacji,
gdy chcemy korzysta z unikatowych funkcji frameworku JUnit 4 w normalnych testach jednost-
kowych i jednoczenie zachowa moliwo stosowania kilku doskonaych bibliotek testujcych
napisanych dla frameworku JUnit 3, na przykad ze StrutsTestCase’a (patrz rozdzia 19.),
frameworku testowego Spring MVC lub rozszerzenia DBUnit.

10.10. Stosowanie frameworku JUnit 4

w projektach Anta

Obsuga frameworku JUnit 4 w wersjach Anta sprzed wydania 1.7.0 pozostawiaa wiele
do yczenia. Okazuje si jednak, e poczwszy od wspomnianej wersji, testy frameworku JUnit 4
s w peni obsugiwane i atwe w konfiguracji. W tym podrozdziale przeanalizujemy kroki
skadajce si na procesy konfiguracji, kompilacji i wykonywania testów JUnit 4 za pored-
nictwem Anta.

Aby nasze rozwaania byy kompletne, przeanalizujemy cay skrypt kompilacji Anta. Wiksza
cz tego pliku powinna by zrozumiaa dla programistów obeznanych z Antem (patrz
rozdzia 1.). W pierwszej czci tego pliku definiujemy katalogi projektu i typowe zadania:

424

Rozdzia 10. Testowanie kodu z wykorzystaniem frameworku JUnit

Nastpnie musimy zdefiniowa zadanie odpowiedzialne za kompilacj naszego kodu Javy:

Take w tym przypadku mamy do czynienia ze standardowymi konstrukcjami skryptu kom-
pilacji — ograniczamy si do kompilowania kodu Javy za pomoc standardowego zadania

<javac>

. Bardziej interesujce elementy mona znale w kolejnym fragmencie tego pliku, gdzie

ustawiamy ciek do klas wskazujc na plik JAR frameworku JUnit 4.1 i skompilowane
klasy naszej aplikacji. Obie cieki wykorzystujemy nastpnie 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 mona z powo-
dzeniem stosowa cznie (bez ryzyka wystpowania konfliktów) w ramach tego samego
projektu:

Jestemy wreszcie gotowi do waciwego uruchomienia naszych testów jednostkowych. Ant
1.7.0 oferuje nowe, udoskonalone zadanie stworzone z myl o obsudze zarówno testów
frameworku JUnit 3, jak i testów frameworku JUnit 4. Typowe zadanie testu frameworku
JUnit uyte w skrypcie kompilacji Anta 1.7.0 ma nastpujc posta :

10.10. Stosowanie frameworku JUnit 4 w projektach Anta

_ 425

Pierwszym interesujcym elementem (przynajmniej z perspektywy uytkowników frameworku
JUnit korzystajcych ze starszych wersji Anta) jest cieka do klas. Wanie za porednictwem
tego elementu sygnalizujemy Antowi, gdzie naley szuka pliku JAR frameworku JUnit 4.
Warto o tym wspomnie cho by dlatego, e a do wydania Anta 1.6.5 uytkownicy zaintere-
sowani korzystaniem z zadania frameworku JUnit musieli umieszcza kopi pliku junit.jar
w katalogu lib Anta. Mimo e przytoczone wymaganie byo udokumentowane w podrczniku
uytkownika Anta i oficjalnie zadeklarowane jako zgodne z zamierzeniami twórców tego
narzdzia, w najlepszym razie mona je uzna za niefortunne. Poczwszy od Anta 1.7.0,
wystarczy zadeklarowa plik JAR frameworku JUnit 4 w zagniedonym elemencie

<class

´path>

W kolejnej czci naley zdefiniowa list obiektów formatujcych. Wyniki testów mona
generowa w wielu rónych formatach — opcja

plain

oznacza zwyke pliki testowe, natomiast

opcja

xml

oznacza bardziej szczegóowe raporty w popularnym formacie XML.

Za waciwe wykonywanie testów odpowiada element

, który uruchamia wszystkie

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

Po wywoaniu tego celu powinnimy otrzyma dane wynikowe podobne do poniszych:

$ 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 narzdziem wyjtkowo elastycznym — za jego porednictwem

moemy midzy 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 najczciej wykonuje si caymi pakietami za pomoc elementu

Okazuje si jednak, e mona te testy wykonywa take pojedynczo z uyciem elementu

<test>

Wywoanie 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

Moemy te zdecydowa o wyczeniu 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
kadej procedury przeprowadzania testów jednostkowych. Niektóre rodzaje testów — w tym
testy obcieniowe, integracyjne i wydajnociowe — mog by do czasochonne, zatem ich

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

_ 427

wykonywanie po kadej kompilacji aplikacji bywa kopotliwe. Testy jednostkowe powinny
by krótkie i treciwe. Testy wymagajce wicej czasu i mocy obliczeniowej procesora naley
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 reguy
odpowiada serwer integracji.

Jednym ze sposobów realizacji tego celu jest uycie atrybutu

elementu

. Atrybut

okrela waciwo , której ustawienie jest warunkiem wykonania wskazanych testów

jednostkowych; w przeciwnym przypadku testy zostan po prostu pominite.

Poniszy cel zostanie przetworzony, pod warunkiem e bdzie ustawiona waciwo

perf

´tests

Jeli waciwo

perftests

nie zostanie ustawiona, testy wydajnociowe nigdy nie zostan

wykonane, nawet jeli nasz cel zostanie wywoany wprost (wedug nazwy):

$ ant runperftests
Buildfile: build.xml

init:

compile:

compiletests:

runperftests:

BUILD SUCCESSFUL
Total time: 1 second

Jeli jednak ustawimy waciwo

perftests

(przypisujc jej dowoln warto ), testy wydaj-

nociowe zostan prawidowo wykonane. Waciwoci mona ustawia na wiele rónych
sposobów: bezporednio w pliku kompilacji, w pliku waciwoci 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 waciwoci w tej formie (ustawianej z poziomu wiersza polece)
jest stosowanie naszego zadania na serwerze integracyjnym — testy wydajnociowe i integracyj-
ne z reguy wykonywane s tylko na tym serwerze, nie na komputerach programistów.

Stosujc t technik, nie moemy zapomina o koniecznoci wyczenia tych testów z gównego
testu jednostkowego za pomoc omówionego wczeniej elementu

10.12. Testy integracyjne

Testy jednostkowe nie tylko powinny by krótkie i treciwe, ale te powinny generowa intere-
sujce nas wyniki moliwie szybko. Testy jednostkowe nie powinny korzysta z takich zasobów
zewntrznych jak bazy danych czy frameworki aplikacji internetowych. Wanie dlatego czsto
stosuje si interfejsy, obiekty zastpcze i rozmaite inne techniki gwarantujce, e kady kom-
ponent bdzie testowany niezalenie od pozostaych.

Prdzej czy póniej bdziemy jednak chcieli sprawdzi , jak nasze komponenty ze sob wspópra-
cuj. Weryfikacj tego aspektu projektu okrela si mianem testów integracyjnych. Na tym
etapie moemy sprawdzi obiekty DAO frameworku Hibernate, korzystajc z prawdziwej
bazy danych (zamiast z bazy wbudowanej), wykona zapytania pokonujce ca drog
od warstwy usug do bazy danych i z powrotem lub zasymulowa dziaanie przegldarki
uytkownika z uyciem specjalnego narzdzia, na przykad Selenium. Mona te sprawdzi ,
jak nasza aplikacja radzi sobie z duym obcieniem i czy jest waciwie przygotowana
do obsugi wielu jednoczesnych da. Tego rodzaju testy s oczywicie bardzo wane, jednak
z reguy okazuj si zdecydowanie zbyt czasochonne, aby programici mogli je kadorazowo
wykonywa wraz ze zwykymi testami jednostkowymi. Zbyt wolne testy jednostkowe zniech-
caj programistów do testowania, zatem powinnimy znale skuteczny sposób wyodrbnienia
szybkich testów jednostkowych z grupy wolnych testów integracyjnych.

W Mavenie mona tak skonfigurowa modu rozszerzenia Surefire, aby sam okrela, które
testy naley 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 poniszym przykadzie nazwy testów integracyjnych kocz si

wyraeniem

IntegrationTest

. Mamy wic do czynienia z wyjtkowo prost konwencj

— w razie potrzeby mona oczywicie zdefiniowa alternatywn, wasn konwencj. Poniszy
plik konfiguracyjny wycza testy integracyjne ze zbioru zwykych testów jednostkowych
(skojarzonych z faz

test

) i kojarzy je z odrbn faz

integration-test

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

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 wydajnociowe, wystarczy wywoa faz testów integracyjnych:

$ mvn integration-test

10.13. Korzystanie z frameworku JUnit 4

w rodowisku Eclipse

Korzystanie z porednictwa 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
mona wywoywa w dokadnie taki sam sposób jak testy frameworku JUnit 3, czyli za pomoc
opcji Run As… i JUnit Test. Jeli korzystamy z asercji Javy 5, powinnimy dodatkowo uy opcji

-ea

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

razie nasze asercje zostan po prostu zignorowane.

Co wicej, Eclipse prawidowo obsuguje te takie mechanizmy frameworku JUnit 4 jak testy
sparametryzowane (patrz rysunek 10.1).

rodowisko Eclipse dodatkowo oferuje moliwo tworzenia nowych przypadków testowych
frameworku JUnit 4 za pomoc opcji New… i JUnit Unit Test (patrz rysunek 10.3). Za porednic-
twem tego okna dialogowego moemy tworzy klasy testów frameworków JUnit 3.8 lub JUnit 4
(oba typy testów jednostkowych mona stosowa jednoczenie w ramach tego samego projektu).

430

Rozdzia 10. Testowanie kodu z wykorzystaniem frameworku JUnit

Rysunek 10.1. Konfigurowanie testów frameworku JUnit 4, aby korzystay z operacji asercji

Rysunek 10.2. Uruchamianie testów frameworku JUnit 4 z poziomu rodowiska Eclipse

10.13. Korzystanie z frameworku JUnit 4 w rodowisku Eclipse

_ 431

Rysunek 10.3. Tworzenie w rodowisku Eclipse nowego testu frameworku JUnit 4

Wyszukiwarka

Podobne podstrony:
informatyka java praktyczne narzedzia john ferguson smart ebook
Controlling w firmie Praktyczne narzedzia jak poprawic plynnosc finansowa w przedsiebiorstwie e
praktyczny kurs java NX2M5DXARLEHY6NHXOS5FJHKLI6ACRLQQSDRS2Q
Praktyczny kurs Java
Praktyczny kurs Java Wydanie II pkjav2
Java Script ćwiczenia praktyczne
praktyczny sposób wykorzystania narzedzi pr, marketing i reklama, perswazja, reklama, marketing, jęz
Java cwiczenia praktyczne
Praktyczny kurs Java pkjava

więcej podobnych podstron