En begyndervejledning til testning: Fejlhåndtering af kanttilfælde

Når du bygger komplekse stykker software, uanset sprog, begynder du at bemærke et mønster i dine testvaner. De samme problemer, der ligner hinanden, vil opstå på tværs af forskellige platforme eller projekter. Uanset om du bygger en anden enkel opgaveliste-demo til en samtale eller arkitekterer en omfattende back-end til en PaaS-opstart, begynder de samme generiske mønstre at dukke op.

Der er seks sager, der skal testes, der skinner et overraskende antal spørgsmål. Disse er ikke beregnet til at være omfattende eller en komplet testpakke. Snarere er de en let at huske delmængde af almindelige testparadigmer, der kan gælde for ethvert sprog, ramme eller miljø.

Disse sager er straks nyttige i to aspekter af daglige kodningsrutiner: debugging af specifikke problemer, når de opstår, og i oprettelsen af ​​testpakken til en kodebase. De er beregnet til at være generiske, abstrakte former for test, der vil skinne et lys over nogle af de mest almindelige problemer, som juniorudviklere står over for.

Disse vil kun være nyttige på en rundkørsel i funktionel programmering. Funktionel programmering omgår mange af de enkleste typer fejl, der er beskrevet nedenfor. Uanset hvad er det nyttigt at huske på denne form for abstrakte grænsesager, da de giver en beskyttelsesskinne mod dårlig praksis i kode.

De seks tests er som følger:

  • Nul
  • En
  • To
  • To til max-1
  • maks
  • maks. + 1

Selv om dette er grænsesager, ligger deres værdi i det, de repræsenterer. Mens du sikrer, at dine tests dækker al funktionalitet i dit program, skal du holde dine tests enkle med så lidt flair som muligt.

Nul

Nul bruges til at betegne enhver form for nul-input, hvad enten det er udefineret, null, et tomt array eller simpelthen det faktiske antal 0. Den mest almindelige og enkle form for fejl henviser muligvis til en nulværdi, og den bærer altid test. Du skal blot teste en funktion, et slutpunkt eller uploade med en nul-input, og kontrollere, at den opfører sig som forventet.

En

Den ene er ligesom nul den mest basale form for den generiserede enkelt test. Funktionen testes med det første gyldige, normale input. Dette er mest nyttigt til regressionstest. I fremtidige gentagelser af koden vil denne test hurtigt indikere, om programmet (eller processen) fungerer som forventet.

Én test giver dig en basislinie for succes, hvad enten det er en vellykket godkendelse på et admin-slutpunkt, en gyldig filupload eller en korrekt matrixændring.

To

To handler ikke bare om at teste matrixindeks 2, eller om din algoritme fungerer med 2 indgange. Det omfatter også, hvad der sker, når du kører den samme kode to gange.

Hvis nogen skulle lave en SLET HTTP-anmodning to gange i træk til den samme ressource, hvad sker der? Hvis sorteringsfunktionen med en brugerdefineret komparator bliver kaldt to gange i træk, opfører den sig som forventet?

To er et interessant nummer, fordi det er første gang, hvor gyldig kode, der fungerer, når den kaldes en gang, kan vise bivirkninger ved gentagne henrettelser. Foretag en lille ændring af de funktioner, vi har testet ovenfor.

Det kommer ned til tilstandsændringer og forståelse af en funktions opførsel. Hvis alt, hvad vi har, er funktionsnavnet, opfører denne kode sig nøjagtigt som forventet. Du har en variabel kaldet 0, du kalder funktionen setVarToOne, og derefter hævder du, at den er lig med en.

Ved første øjekast opførte dette sig nøjagtigt som forventet. At teste det med tanken om to i tankerne vil imidlertid fremhæve dybere problemer med koden. Du vil teste det ved at kalde det to gange og hævde, at i begge tilfælde er mVar lig med 1.

To til max-1

To til max-1 er sundhedskontrollen. Det ligner meget på One-testen, men der er en subtil forskel. Dette skal være en gennemsnitlig brugstilfælde - ikke den enkleste eller mest ligefremme eller den letteste at læse. Bare en gennemsnitlig brugssag, der måske ikke er særlig enkel, men det er ret almindeligt .

Maks

Max er ret ligetil: det tester simpelthen grænserne for din applikation, især omkring definerede maksimale konstanter.

Hvis du har en simpel implementering af en sammenkædet liste, kan du forestille dig, at du har et tilsyneladende uendeligt antal tilladte indsatser. I virkeligheden er der en øvre grænse - hvad enten det er INT_MAX, antallet af filbeskrivere, dit operativsystem kan have åbent, eller simpelthen mængden af ​​hukommelse eller diskplads, der er tildelt dit program.

Under nogle omstændigheder kan Max virke som en umulig test, fordi der ikke er noget kendt maksimum for hvad du end tester. Det er målet i disse tilfælde, men det er af en anden karakter: at stresstest din ansøgning.

For eksempel er det muligt, at et bestemt stykke brugerindleverede data reduceres og sendes gennem funktioner, indtil det når en sløjfe, du har defineret. Hvis disse data f.eks. Er INT_MAX, kan det tage en ikke-ubetydelig tid, før din kode er færdig. Værre, det kaster muligvis din kode i en tilstand, der ikke stopper. Dette kan være subtile problemer, der kun opstår, når din kode går i produktion, så det er vigtigt at fange dem i testfasen.

Max + 1

Max + 1 er en test, der mest bruges til at verificere de standarder eller regler, der er indført af programmøren. Dette indebærer at teste noget til dets teoretiske grænse + epsilon.

Dette kan manifestere sig som en matrix uden for grænser-problemet, en off ved en fejl, en heltalsoverløbsfejl eller enhver anden form for problem, der sker, når du når grænserne for din funktion eller program.

Hvis du har en filstørrelse, der maksimalt er 2 MB, kan du prøve at uploade en fil, der er 2 MB + 1 B i størrelse. Hvis du har en grænse for antallet af poster i et brugerkatalog, skal du sørge for, at verifikationen sker både på klientsiden ogserver side.

Konklusion

Som nævnt ovenfor er dette ikke et komplet billede af, hvad dine fejlretnings- eller testrutiner skal være. Dette giver simpelthen en solid, generisk baseline, der skal overskride enhver specifik testpakke eller ramme.

Testene ses almindeligvis som grænse- eller kanttilfælde, men de kan hæve deres grimme hoved på steder, der ikke er umiddelbart indlysende.