Unit testing

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

2. Hvorfor så få tester kode Når man bør teste kode Unit testing frameworks: JUnit Et eksempel på bruk av JUnit Unit testing

3. A vicious cycle Hvorfor tester vi ikke kode? Høyt arbeidspress / dårlig tid Mindre stabil kode Færre tester Mindre produktivitet og nøyaktighet

4. 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”

5. JUnit ”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)

6. 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) Eksempel på bruk av JUnit

7. Gjennomgang av kode • Walkthrough • 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.

8. 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.

9. 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.

10. 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.

11. 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

12. Sammenligning av teknikker