de JonLuca De Caro

Când construiți programe software complexe, indiferent de limbă, începeți să observați un model în obiceiurile dvs. de testare. Aceleași probleme cu aspect similar vor apărea pe diferite platforme sau proiecte. Indiferent dacă construiți o altă demonstrație simplă de listă de sarcini pentru o discuție sau arhitecturați un back-end cuprinzător pentru o pornire PaaS, aceleași tipare generice încep să apară.

Există șase cazuri care ar trebui testate, care vor da lumină asupra unui număr surprinzător de probleme. Acestea nu trebuie să fie cuprinzătoare sau să fie o suită de testare completă. Mai degrabă, sunt un subset ușor de reținut al paradigmelor de testare obișnuite, care se pot aplica oricărei limbi, cadru sau mediu.

Aceste cazuri sunt utile imediat în două aspecte ale rutinelor zilnice de codificare: depanarea problemelor specifice pe măsură ce apar și în crearea suitei de testare pentru o bază de cod. Acestea sunt destinate a fi forme generice, abstracte de testare, care vor da o lumină asupra unora dintre cele mai frecvente probleme cu care se confruntă dezvoltatorii juniori.

Acestea vor fi utile doar într-un mod giratoriu în programarea funcțională. Programarea funcțională ocolește multe dintre cele mai simple tipuri de erori descrise mai jos. Oricum ar fi, este util să țineți cont de acest tip de cazuri de granițe abstracte, deoarece acestea oferă o cale de protecție împotriva practicilor proaste din cod.

Cele șase teste sunt după cum urmează:

  • Zero
  • unu
  • Două
  • De la două la maxim-1
  • max
  • max + 1

Chiar dacă acestea sunt cazuri limită, valoarea lor este în ceea ce reprezintă. În timp ce vă asigurați că testele dvs. acoperă toate funcționalitățile programului dvs., ar trebui să vă păstrați testele simple, cu cât mai puțin fler posibil.

Conţinut

Zero

Zero este folosit pentru a semnifica orice formă de intrare nulă, indiferent dacă este nedefinită, nulă, o matrice goală sau pur și simplu numărul real 0. Probabil că cea mai comună și simplă formă de eroare este referința la o valoare zero și este mereu testată. Pur și simplu testați o funcție, un punct final sau încărcați cu o intrare zero și verificați dacă se comportă conform așteptărilor.

unu

Una, ca Zero, este cea mai de bază formă a testului unic genericizat. Funcția este testată cu prima intrare validă, normală. Acest lucru este cel mai util pentru testarea de regresie. În iterațiile viitoare ale codului, acest test va indica rapid dacă programul (sau procesul) funcționează conform așteptărilor.

O testare vă oferă o linie de bază pentru succes, indiferent dacă este o autentificare reușită pe un punct final de administrare, o încărcare validă a fișierului sau o modificare corectă a matricei.

Două

Doi nu se referă pur și simplu la testarea indexului matricei 2 sau dacă algoritmul dvs. funcționează cu 2 intrări. De asemenea, cuprinde ceea ce se întâmplă atunci când rulați același cod de două ori.

Dacă cineva ar face o solicitare HTTP DELETE de două ori la rând cu aceeași resursă, ce se întâmplă? Dacă funcția de sortare cu un comparator personalizat este apelată de două ori la rând, se comportă așa cum era de așteptat?

Two este un număr interesant, deoarece este prima dată în care codul valid care funcționează atunci când este apelat o dată poate prezenta efecte secundare asupra execuțiilor repetate. Aduceți o mică modificare a funcțiilor pe care le-am testat mai sus.

Se reduce la modificări de stare și la înțelegerea comportamentului unei funcții. Dacă tot ce avem este numele funcției, atunci acest cod se comportă exact așa cum era anticipat. Aveți o variabilă numită 0, numiți funcția setVarToOne și apoi afirmați că este egală cu una.

La prima vedere, acest lucru s-a comportat exact așa cum era de așteptat. Cu toate acestea, testarea acestuia având în vedere ideea Two ar evidenția probleme mai profunde cu codul. O veți testa apelând-o de două ori și afirmând că în ambele cazuri, mVar este egal cu 1.

De la două la maxim-1

De la două la maxim-1 este verificarea sănătății. Este foarte similar cu testul One, dar există o diferență subtilă. Acesta ar trebui să fie un in medie caz de utilizare – nu cel mai simplu sau cel mai simplu sau cel mai ușor de citit. Doar un caz de utilizare mediu care poate nu este deosebit de simplu, dar care este destul de uzual.

Max

Max este destul de simplu: testează pur și simplu limitele aplicației dvs., în special în jurul constantelor max definite.

Dacă aveți o implementare simplă a listei legate, vă puteți imagina că aveți un număr aparent infinit de inserții permise. În realitate, există o limită superioară – indiferent dacă este INT_MAX, numărul de descriptori de fișiere pe care sistemul dvs. de operare îl poate avea deschis sau pur și simplu cantitatea de memorie sau spațiu pe disc alocat pentru programul dvs.

În anumite circumstanțe, Max ar putea părea un test imposibil, deoarece nu există un maxim cunoscut pentru ceea ce testați. Obiectivul în aceste cazuri, totuși, este de altă natură: să vă testați solicitarea.

De exemplu, este posibil ca o anumită bucată de date trimise de utilizator să fie redusă și trecută prin funcții până când ajunge la o buclă definită de dvs. Dacă aceste date sunt, să zicem, INT_MAX, s-ar putea să dureze o perioadă deloc neglijabilă pentru finalizarea codului. Mai rău, s-ar putea să vă arunce codul într-o stare non-stop. Acestea pot fi probleme subtile care apar numai odată ce codul dvs. intră în producție, deci este important să le prindeți în timpul fazei de testare.

Max + 1

Max + 1 este un test care este utilizat în principal pentru a verifica standardele sau regulile puse în aplicare de către programator. Aceasta implică testarea oricăror la limita sa teoretică + epsilon.

Acest lucru s-ar putea manifesta ca o problemă de matrice în afara limitelor, o eroare off by one, o eroare de depășire a numărului întreg sau orice alt tip de problemă care se întâmplă atunci când atingeți limitele funcției sau programului dvs.

Dacă aveți o dimensiune maximă de încărcare a fișierului de 2 MB, încercați să încărcați un fișier cu dimensiunea de 2 MB + 1b. Dacă aveți o limită a numărului de intrări într-un catalog de utilizatori, asigurați-vă că verificarea are loc atât pe partea clientului și partea de server.

Concluzie

Așa cum am menționat mai sus, aceasta nu este o imagine completă a ceea ce ar trebui să fie rutinele de depanare sau testare. Aceasta oferă pur și simplu o bază solidă, generică, care ar trebui să depășească orice suită sau cadru de testare specific.

Testele sunt văzute în mod obișnuit ca cazuri de graniță sau de margine, dar își pot sprijini capul urât în ​​locuri care nu sunt imediat evidente.