Testimise tüübid

Sissejuhatus

Eelmine peatükk tutvustas testimist kui praktikat ning mainis lühidalt erinevaid testimise tasemeid. See peatükk vaatleb igat taset lähemalt, selgitab, mida see kontrollib, ning täpsustab, kuidas need tasemed omavahel seotud on.

Nende erinevuste mõistmine aitab otsustada, millist tüüpi testi konkreetses olukorras kirjutada.

Üksustestimine (unit testing)

Üksustest kontrollib kõige väiksemat testitavat koodiosa, tavaliselt ühte meetodit või klassi, isoleerituna ülejäänud süsteemist.

@Test
void testSumPositiveNumbers() {
    int result = Calculator.sum(2, 3);

    assertEquals(5, result);
}

Põhiomadused

• Üksustestid on reeglina kiired, töötavad millisekunditega.
• Üksustestid on sõltumatud. Testitav kood ei sõltu välistest süsteemidest. Kui sellel on sõltuvusi, asendatakse need testidublitega (käsitletud mock'imise peatükis).
• Üksustestid on fokuseeritud ehk need keskenduvad ühele konkreetsele käitumisele.

Üksustestid on koodibaasis kõige levinum testitüüp. Need annavad kiire tagasiside ja näitavad täpselt, kus midagi valesti läks.

Integratsioonitestimine

Integratsioonitest kontrollib, et mitu komponenti töötaksid koos õigesti. Erinevalt üksustestidest ei asenda integratsioonitestid sõltuvusi - need kasutavad päris komponente, et veenduda, et erinevad süsteemi osad oleks õigesti ühendatud.

@Test
void testServiceReturnsBooksFromRepository() {
    BookRepository repository = new InMemoryBookRepository();
    repository.save(new Book("Clean Code", "Robert Martin", 2008, new BigDecimal("35")));

    BookService service = new BookService(repository);
    String result = service.getAllBooks();

    assertTrue(result.contains("Clean Code"));
}

Antud näite puhul BookService klassi testitakse koos reaalse BookRepository teostusega. See test kontrollib, et teenusklass delegeeriks tööd andmehoidlale ning töötleks tulemust õigesti.

Põhiomadused:

• Võrreldes üksustestidega on integratsioonitestidel laiem skoop. Need katavad kahe või enama komponendi omavahelist koostööd.
• Aeglasem võrreldes üksustestidega, kuna testimisel on suurem kogus koodi.
• Avastavad ühendusvigu ehk probleeme, mis ilmnevad ainult komponentide omavahelise koostöö ajal.

Läbivtestimine (End-to-end testing)

Läbivtestid kontrollivad terviklikku kasutajavoogu läbi kogu süsteemi.

Tüüpilise veebirakenduse puhul võib läbivtest välja näha selline:

1. Saadetakse HTTP-päring, et luua uus kasutaja
2. Saadetakse uus päring, et sisse logida äsja loodud kasutajasse
3. Kontrollitakse, et vastused serverilt sisaldavad oodatud andmeid.

Põhiomadused:

• Võrreldes eelneva kahe tüübiga on läbivtestid kõige realistlikumad kuna need testivad süsteemi sarnasel eeldusel nagu kasutajad kasutaksid seda.
• Läbivtestid on aeglased kuna süsteem peab tervikuna töökorras olema.
• Läbivtestid on haprad, väike muudatus kasutajaliideses või tagarakenduses API spetsifikatsioonis võivad testid katki teha, kuigi funktsionaalsus toimib.

Läbivtestid on testikomplektis väärtuslikud, kuid neid on raske hallata ja käivitada. Igale tegevusele pole mõistlik läbivtesti luua, neid peaks looma ainult kriitilistele kasutusjuhtudele.

Testipüramiid

Erinevaid testitüüpe kujutatakse sageli püramiidina:

         / \
        /   \          Vähe E2E teste
       / E2E \         (aeglased, kallid, aga realistlikud)
      /_______\
     / Integr. \       Mõõdukalt integratsiooniteste
    /  ation    \      (keskmine kiirus, laiem skoop)
   /_____________\
  /     Unit      \    Palju üksusteste
 /     tests       \   (kiired, fokuseeritud, isoleeritud)
/___________________\

Püramiid kujutab praktilist kompromissi erinevate tasemete vahel

• Üksustestid peaksid moodustama enamiku testidest. Neid on odav kirjutada, neid saab kiirelt käivitada ja annavad täpselt teada, kus viga tekkis.
• Integratsioonitestid täidavad lüngad, mida üksustestid ei kata - need kontrollivad, et komponendid töötaksid tegelikult koos.
• Läbivteste kasutatakse säästlikult, et kontrollida kõige olulisemaid kasutusjuhte.

Kui viga on võimalik tabada üksustestiga, tuleks selle jaoks üksustest kirjutada. Kõrgema taseme peale tasuks mõelda ainult siis, kui madalama taseme test ei ole suuteline sellega tegelema.

Muud testimise tüübid

Lisaks kolmele peamisele tasemele on veel mitmeid testimispraktikaid, mida tasub teada:

Regressioonitestimine. Regressioonitestimine ei ole eraldi tase, vaid praktika: olemasolevate testide uuesti käivitamine pärast muudatust, et veenduda, et varem töötanud funktsionaalsus ei ole katki läinud. Iga testitüüp (üksus-, integratsiooni- või läbivtest) võib toimida regressioonitestina.

Proovitestimine (smoke testing). Proovitestimine on kiire viis kuidas kindlaks teha, et kriitilised funktsionaalsused töötavad. See on väike osa kogu testikomplektist, mida kasutatakse veendumaks, et programmi põhifunktsionaalsus toimiks.

Jõudlustestimine (performance testing). Jõudlustestimine kontrollib, kas süsteem vastab kiiruse ja ressursikasutuse nõuetele eeldatava koormuse all.

Manuaalne testimine Manuaalset testimist viib inimene käsitsi läbi. Kuigi automatiseeritud testid on eelistatud korduvuse tõttu, on manuaalne testimine endiselt väärtuslik kasutajakogemuse, visuaalse disaini ja selliste stsenaariumide hindamiseks, mida on raske automatiseerida.