< >.

SEMINARSKI RAD
Predmet: Dokumentovanje softverskih projekata Tema: Testiranje softvera, JUNIT

Mentor: eljko Jovanovi

Student: Nikola Ostoji, 885/2012

aak, 2013. godine

SADRAJ
1.UVOD...................................................................................................................................... 3 2.TEST DOKUMENTACIJA .................................................................................................... 4 3.TESTIRANJE SOFTVERA .................................................................................................... 7 3.1 Faze testiranja softvera ..................................................................................................... 7 3.2 Unit testovi ....................................................................................................................... 9 3.3 Automatizovani alati za testiranje .................................................................................... 9 3.3.1 Junit ......................................................................................................................... 10 3.4 Osnovni ciklus testiranja ................................................................................................ 12 4.TESTIRANJE SOFTVERA U NETBEANS IDE RAZVOJNOM OKRUENJU .............. 15 4.1 Kreiranje novog projekta i njegovo testiranje ................................................................ 15 5.ZAKLJUAK........................................................................................................................ 25 6.LITERATURA ...................................................................................................................... 26

1.
UVOD
Ako biste se preraunali na ta troite koliko vremena tokom programiranja, shvatili biste da skoro najmanji deo vremena otpada na samo pisanje kda. Jedan deo vremena provodite u planiranju i projektovanju kda koji bi trebalo napisati, drugi deo u dizajniranju, ali najvei deo odlazi na debagovanje kda i pokuavanje da shvatite ta zapravo ne radi. Otklanjanje greke, opet oduzima jako malo vremena, dok najvei deo otpada na samo pronalaenje greke. Kako skratiti ovo neproduktivno vreme pronalaenja greke? Najjednostavniji odgovor bi bio: testiranjem.

2.
TEST DOKUMENTACIJA
Sistematino i sveobuhvatno testiranje je glavni faktor koji doprinosi kvalitetu informacionih sistema. Meutim, odgovarajue testiranje esto nije izvreno to dovodi do veeg broja softverskih nedostataka koji utiu na objektivan i subjektivan kvalitet softvera, to dovodi do dodatnog troenja vremena i novca na dorade i trokove odravanja. Na primer, softver za upotrebu u klinikom okruenju mora biti testiran. Bez obzira da li testiramo malu kunu aplikaciju ili neki medicinski ureaj sa velikim softverom ili firmware-om, zahtevi za odgovarajuom dokumentacijom, planiranjem i izvetavanjem su isti. Test dokumentacija je vitalni element koji podie eksperientalne aktivnosti na nivo odgovarajueg testa. ak i u sluaju da je neki softver koji testiramo dobar, to je bezvredno ako nije dokumentovano. Kako test dokumentacija treba da izgleda je navedeno u IEEE 829 standardu. IEEE standard omoguava skaliranje seta dokumenata do odreenog stepena. IEEE standard za izradu test dokumentacije opisuje osnovni set dokumenata za testiranje softvera. On ne precizira neke posebne tehnike za testiranje niti zahteva da sva dokumentacija definisana unutar standarda mora da bude koriena. Meutim, ono to ovaj standar obezbeuje je: a) pruanje referentnog okvira za razliite aktere koji uestvuju u izradi softvera, b) da poslui kao provera za razne vrste tema koje treba razmotriti prilikom testiranja softvera i c) olakava upravljanje procesom testiranja softvera. Slede kratke definicije sakog dokumenta koji je definisan u IEEE standardu:

Test Plan Ovaj plan opisuje obim, pristup, resurse i raspored aktivnosti u toku testiranja. On identifikuje koje stavke su u fazi testiranja a koje nisu. On takoe na visokom nivou opisuje pristup koji treba primeniti za testiranje svake glavne gupe karakteristika. Na kraju, on sadri i

odreuje raspored aktivnosti koje treba da budu sprovedene u toku testiranja. Ovo je osnovni menadment dokument koji se koristi za praenje projekta do kraja njegove realizacije. Test Design specifikacija Ovaj razradni test je deo Test Plana. Svaka funkcija koja treba da bude testirana i njoj pridrueni testovi su identifikovani. Treba da budu identifikovani zahtevi vezani za svaki test kao i da budu navedeni kriterijumi za utvrivanje statusa proao/pao.

Test Case specifikacija Za svaki test identifikovan Test Design specifikacijom definisan je jedinstven Test Case. Postoji veliki broj potrebnih aspekata Test Case specifikacije ali najvaniji sa take gledita test developera su: potrebe okruenja i njegovo podeavanje, ulazne i izlazne specifikacije. Izlazne specifikacije su najvaniji aspekt testiranja jer test developer mora da zna kako deo softvera treba da postupa u skladu sa odreenim nizom okolnosti. To podrazumeva postojanje precizne up to date specifikacije i dobro poznavanje .

Test Procedure specifikacija Ovim se definiu potrebni koraci za izvravanje skupa jedinstvenih Test Case sluajeva. Ponekad e se ista procedura primenjivati na vie Test Case sluajeva. Test Item Transmittal izvetaj Ovim su identifikovane stavke softvera koje su date na testiranje. Ovo je najee dato od strane programera koji razvija softver koji se testira i obino identifikuje posebnu ready for test verziju programa.

Test Log Ovo je hronoloki dnevnik relevantnih detalja o izvravanju testova. Obino sadri datum kada je zapoeto testiranje odreene verzije softvera a zatim sumirane rezultate testiranja i probleme koji treba da se ree. Test Incident izvetaj To je ono to se obino naziva izvetaj o grekama i sadri informacije o softveskom neuspehu neke vrste. Tipine informacije koje treba da budu ukljuene su broj verzije softvera, sve znaajne informacije o okruenju, ulazi, oekivani rezultati i stvarni rezultati. Takoe sadri i informacije o tome kako je neka greka nastala. 5

Test Summary izvetaj Ovo je pregled svih rezultata i aktivnosti tokom testiranja softvera. On treba da sadri sveobuhvatnu procenu o testiranju softvera, ukupnu procenu o testiranju svake stavke, ogranienja postupka testiranja i potpunost izvrenog testiranja.

Slika 2.1 Test dokumentacija Veina dokumenata koji su definisani iznad nisu potrebni sve vreme ivotnog veka softvera. Neki od dokumenata se mogu kombinovati sa drugima ili ak potpuno eliminisati. Grupa test programera moda nije dovoljno velika kako bi bili u stanju da kreiraju formalnu dokumentaciju kao to je Test Transmittal izvetaj ili Test Log. Automatizacija moe zameniti mnoge aspekte ovog skupa dokumenata, na primer, Test Incident izvetaj se danas obino sprovodi u automatizovanim sistemima za praenje greaka. Bez obzira kakve su potrebe projekta, kompletan Test Plan i Test Summary izvetaj su potrebni za uspeno kompletiranje skoro svih test projekata.

3.
TESTIRANJE SOFTVERA
Mnogi programeri posmatraju testiranje kao dokaz da njihovi programi ispravno rade. Ali, zapravo, programi se testiraju da bi se dokazalo postojanje greaka. Poto je cilj da se greka otkrije, test se smatra uspenim samo ako se greka otkrije ili ako doe do otkaza u toku testiranja. Test Driven Development je tehnika razvoja softvera koja podrazumeva esto testiranje napisanog kda. Test se pie pre kda, a nakon toga se pie izvorni kd koji treba da zadovolji test. Refaktorisanjem se taj kd dalje preiava i pojednostavljuje, ali osnovno je da test koji se jednom verifikovao mora da se iznova verifikuje, pri svim sledeim izmenama. To je tzv. Jedinino testiranja (unit test). Postoje i funkcionalni testovi kroz test primere, odnosno test sluajeve (test case) koje izvodi sam klijent. Testovi korisnosti i korisnikog interfejsa se takoe izvode kod klijenta. TDD strategija je poela da privlai panju poetkom 2000-te, kao aspekt Ekstremnog programiranja. Postoje razni aspekti TDD razvoja, kao to su na primer principi Keep It Simple, Stupid (KISS), i You Aint Gonna Need It (YAGNI). Fokusirajui se samo na kd koji mora da zadovolji test, dizajn moe biti jasniji i istiji nego to se to obino moe postii nekom drugom metodom. TDD zahteva da programeri prvo napiu test case koji ne prolazi, kako bi bili sigurni da test zaista radi ispravno i da moe da uhvati greku. 3.1 Faze testiranja softvera Kada se razvija veliki sistem, testiranje zahteva vie faza.

Slika 3.1 Faze testiranja softvera Prvo se zasebno testira svaka programska komponenta, nezavisno od ostalih delova sistema. Takvo testiranje modula (jedinino testiranje, unit test) proverava da li pojedinane komponente ispravno funkcioniu sa svim oekivanim tipovima ulaza, u skladu sa dizajnom komponente. Kada se zavri jedinino testiranje skupa komponenti, sledi provera da li su interfejsi izmeu komponenti pravilno definisani i realizovani. Integraciono testiranje je postupak provere da li sistemske komponente sarauju kao to je opisano u specifikacijama dizajna sistema i programa. Funkcionalnim testiranjem se proverava da li integrisani sistem zaista izvrava funkcije opisane u specifikaciji zahteva. Kao rezultat dobija se funkcionalni softverski sistem. Funkcionalni test predstavlja poreenje sistema koji se gradi sa funkcijama zahteva kupca. Testiranjem performanse sistem se poredi sa ostatkom hardverskih i softverskih zahteva. Kada se to testiranje uspeno obavi u stvarnom radnom okruenju kupca, dobija se validiran sistem. U sledeem koraku, zajedno sa kupcem se obavlja zavrni test prihvatanja (acceptance test), u kojem se proverava usklaenost sistema sa opisom zahteva kupca. Kada se obavi zavrni test, prihvaeni sistem se instalira u okruenje u kome e se koristiti. Konani instalacioni test potvruje da li sistem i dalje ispravno funkcionie. 8

3.2 Unit testovi Unit test moe da se definie kao test jedne izolovane komponente sa ponavljanjem. Test znaci da se proveri da li je neto ispravno. Da bi test bi validan potrebno je da proverimo da ako je poetno stanje A krajnje stanje e biti B. Unit test je izolovani test to znai da se komponenta koja se testira tretira u izolaciji a ne da se test izvodi u vezi sa ostalim komponentama koje se ne testiraju. Ovo ini razliku izmeu unit testiranja i integracionih testiranja. Test je potrebno da se izvodi sa ponavljanjem zbog toga to moe da doe do razlika u rezultatima pri jednom izvravanju komponente i pri vie ponavljanja. Dakle, ako oekujemo da e komponenta koja se testira iz stanja A posle izvravanja dati rezultat B onda to mora da bude sluaj i pri ponavljanju izvravanja stim to moe da postoji i dinamika kretanja stanja komponente sve dok je ona tano predefinisana. Jedinino testiranje treba vriti u kontrolisanom okruenju tako da tim za testiranje moe komponenti koja se testira da predaje unapred definisan skup podataka, i da posmatra izlazne akcije i rezultate. Takoe, tim za testiranje proverava unutranju strukturu podataka, logiku i granine uslove za ulazne i izlazne podatke. Test se sastoji od etiri faze: Priprema: priprema okruenja za testiranje i definisanje oekivanih rezultata Izvravanje: pokretanje testa Validacija: poreenje dobijenih rezultata sa predefinisanim rezultatima ienje: postavljanje okruenja onako kako je bilo pre testiranja 3.3 Automatizovani alati za testiranje Dananji softverski sistemi su veoma velike i kompleksne aplikacije. Zato je vano koristiti alate za automatizovano izvravanje testova, jer omoguavaju veoma veliki broj sluajeva za testiranje, bez kojih sistem bi bio povrno testiran. Alati za izvravanje testova mogu da se integriu sa drugim alatima radi izgradnje okruenja za sveobuhvatno testiranje. Alati se esto povezuju sa bazom podataka za testiranje, mernim alatima, alatima za analizu koda, editorima teksta i alatima za simulaciju i modelovanje da bi se automatizovao to je mogue vei deo procesa testiranja. Meutim, utvrivanje da greka postoji ne znai da je greka i pronaena. Zato e automatizovano testiranje zahtevati i ljudski trud u traenju izvora za nastali problem.

3.3.1 Junit Junit je open source okvir za testiranje, napisan za Java programski jezik. Meutim, postao je toliko popularan da je preveden i prilagoen za korienje u drugim programskim jezicima: C# (NUnit), Python (PyUnit), Fortran (fUnit), C++ (CPPUnit). Pomou ovih alata, mogue je automatizovano izvravati jedinine testove iz IDE razvojnog okruenja. Junit je integrisan u mnoga razvojna okruenja (Eclipse, NetBeans, JBuilder, JDeveloper, Sun Java Enterprise Studio) . Prednost integrisanog Junita je u tome to je olakan rad pri testiranju koda jer se vri preko bogatog grafikog interfejsa, a mnoge operacije, kao to je na primer kompajliranje testova i izvravanje testova, su automatizovane. Junit je nastao na osnovu originalnog okruenja za testiranje u SmallTalku, koje je napisao Kent Beck (SUnit). Nakon toga su Kent Beck i Erich Gamma napravili Junit za J2SE i J2EE platformu. Junit omoguava kreiranje testova za bilo koju Java klasu, odnosno za bilo koju njenu metodu.

Slika 3.2 Junit testiranje Svaka Java klasa moe da se testira, ali ne moraju sve. Kada se testira klasa, koristi se jedna ili vie test procedura. Test procedura je nezavisna od klase, pa moe ista test procedura da se primeni na razliitim klasama. Kad se test procedura primeni na odreenu klasu, onda 10

nastaje konkretan test ili vie konkretnih testova. Konkretan test je u vezi sa samo jednom procedurom i sa samo jednom klasom. U Junit-u, svaki konkretan test moe da se implementira kao jedna test metoda. Junit test metoda je Java metod ije ime poinje sa test (na primer: testIzracunajRacun) i pripada Junit test klasi (TestCase). Svaka test klasa moe da ima jednu ili vie test metoda, a test metoda moe da pripada samo jednoj test klasi. Svaka test klasa odgovara samo jednoj Java klasi, odnosno onoj koja se testira. Test klase mogu da se organizuju u vee celine skupove testova (TestSuite). Svaki skup sadri jednu ili vie test klasa, a moe da sadri i jedan ili vie drugih skupova. Na taj nain se moe pozvati izvravanje svih testova, nekih testova koji pripadaju odreenom skupu ili pojedinanih testova. JUnit moe da se koristi sve vreme tokom razvoja softvera, jer se prvo pie test, a posle toga kodira, odnosno piu se jedinini testovi kojima se testira svaka metoda. Korienjem JUnita kreira se baza testova, a testovi se izvode organizovano i detaljno. Tako se stvara sigurnost da sve to je implementirano je potpuno funkcionalno. Prednosti testiranja koda korienjem JUnit-a su sledee: JUnit je veoma jednostavan za korienje, a testovi se piu veoma lako. uva se baza testova, tako da se moe menjati, dopuniti i ponovo izvravati, to je vano, jer se moe proveriti da li je program zadrao svu funkcionalnost koju je imao ranije, odnosno vri se regresiono testiranje (izvravaju se svi postojei testovi) i da li novi deo funkcionie kako bi trebalo (napiu se i dodaju novi testovi u bazu i izvre). Pri izvravanju, testovi napisani u JUnit-u, vre automatsku proveru rezultata i prijavljuju greke. Testovi se mogu organizovati u hijerarhijski povezane celine, to je vano kada je broj testova relativno veliki. Svaki programer moe lako da naui da pie testove, jer se piu u Javi u formi obinih metoda. Junit se definie nasleivanjem junit.framevork.TestCase klase. Ova klasa obezbeuje niz metoda koje se koriste u navedene etiri faze testiranja. Kada kreiramo Test Case potrebno je da imamo jednu ili vie test metoda. Test metoda je standardana javina metoda stim to je potrebno da bude deklarisana kao javna (public),

11

mora da vraa tip void i mora da poinje sa test u nazivu. Pored test metode koja je obavezna postoje i opcione metode: public void setUp(); public void tearDown(); SetUp se izvrava pre svake test metode a tearDown posle izvravanja svake. Izvravanje obe ove metode je zagarantovano. Pored ove dve postoje i druge dve opcione metode: public void beforeClass(); public void afterClass(); One se, za razliku od setUp i tearDown izvravaju jednom na poetku izvravanja test case-a(beforeClass) i na kraju (afterClass). Junit koristi takozvane assertion metode za testiranje. Postoje razne: assertNull(Object x) proverava da li je objekat x null assertNotNull(Object x) proverava da li objekat x nije null assertTrue(boolean x) proverava da li je iskay x true odnosno taan assertFalse(boolean x) proverava da li je iskaz x false odnosno netaan assertEqual(Object x, Object y) proverava jednakost objekata koristeei equal() metod assertSame(Object x, Object y) proverava jednakost objekata koristei operator == 3.4 Osnovni ciklus testiranja Svaki sluaj testiranja prati sledei osnovni ciklus: petlja kroz metode za testiranje: { setUp(); // izvrava se logika za inicijalizaciju doTests(); // izvrava se metod za testiranje tearDown(); // izvrava se logika za zavretak testa } Svaki jedinini test treba da sledi sledee korake: 1. Treba da bude potklasa klase junit.framework.TestCase. 2. U metodu setUp() treba dodati neki kd za podeavanje.

12

3. Treba definisati test. Svaki test treba da kao povratni tip ima void (odnosno da ne vraa nita), a njegovo ime treba da poinje sa test, na primer testMaxSize(), test ConvertAmount(), testAdd() itd. 4. Resurse koje smo zauzeli preko funkcije setUp() osloboditi preklapanjem metoda tearDown(). 5. Definisati skup testova, ako je potrebno da se testovi izvravaju zajedno. TestCase klasa je osnovna klasa za testiranje. Sadri pomone metode za kreiranje i pokretanje testova. Kada se izvri TestCase, automatski se pokreu sve metode klase koja poinje sa test. Junit koristi refleksiju da odredi koje testove da pokrene, olakavajui na taj nain dodavanje novih metoda za testiranje u postojei sluaj testiranja. Refleksija je proces kojim program moe da uoi i modifikuje svoju strukturu i ponaanje. TestCase ukljuuje i metode kojima se implementira fixture. Fixture je artifakt u odnosu na koga se pokreu testovi. To nije neto to se testira, nego sredstvo (resource) koje je potrebno da bi se test pokrenuo. Na primer, ako se testira pristup bazi podataka (database access), potreban je Connection objekat da bi se pristupilo tabelama baze. Ne testira se sama konekcija, nego je konekcija potrebna pre nego to se napie ostatak testa. Sluaj testiranja e ukljuiti Connection kao fixture. Metod setUp() framework automatski poziva pre nego to se pokrene svaki test. Slino, tearDown() metod se poziva nakon to se pokrene svaki test. Na primer, setUp() uspostavlja konekciju na bazu, a tearDown() zatvara tu konekciju. Primer 1 : Testiranje klase SimpleTest
package junit.samples; import junit.framework.*; public class SimpleTest extends TestCase{ protected int value1; protected int value2; public SimpleTest(String name) {super (name);} protected void setUp(){ value1=2; value2=3; } public static TestSuite(){ return new TestSuite(SimpleTest.class); } public void testAdd(){ double result=value1+value2; // forced failure result ==5 assertTrue(result==6); } public void testDivideByZero(){ int zero=0; int result=8/zero; } public void testEquals(){

13

assertEquals(12, 12); assertEquals(12L, 12L); assertEquals(new Long(12), new Long(12)); assertEquals("Size", 12, 13); assertEquals("Capacity", 12.0, 11.99, 0.0); } }

U datoteci SimpleTest.java nalazi se sledee: Referencira se biblioteka iz okvira JUnit; Daje se ime klasi za testiranje (SimpleTest). Ta klasa treba da bude potklasa klase TestCase; Vri se preklapanje metode setUp() i podeavanje inicijalne vrednosti za promenljive u testu; Vri se preklapanje osnovnog skupa testova i vraa nova instanca za taj sluaj testiranja; Klasa za testiranje implementira test "dodavanje brojeva", testAdd(). Generie se poruka ako sabiranje ne uspe. Ovde se javlja greka radi demonstracije. Pravi se izuzetak, tako to se u metodi testDivideByZero() vri deljenje sa nulom. Nastaje greka, to je suprotno u odnosu na neuspeh. Metoda testEquals() proverava jednakosti i vraa poruku o neuspehu. Izvravanjem SimpleTest-a dobija se izvetaj o 1 greci i 2 otkaza.

14

4.
TESTIRANJE SOFTVERA U NETBEANS IDE RAZVOJNOM OKRUENJU
Za potrebe ovog seminarskog rada bilo je potrebno instalirati: Java SE Developnent Kit 7 NetBeans IDE 7.0 Ovaj softwer je besplatan i nalazi se na adresama: http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads1880260.html https://netbeans.org/downloads/ Nakon preuzimanja ovog softvera, njegova instalacija je jednostavna i svodi se na prihvatanje ponuenih podrazumevanih opcija i prelaska na sledee korake dok se ne zavri instalacija. 4.1 Kreiranje novog projekta i njegovo testiranje 1. Nakon pokretanja NetBeans JDK 7.0 pristupamo kreiranju novog projekta (File > New Project > Java > Java Application).

15

2. Nakon toga kreiramo klasu Email.java u okviru NikolaOstojicSeminarski projekta (File > New File > Java > Java Class).

16

3. Kreiranu Email.java klasu zameniti sledeim kdom:

17

package nikolaostojicseminarski; public class Email { private String emailStr; public Email() { super(); // TODO Auto-generated constructor stub } public Email(String str) { super(); // TODO Auto-generated constructor stub emailStr = str; } public String getEmailStr() { return emailStr; } public void setEmailStr(String emailStr) { this.emailStr = emailStr; } public boolean isValid() { boolean result = true; int atPosition = emailStr.indexOf("@"); if (atPosition == -1 // must have an @ sign || atPosition == 0 // no @ at the beginning || atPosition == emailStr.length()-1) // no @ at the end result = false; return result; } }

Klasa Email.java koju smo kreirali i koju treba da testiramo omogoava modelovanje email-a i poseduje nekoliko metoda koje ilustruju kako se moe manipulisati i proveravati email string. 4. Sada je potrebno kreirati Junit test klasu koju emo nazvati EmailJUnitTest (File > New File > Junit > Junit Test)

18

19

Za razliku od Junit 3.x u Junit 4.x ne zahteva proirivanje TestCase klase da bi se implementirali testovi. Jednostavna Java klasa se moe koristiti kao TestCase. Test metode se mogu jednostavno obeleiti sa org.junit.Test anotacijom. U Junit 4.0 test klase se ne nasleuju od TestCase klase i kao rezultat toga Assert metode nisu dostupne za test klase. Da bi se Assert metode mogle koristiti moraju imati prefiks u sintaksi (Assert.assertEquals()) ili koristiti static import za Assert klase.
import org.junit.Test; import static org.junit.Assert.*;

5. Zatim dodajemo sledee metode u nau Junit test klasu:

@Test public void TestAtSignExists() { Email myEmail = new Email("abc.com");

// // assertEquals(myEmail.isValid(), false); // // // // //

kreiranje novog Email objekta uz pomoc konstruktora assertEquals proverava da li dva argumenta imaju jednaku vrednost posto email nema znak @, funkcija myEmail.isValid() bi trebalo da vrati false

myEmail.setEmailStr("billy@abc.com"); assertEquals(myEmail.isValid(), true); // @ znak je OK => true } @Test public void TestAtSignNotTheBeginning() { Email myEmail = new Email("@abc.com"); // postavljanje/izmena email stringa assertEquals(myEmail.isValid(), false); // @ znak je na pocetku => false } @Test public void TestAtSignNotTheEnd() { Email myEmail = new Email("abc.com@"); // postavljanje/izmena email stringa assertEquals(myEmail.isValid(), false); // @ znak je na kraju => false } @Test public void TestNoTwoAtSigns() {

20

Email myEmail = new Email("billy@abc.com@"); assertEquals(myEmail.isValid(), false); // @ znak je na kraju => false //(Zasto onda test nije prosao?) }

Svaki poseban test pie se kao bezparametarski javni void metod u test klasi, koji mora da ima prefiks @Test. Rezultat izvravanja kda koji se testira proverava se unutar test metoda pozivom jednog ili vie assert metoda definisanih u okviru alata Junit.

6. Na kraju je potrebno pokrenuti EmailJUnitTest klasu. Trba imati na umu da to nije glavna klasa i na taj nain se ne moe samo kliknuti na PLAY ikonu.

7. Na kraju moemo videti rezultate testiranja:

21

U ovom prozoru e biti izlistani rezultati svakog pojedinanog testa. Zbog korienja metoda setUp i tearDown, testovi su nezavisni, pa je mogue da od etiri testa prva dva prou, trei ne, a onda poslednji proe. To je dobra stvar jer nam pokazuje kao lo tano onaj test koji pravi problem, a ne i sve posle njega. Primeujemo da je greka nastala u TestNoTwoAtSigns metodi EmailJUnitTest klase. U pomenutoj metodi je bilo potrebno ispitati email string u kome se nalaze dva znaka @ od kojih je jedan na pravom mestu a jedan je na kraju stringa. Iako bi funkcija myEmail.isValid() trebala da vrati false (jer smo u znak @ postavili i na poslednje mesto), ona ipak vraa true, pa se u poreenju sa drugim argumentom test metode assertEquals() koji je false, vraa rezultat false. To zni da treba napraviti izmene nad funkcijom isValid() koja se nalazi u Email.java klasi koju testiramo. Da bi klasa koju testiramo zadovoljila sve uslove u okviru funkcije isValid() emo ispred if petlje dodati sledei red kda
int atPosition2 = emailStr.lastIndexOf("@");

a zatim u okviru if petlje dodajemo sledeu liniju koda

|| atPosition != atPosition2

Kada ponovo pokrenemo test dobijamo sledee rezultate:

22

Primer 2: esto se deava da imamo dva ili vie testova koji koriste isti skup objekata. Ovaj skup objekata naziva se text fixture. Text fixture se upotrebljava na sledei nain: Kreirati lan klase za svaki objekat iz text fixture Napisati metod koji postavlja skup radnih objekata (staviti oznaku @Before) Napisati metod koji isti skup radnih objekata (staviti oznaku @After) Metode obeleene sa @Before se pozivaju pre svakog test metoda. Metode obeleene sa @After se pozivaju nakon svakog test metoda. Time se izbegavaju boni efekti izmeu pokretanja test metoda. Metode obeleene sa sa @BeforeClass i @AfterClass se pzivaju pre i posle Test klase. Sledi demonstracija upotrebe osnovnih oznaka u Junitu: Nakon kreiranja novog projekta odmah kreiramo novu Junit test klasu.
package primer2; import org.junit.*; import static org.junit.Assert.*; import java.util.*; /** * * @author Nikola */ public class NewEmptyJUnitTest { private Collection collection; @BeforeClass public static void oneTimeSetUp() { // one-time initialization code System.out.println("@BeforeClass - oneTimeSetUp"); }

23

@AfterClass public static void oneTimeTearDown() { // one-time cleanup code System.out.println("@AfterClass - oneTimeTearDown"); } @Before public void setUp() { collection = new ArrayList(); System.out.println("@Before - setUp"); } @After public void tearDown() { collection.clear(); System.out.println("@After - tearDown"); } @Test public void testEmptyCollection() { assertTrue(collection.isEmpty()); System.out.println("@Test - testEmptyCollection"); } @Test public void testOneItemCollection() { collection.add("itemA"); assertEquals(1, collection.size()); System.out.println("@Test - testOneItemCollection"); } }

Nakon pokretanja testa dobijamo obavetenje da su oba testa prola kao i sledei rezultat:

24

5.
ZAKLJUAK
Pisanje testova korienjem Junit tehnologije pomae programerima da stvaraju kd u kojem se lake izbore sa grekama za ije pronalaenje i ispravku ponekad treba izdvojiti previe vremena. Pored toga, odravanje kda napisanog test-driven metodom je dosta lake pa samim tim i refaktorisanja, koja su deo ivotnog ciklusa svakog softvera.

25

6.
LITERATURA
[1.] Todor unjevi, Vojin Kerleta, Nenad Milievic, Testiranje u Java okruenju, INFOTEH-JAORINA Vol. 8, Ref. E-V-9, p. 726-729, March 2009. [2.] Unit testovi, http://poincare.matf.bg.ac.rs/~jelenagr/rs2/Testiranje.pdf [3.] Test dokumentacija, http://clinfowiki.org/wiki/index.php/Software_Test_Documentation [4.] Junit in NetBeans, http://www.itk.ilstu.edu/faculty/bllim/itk353/JUnit-NB6.1.htm [5.] Misa Lazovi, Testiranje softvera i xUnit, http://www.itk.ilstu.edu/faculty/bllim/itk353/JUnit-NB6.1.htm [6.] basic annotation supported in Junit 4.x http://www.mkyong.com/unittest/junit-4tutorial-1-basic-usage/

26