I dataprogrammering er enhetstesten (eller " TU " eller " UT " på engelsk) en prosedyre som gjør det mulig å verifisere at en bestemt del av en programvare eller en del av et program (kalt "enhet") fungerer korrekt. eller “modul”).
I ikke-kritiske applikasjoner har skriving av enhetstester lenge blitt sett på som en sideoppgave. Imidlertid har metodene Extreme Programming (XP) eller Test Driven Development (TDD) satt enhetstesting, kjent som “programmerer tests”, i sentrum for programmeringsaktiviteten.
SUnit- testmiljøet for Smalltalk- språket , opprettet iOktober 1994av Kent Beck . I 1997, Kent Beck møtte Erich Gamma som han skapte JUnit som ved sin popularitet, førte til opprettelsen av mange enhetstesting rammer , er dette settet kalles xUnit .
Samtidig ble ATTOL Unit test utviklet, og ble deretter brukt av Sextant Avionique i 1998
Vi skriver en test for å sammenligne en realisering med spesifikasjonen. Den test definerer en stoppkriterium (tilstand eller utganger ved slutten av utførelsen) og gjør det mulig å styre på den suksess eller svikt av en sjekk. Takket være spesifikasjonen er man i stand til å matche en gitt inngangstilstand til et resultat eller en utgang. Den testen som gjør det mulig å verifisere at inngangs / utgangs-forhold som er gitt av spesifikasjonen er faktisk utført.
XP-metoden anbefaler at du skriver testene samtidig, eller til og med før funksjonen som skal testes ( Test Driven Development ). Dette gjør det mulig å presist definere grensesnittet til modulen som skal utvikles. Tester kjøres gjennom hele utviklingen, noe som gjør det mulig å se om den nyskrevne koden samsvarer med kravet.
Når et program er modifisert, rapporterer enhetstester eventuelle tilbakeslag . Visse tester kan faktisk mislykkes etter en modifisering, det er dermed nødvendig å enten omskrive testen for å få den til å svare til de nye forventningene, eller å rette feilen i koden.
Enhetstester kan brukes som et supplement til API , det er veldig nyttig å lese testene for å forstå hvordan en metode brukes. I tillegg er det mulig at dokumentasjonen ikke lenger er oppdatert, men selve testene tilsvarer applikasjonens virkelighet.
Vi definerer generelt fire faser i utførelsen av en enhetstest:
For programmereren innebærer dette å teste en modul , uavhengig av resten av programmet, for å sikre at den oppfyller funksjonelle spesifikasjoner og at den fungerer riktig under alle omstendigheter. Denne sjekken anses å være viktig, spesielt i kritiske applikasjoner. Det ledsages ofte av en kodedekningskontroll (evaluering av strukturell dekning), som består i å sikre at alle testene fører til gjennomføring av alle (eller en bestemt brøkdel) av instruksjonene i koden.
Alle enhetstestene må spilles av etter en modifisering av koden for å kontrollere at det ikke er noen regresjoner (utseendet til nye dysfunksjoner). Bruk av en bestemt "teststrategi" kan begrense testene som skal spilles på nytt, for eksempel: en modifikasjonseffektanalyse, korrelert med et bevis på at modulene er uavhengige, gjør det mulig å målrette mot enhetstestsakene som skal spilles på nytt.
En test må samsvare med spesifikasjonene til applikasjonen, så du må skrive testene først og deretter bestå dem senere i stedet for å skrive koden før og ta risikoen for å bli påvirket av den under skrivetestene. Bob Martin, stor forsvarer av TDD- metoden , tilbyr en enkel modell for å skrive enhetstester:
De simuleringer er objekter for å simulere en virkelig objekt på en kontrollert måte. I noen tilfeller er bruk av mock viktig for å spare tid for kodedekning og pålitelighet av testen.
Imidlertid kan misbruk av mock ha motsatt effekt, inkludert å forlenge testutførelsestiden, noe som gjør tester kompliserte å forstå.
De fleste av rammene til xUnit- familien tillater generering av enhetstestklasser. Imidlertid gir disse rammene bare skjelettet til klassene. Testene må derfor skrives av utvikleren.
Generering av enhetstester er et viktig emne for forskere, og flere konferanser er interessert i dette problemet, for eksempel International Symposium on Software Testing and Analysis (ISSTA), International Conference on Software Engineering (ICSE) og Automated Software Engineering (ASE).
Når du endrer koden til et program, kan det hende at noen tester ikke lenger består. i dette tilfellet må utvikleren avgjøre om den kommer fra selve koden eller fra testen: hvis den kommer fra testen, må utvikleren endre testen sin fordi fjerning av den vil øke sjansene for regresjon av programmet. Noen forskere har utviklet verktøy for å løse dette problemet.
ReAssert er et verktøy som foreslår reparasjoner for en mislykket test, den analyserer tester for modifikasjon og foreslår endringer til utvikleren. Hvis forslaget passer utvikleren, kan de gjøre endringen med et enkelt klikk på en knapp.
Parameteriserbare enhetstester er enhetstester som tar parametere. De kan deretter bruke verktøy som QuickCheck for å generere parametere. Disse testene støttes av JUnit , TestNG og NUnit.
Ved å stole på konkrete inngangs- og utgangssaker, Oracle-generering og testdekning for å minimere tilfeller, har forskere lykkes med å generere konfigurerbare enhetstester. Resultatene av denne metoden er lovende.
Det er mange verktøy ( rammeverk ) for enkelt å utføre enhetstester. De finnes i de viktigste programmeringsspråkene . For eksempel Test::More for Perl .
Det generiske begrepet " xUnit " betegner et verktøy som gjør det mulig å utføre enhetstester på et gitt språk (begynnelsen erstatter vanligvis "x").
Ulike verktøy tillater automatisering av enhetstester: