Unit testing Gruppe 2: Kjartan Haugen Jon Gunnar Bjørkmo Leendert Wienhofen Olav Dæhlie Thomas Julsen Carl-Erik Herheim

Unit testing Hvorfor så få tester kode Når man bør teste kode Unit testing frameworks: JUnit Et eksempel på bruk av JUnit Hvorfor så få tester kode: Det er nemlig veldig få utviklere som tar seg tid til å teste koden de lager på ein skikkelig måte Når bør man teste kode: vinkla mot Xtreme Programming Unit Testing Frameworks: Rammeverk / Verktøy for testing av kode * JUnit: Som er det mest brukte verktøyet for testing av Javakode * Eksempel: * Andre: Til slutt gi oversikt over andre verktøy/rammeverk som finnes for andre språk

A vicious cycle Hvorfor tester vi ikke kode? Høyt arbeidspress / dårlig tid Mindre stabil kode Færre tester Grunnen til at så få programmerere/utviklere tester koden sin. Ond sirkel: ..figur som kan vise grunnen til at så få tester koden sin. Mindre produktivitet og nøyaktighet

Unit testing – XP style Når bør man teste kode? Skal du legge til en ny egenskap, lag en test før du lager selve koden. Skal du fikse en feil, lag en test som påviser feilen før du reparer den. Hver gang før du integrerer koden må unit testing være 100% feilfri. ”Don’t let the fear that testing can’t catch all bugs stop you from writing tests that will catch most bugs” Ny feature: det er litt unighet om man bør skrive ein test før eller etter man utvikler koden. Fikse feil: Integrere kode: Før du begynner med Integrasjonstesting (som gr. 3 skal fortelle meir om) må unit testing være feilfri.

The official JUnit home page: http://Junit.org ”JUnit er et enkelt rammeverk for java brukt til å skrive og kjøre gjenntagende tester” The official JUnit home page: http://Junit.org JUnit innkluderer: - Assertions (Påstander): Når man vil sjekke verdier, kaller man f.eks assertTrue() og sender med en boolean som skal være sann hvis testen lykkes. - Test fixtures: Benyttes når man har to eller flere tester som opererer mot de samme objektene. - Test suites: For å kunne kjøre flere tester samtidig. - Graphical and textual test runners: - junit.awtui.TestRunner - junit.swingui.TestRunner (Grafisk) Junit.zip: Inneholder blant annet junit.jar (JUnit API), som man setter klasspath til å peke på. Assertions: ”Metoder som verifiserer resultat” (over 30 stk.) feks. : om man kaller assertEquals("23", Tall.toString(23)); -> for å teste om toString-metoden vår er riktig. Test Fixtures: Om man rellaterer til Junit sitt API: Overloade setUp() for å inititalisere variabler og Overloade tearDown() for å gjøre det motsatte.. fjerne slik at testene blir isolert ifra hverandre --- komme tilbake med eksempel --- TestSuite: JUnit tilbyr et objekt, TestSuite som kan kjøre flerie tester samtidig.

Eksempel på bruk av JUnit 1.) Subklasse av TestCase: import java.util.*; import junit.framework.*; public class SimpleTest extends TestCase { public SimpleTest(String name) { super(name); } 2.) Initialiserer objekt som benyttes i testen: protected void setUp() { collection = new ArrayList(); itr = collection.iterator(); 3.) public void tearDown(){ collection.clear(); //fjerner alle elementer 4.) En samling av påstander (Assertions): public void testEmptyCollection() { Collection collection = new ArrayList(); assertTrue(collection.isEmpty()); public void testNoSuchElementException() { try { Object o = itr.next(); fail("Should raise an NoSuchElementException"); } catch (NoSuchElementException success) {} public void testOneItemCollcetion(){ collection.add("itemA"); assertEquals(1, collection.size()); } 5.) Suite: Lager en samling av alle metodene som starter med ”test”: public static Test suite() { return new TestSuite(SimpleTest.class); 5.) Skrive en main metode som kjører testene: public static void main(String args[]) { junit.textui.TestRunner.run(suite()); 6.) Kjør testen: java SimpleTest java junit.swingui.TestRunner SimpleTest (grafisk) Formål: Teste metoder i iterator og collection (at de er riktig kodet) / At de gjør det me vil de skal gjere. setUp: initialiserer objekt. tearDown: blir kallt opp mellom hver test. testEmptyCollection: Vi påstår at at collection.isEmpty() skal returnere True testNoSuchElementException: Om itr.next() kaster unntak er testen vellykket, ellers blir fail()-kallt opp. testOneItemCollection: tester om collection.size() returnerer 1 etter at vi lagt til et element i ”collection”.

Gjennomgang av kode Walkthrough Code inspection Mindre formell Du presenterer kode og dokumentasjon for et review team, som har kommenterer og endringer. Fokuserer på å finne feil i koden, men ikke nødvendigvis endre koden der og da. Fokus på koden, ikke koderen Code inspection Mer formell metode. Arbeidsoppgaver til test team Gjennomgang av algoritmer for sjekke korrekthet og effektivitet. Gjennomgang om kommentarer samsvarer med koden. Beregning av minneforbruk eller prosesseringshastighet. I tillegg gjennomgang av interface mellom komponenter.

Hvorfor inspeksjon av kode før enhetstesting Desto tidligere en feil er oppdaget i utviklings prosessen, desto lettere og billigere er det å rette den opp. Når enhetstesting er utført, er medarbeiderne lite motivert for inspeksjon av koden. De vet at produktet virker. Kode inspeksjon kan avdekke design feil, som ikke kommer fram i enhetstesting. Du sparer resurser og penger ved inspeksjon av koden før enhetstesting.

Testing av program komponent For å teste en komponent velger vi inndata og betingelser, lar komponenten manipulere dataene, og observerer utdataene. Test case: Eksempel på hvordan man tester en komponent som er laget for å ta imot positive heltall. Komponenten må ha en test case for: Store positive heltall. Et positivt heltall. Et tall større en 0, men mindre en 1. Et positivt desimaltall med faste siffer. Null Negative tall Numeriske karakterer.

Testing versus proving Formal proof technics Uttrykker programmet ved hjelp av matematiske termer og notasjoner slik at det ikke er rom for misforståelser. Vi kan formulere programmet som et sett av teoremer og påstander(assertion), som beviser riktigheten av koden. Fordeler Vi kan oppdage algoritme feil i koden Formell forståelse av koden Vi blir tvunget til å være mer presis i beskrivelsen av datastrukturer og algoritme regler. Ulemper I mange tilfeller tar det lenger tid å bevise at koden er korrekt, en å skrive selve koden. Ikke numeriske program kan være mer kompleks å representere logisk, en numeriske. Parallelle prosesser er vanskelig å håndtere.

Branch vs Random testing Teste ulike veier. 1-2-3-4-5-6-7 1-2-3-4-5-6-1 1-2-4-5-6-7 1-2-4-5-6-1

Sammenligning av teknikker