En nybegynnerveiledning for testing: Feilbehandling av kantsaker

Når du bygger komplekse programvarestykker, uansett språk, begynner du å legge merke til et mønster i testvanene dine. De samme problemene med lignende utseende vil oppstå på forskjellige plattformer eller prosjekter. Uansett om du bygger en annen enkel oppgavedemo for en samtale eller arkitekterer en omfattende back-end for en PaaS-oppstart, begynner de samme generiske mønstrene å dukke opp.

Det er seks saker som bør testes som vil skinne lys over et overraskende antall spørsmål. Disse er ikke ment å være omfattende, eller en komplett testpakke. Snarere er de en lett å huske delmengde av vanlige testparadigmer som kan gjelde for ethvert språk, rammeverk eller miljø.

Disse sakene er umiddelbart nyttige i to aspekter av daglige kodingsrutiner: feilsøking av spesifikke problemer når de oppstår, og i opprettelsen av testpakken for en kodebase. De er ment å være generiske, abstrakte former for testing som vil skinne lys over noen av de vanligste problemene juniorutviklere står overfor.

Disse vil bare være nyttige på en rundkjøring i funksjonell programmering. Funksjonell programmering omgår mange av de enkleste typer feil som er beskrevet nedenfor. Uansett er det nyttig å huske på denne typen abstrakte grensesaker, da de gir en beskyttelsesskinne mot dårlig praksis i kode.

De seks testene er som følger:

  • Null
  • En
  • To
  • To til maks-1
  • maks
  • maks + 1

Selv om dette er grensesaker, ligger verdien i det de representerer. Mens du sørger for at testene dine dekker all funksjonalitet i programmet ditt, bør du holde testene enkle med så lite teft som mulig.

Null

Null brukes til å betegne hvilken som helst form for nullinngang, enten det er udefinert, null, en tom matrise eller bare det faktiske tallet 0. Uten tvil er den vanligste og enkle formen for feil å referere til en nullverdi, og den bærer alltid testing. Det er bare å teste en funksjon, et sluttpunkt eller laste opp med null inngang, og kontrollere at den oppfører seg som forventet.

En

En, som Zero, er den mest grunnleggende formen for den generiserte enkelt testen. Funksjonen blir testet med den første gyldige, normale inngangen. Dette er mest nyttig for regresjonstesting. I fremtidige gjentakelser av koden vil denne testen raskt indikere om programmet (eller prosessen) fungerer som forventet.

Én testing gir deg en grunnlinje for suksess, enten det er en vellykket autentisering på et administratorendepunkt, en gyldig filopplasting eller en riktig matrixendring.

To

To handler ikke bare om å teste matriseindeks 2, eller om algoritmen din fungerer med to innganger. Det omfatter også hva som skjer når du kjører den samme koden to ganger.

Hvis noen skulle gjøre en SLETTE HTTP-forespørsel to ganger på rad til den samme ressursen, hva skjer? Hvis sorteringsfunksjonen med en tilpasset komparator blir ringt to ganger på rad, oppfører den seg som forventet?

To er et interessant tall, fordi det er første gang gyldig kode som fungerer når den ringes en gang, kan vise bivirkninger ved gjentatte henrettelser. Ta en liten endring i funksjonene vi har testet ovenfor.

Det kommer ned til modifikasjoner av tilstanden, og forstå oppførselen til en funksjon. Hvis alt vi har er funksjonsnavnet, oppfører denne koden seg akkurat som forventet. Du har en variabel kalt 0, du kaller funksjonen setVarToOne, og deretter hevder du at den er lik en.

Ved første øyekast oppførte dette seg akkurat som forventet. Å teste det med tanken om to i tankene vil imidlertid fremheve dypere problemer med koden. Du vil teste det ved å ringe det to ganger, og hevde at i begge tilfeller er mVar lik 1.

To til maks-1

To til max-1 er sunnhetssjekken. Det ligner veldig på One-testen, men det er en subtil forskjell. Dette bør være en gjennomsnittlig brukssak - ikke den enkleste eller enkleste, eller den letteste å lese. Bare en gjennomsnittlig brukssak som kanskje ikke er spesielt enkel, men som er ganske vanlig .

Maks

Max er ganske grei: det tester bare begrensningene for applikasjonen din, spesielt rundt definerte maksimale konstanter.

Hvis du har en enkel implementering av koblet liste, kan du forestille deg at du har et tilsynelatende uendelig antall tillatte innlegg. I virkeligheten er det en øvre grense - enten det er INT_MAX, antall filbeskrivere operativsystemet ditt kan ha åpent, eller bare hvor mye minne eller diskplass som er tildelt programmet ditt.

Under noen omstendigheter kan Max virke som en umulig test fordi det ikke er noe kjent maks for hva du tester. Målet i disse tilfellene er imidlertid av en annen art: å stresstest søknaden din.

For eksempel er det mulig at en viss del av brukerinnsendte data blir redusert og ført gjennom funksjoner til den når en sløyfe du har definert. Hvis disse dataene er, for eksempel INT_MAX, kan det ta en ubetydelig tid før koden din er fullført. Verre, det kan kaste koden din i en ikke-stoppende tilstand. Dette kan være subtile problemer som bare oppstår når koden din kommer i produksjon, så det er viktig å fange dem i løpet av testfasen.

Maks + 1

Max + 1 er en test som for det meste brukes til å verifisere standardene eller reglene som er satt på plass av programmereren. Dette innebærer å teste alt til sin teoretiske grense + epsilon.

Dette kan manifestere seg som et problem utenfor rekkevidden, en feil ved en feil, en heltalsfeil eller noe annet problem som skjer når du når grensene for funksjonen eller programmet.

Hvis du har en maksimal filopplastingsstørrelse på 2 MB, kan du prøve å laste opp en fil som er 2 MB + 1 B i størrelse. Hvis du har en grense for antall oppføringer i en brukerkatalog, må du sørge for at bekreftelsen skjer både på klientsiden ogserver side.

Konklusjon

Som nevnt ovenfor er dette ikke et fullstendig bilde av hva feilsøkings- eller testrutinene dine bør være. Dette gir ganske enkelt en solid, generell grunnlinje som skal overskride en hvilken som helst spesifikk testpakke eller rammeverk.

Testene blir ofte sett på som grense- eller kanttilfeller, men de kan løfte sitt stygge hode på steder som ikke er umiddelbart åpenbare.