Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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

Liknende presentasjoner


Presentasjon om: "Unit testing Gruppe 2: Kjartan Haugen Jon Gunnar Bjørkmo Leendert Wienhofen Olav Dæhlie Thomas Julsen Carl-Erik Herheim."— Utskrift av presentasjonen:

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

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

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

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: 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 (Grafisk) - junit.swingui.TestRunner (Grafisk)

6 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 java junit.swingui.TestRunner SimpleTest (grafisk)

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

12 Sammenligning av teknikker


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

Liknende presentasjoner


Annonser fra Google