Ce este testarea unității?
Testarea unității este un cuvânt autoexplicativ dacă se înțelege ce se înțelege prin unitate. O unitate este cea mai mică bucată de cod posibilă care poate fi izolată logic din sistem. Acest lucru înseamnă că orice bucată de cod care poate lua intrări, efectua o sarcină și poate genera ieșire chiar și atunci când este independentă de întregul sistem sau soluție, poate fi denumită unitate. Testarea acestei bucăți de cod pentru a genera o ieșire preconizată pe un set dat de intrări se numește Testarea unității.
Tipuri de unități de testare
Haideți să discutăm unele dintre tipurile de testare a unității.
1) Testare manuală
Testarea manuală a codului necesită dezvoltatorului să debuteze manual fiecare linie a codului și să o testeze pentru acuratețe. Poate necesita un set de instrucțiuni pas cu pas, de asemenea, dacă funcționalitatea este complexă.
2) Testare automată
În testarea automatizării, dezvoltatorul scrie cod pentru a testa codul. Aceasta este, în general, asistată prin cadre de testare a unităților care nu sunt desfășurate în producție. Alteori, un dezvoltator poate alege să scrie cod de test fără cadrul și să-l comenteze manual înainte de implementare.
Testarea manuală pare evident că consumă mult timp în majoritatea cazurilor. Dar, în unele cazuri, când scrierea de cazuri de testare automată pentru a acoperi fiecare scenariu nu este posibilă, manualul este adesea metoda preferată.
De ce este importantă testarea unității?
Pentru a înțelege importanța testării unității, trebuie să analizăm imaginea mai largă. Este o parte a ciclului de viață al dezvoltării software. Să vedem pe scurt celelalte părți pentru a obține o mai bună înțelegere a rolului unității de testare.
Imaginea de mai sus este o ilustrare simplă a unui ciclu de viață normal de dezvoltare a software-ului și a proceselor de testare implicate cu acesta. Inutil să spun, în funcție de structura proiectului, întregul proces variază odată cu adăugarea și eliminarea anumitor componente. Cu toate acestea, procesul de testare implică, cu siguranță, patru tipuri descrise mai jos:
- Testarea unității - Nivelul elementar al întregului proces de testare. Aceasta este realizată de dezvoltatorul componentei sau de oricare dintre colegii săi. În ultimul caz, este adesea denumit Test peer în lumea software-ului.
- Testare de integrare - Testarea componentei unității cu modulul parent imediat. Scopul este de a verifica dacă componenta unității se integrează bine cu celelalte componente și nu a cauzat funcționarea defectuoasă a niciunei alte componente.
- Sisteme de testare - Testarea întregului sistem atunci când componenta unității este plasată la poziția sa.
- Testarea acceptării - De obicei realizată de companii / clienți, verifică dacă rezultatul se aliniază funcționalității așteptate de utilizatorul final.
Astfel, se poate vedea foarte bine că toate procesele de testare se bazează pe nivelul elementar de testare. În cazul în care nivelul elementar de testare nu este făcut, toate celelalte testări pot avea ca rezultat inutil.
Acum să zicem că aveți un cod care are două părți
- Calculați interesul compus.
- Adăugați dobânda la valoarea principală și calculați beneficiul la scadență.
Să presupunem că nu ați testat unitățile din aceste componente și ați procedat direct la testarea sistemului. O eroare apare la testarea sistemului că valoarea de maturitate este incorectă. Acum ce parte a codului are o eroare?
- Poate fi în calculul dobânzii.
- Poate fi în aplicarea logicii de compunere.
- Poate fi în plus un interes pentru suma principală.
Vezi, cum crește efortul acum. Toate acestea ar fi putut fi evitate dacă ambele componente ale codului ar fi fost testate în unitate.
De ce este importantă testarea unității?
- Remediază erorile doar în faza de dezvoltare. Acest lucru economisește mult timp, efort și costuri. Imaginează-ți dacă nu ar fi efectuate teste unitare, codul ar merge la și de la echipa de asigurare a calității pentru probleme foarte simple.
- Testele de unități bune servesc, de asemenea, scopului unei documentații detaliate. Atunci când un dezvoltator scrie cazuri de testare a unității, el scrie din neatenție funcționalitatea preconizată a codului. Aceasta nu este altceva decât documentație care explică funcționarea codului.
- Face ușor modificarea și menținerea codului. După ce ați făcut orice modificări ale codului, rulați testele din nou și violați, toate defectele sunt surprinse fără probleme.
- De asemenea, aplică modularitatea. Testele unitare sunt efectuate pe componente individuale, ceea ce înseamnă că codul trebuie să fie cât mai granular posibil. Acest lucru asigură că codul este împărțit în mod corespunzător în module.
Cealaltă latură a monedei
Are și unele dezavantaje. Deși avantajele depășesc dezavantajele și se recomandă întotdeauna testarea codului dvs., dar are sens să cunoaștem ambele fețe ale aceleiași monede.
- Testarea unității, cât de cât mai amănunțită, poate uneori să nu surprindă toate erorile din codul cel mai banal. Pur și simplu nu este posibil să evaluați toate căile de execuție. Astfel, testele unitare sunt deseori simple scenarii fericite și negative.
- Este necesar ca un dezvoltator să se gândească la cutie și să încerce să-i rupă codul. Acest lucru este adesea dificil, deoarece percepția unui dezvoltator este părtinitoare către cod.
Instrumente de testare a unității
Există mai multe instrumente în industrie pentru a ajuta la testarea unităților automate. Așa cum este scopul, ele facilitează scrierea și executarea cazurilor de testare a unității pentru dezvoltator. Există o lume a cadrelor de testare a unităților, la debitarea dezvoltatorilor. Unele dintre cele mai populare și utilizate pe scară largă sunt enumerate mai jos.
JUnit
JUnit este un instrument de testare gratuit pentru Java. Acesta este automat inclus în multe șabloane de proiect disponibile cu diverse IDE-uri pentru dezvoltare Java. Ceea ce face JUnit special este faptul că testează mai întâi datele și apoi testează codul după introducerea datelor în el. De asemenea, oferă afirmații pentru identificarea metodelor de testare.
NUnit
NUnit este la .Net așa cum este JUnit în Java. Are toate caracteristicile importante ale JUnit, dar pentru dezvoltare într-un limbaj de programare .Net. De asemenea, acceptă rularea testelor în paralel.
PHPUnit
Similar cu JUnit și NUnit, PHPUnit este un instrument pentru dezvoltatorii PHP. De asemenea, acceptă toate caracteristicile elementare ale unui instrument de testare bun.
XUnit
Un alt cadru mai generic decât omologii săi este XUnit. Suporta mai multe limbi precum C ++, C #, ASP.Net, etc. De asemenea, are funcții similare cu cele ale altor instrumente disponibile pe piață.
Jtest
Parasoft Jtest este un plugin pentru terțe părți care folosește cadrele open source precum JUnit și adaugă soluții cu un singur clic pentru a ușura viața. Cu Jtest, puteți genera automat coduri de testare pentru codul dvs. cu doar câteva clicuri. Prin automatizarea acestor sarcini, dezvoltatorul este liber să lucreze asupra logicii de afaceri a cazurilor de testare.
QUnit
Un cadru foarte popular de testare a unității JavaScript. Poate testa codul JavaScript atât din partea clientului, cât și din partea serverului.
Iasomie
Un alt instrument de testare foarte utilizat pentru cadrele JavaScript. Are sprijin comunitar major pentru Angular, React etc.
JMockIt
JMockIt este un instrument open source care acceptă și batjocurarea apelurilor API cu sintaxa de înregistrare și verificare.
Exemplu de caz de test de unitate
O cerință de bază a oricărui caz de testare a unității este codul care trebuie testat. Să presupunem că avem o funcție care validează dacă numerele de telefon sunt corecte (în termeni de format) sau nu. În funcție de locația geografică, acest criteriu poate varia și el. Deci, nu vom sublinia criteriile. Mai degrabă ne vom concentra asupra cazului testului unității.
public class PhoneValidator
(
public bool IsPhoneValid(string phone)
(
/* write some code to verify if the phone is valid or not. return true, if the phone is valid. return false, if invalid. */
)
)
Acum trebuie să testăm această bucată de cod.
O putem testa fie manual, prin introducerea diferitelor valori și verificarea ieșirii. Acest lucru poate părea ușor la prima privire, dar va fi o sarcină repetată dacă se face vreo modificare a codului.
În mod alternativ, putem scrie un caz de test de unitate care poate servi ca validator al meu, atât timp cât logica de afaceri rămâne aceeași. Cazul testului unității nu se va schimba chiar dacă schimbăm codul. Deci, să scriem un caz de test de unitate pentru codul de mai sus.
public void TestPhoneValidator()
(
string validPhone = "(123) 456-7890";
string invalidPhone = "123 45"
PhoneValidator validator = new PhoneValidator();
Assert.IsTrue(validator.IsPhoneValid(valid phone));
Assert.IsFalse(validator.IsPhoneValid(invalidPhone));
)
Deci, cum funcționează codul de testare al unității de mai sus? Observați cele două declarații Assert. Se asigură că testul trece doar dacă cele două linii primesc adevărat și fals de la apelurile funcționale IsPhoneValid.
V-ați întreba care sunt avantajele redactării acestui caz de testare? Ei bine, dacă aveți mii de numere de telefon pentru a valida în orice scenariu din lumea reală, nu trebuie să verificați manual de fiecare dată când debuggerul apasă codul. Pur și simplu sunați codul testului de mii de ori și vă va spune ce teste au trecut și care nu au reușit. Acum trebuie doar să le inspectați pe cele eșuate.
Sfaturi pentru testarea unității
- Utilizați întotdeauna un instrument sau un cadru care vă sprijină limba. Instrumentele facilitează dezvoltarea cazurilor de testare a unității. În caz contrar, puteți ajunge să depuneți eforturi suplimentare.
- Deși este recomandat pentru toate, uneori este convenabil să omiteți codurile simple și nu afectează în mod direct comportamentul sistemului. De exemplu, codurile getter și setter pot fi mai puțin concentrate pe.
- Nu săriți niciodată coduri care afectează direct sistemul sau sunt cruciale pentru implementarea logicii de afaceri.
- Utilizați date de testare care seamănă cu datele de producție.
- Izolați-vă codul. Dacă codul dvs. depinde de datele din baza de date, nu scrieți un caz de testare pentru a apela baza de date și a obține valori. În schimb, creați o interfață și batjorați apelurile API și la baza de date.
- Înainte de a remedia o eroare care rezultă din testarea unității, scrieți testul care expune defectul. Există trei motive pentru a face acest lucru:
- Veți putea să detectați defectele de regresie care apar din remedierea dvs.
- Cazul dvs. de testare este acum mai cuprinzător.
- Adesea, un dezvoltator este prea leneș pentru a-și actualiza cazurile de testare odată scrise.
- Pe lângă scrierea cazurilor de testare care verifică logica de afaceri, scrieți și cazuri care testează performanța codului dvs. În special atunci când codurile implică bucla, performanța este zona cea mai afectată.
Lucruri de amintit
- Cazurile de testare a unității ar trebui să fie independente de
- Codul care urmează să fie testat - Orice modificare a codului nu ar trebui să necesite o modificare a cazului de testare a unității, cu excepția cazului în care logica de afaceri în sine se schimbă. De exemplu, dacă acum logica cere ca un număr de telefon valid să înceapă întotdeauna cu '+', atunci trebuie testat cazul testului unității, altfel nu.
- Celălalt cod - Nu ar trebui să existe nicio interacțiune sau dependență cu orice altă bucată de cod sau valoare a bazei de date sau cu orice alt lucru. O unitate trebuie izolată la testare.
- Urmați convențiile de denumire clare și coerente pentru cazurile dvs. de testare. Îți facilitează urmărirea scenariilor. Puteți utiliza, de asemenea, instrumente de control pentru versiuni pentru a urmări cazurile de testare.
- Nu treceți niciodată codul la faza următoare până când nu a fost făcut, erorile sunt rezolvate și testate din nou.
- Cel mai important, fă-i un obicei. Aceasta este o practică de codare care trebuie inculcată. Cu cât codificați mai mult fără testarea unității, cu atât codul dvs. este mai predispus la erori.
Cariera în testarea unităților
Deși testarea unității nu este un câmp în ansamblu, totuși, este o săgeată suplimentară în quiver-ul tău. Este o bună practică de codare și când nu sunt preferați codificatorii buni?
Concluzie
Se poate concluziona incontestabil că testarea unității poate fi simplă uneori și alteori complexe. Aceasta este atunci când instrumentele și cadrele vin la salvarea ta. Chiar și odată cu testarea unității, codul nu este complet erodat. Acesta este momentul în care procedurile de testare la nivelul următor încep. Dintre toate aceste incertitudini, singurul lucru cert este că Testarea unității este necesară.
Articole recomandate
Acesta a fost un ghid pentru Testarea unității. Aici am discutat despre importanța, sfaturi, instrumente, carieră și tipuri de teste de unități cu exemplele sale. Puteți parcurge și alte articole sugerate pentru a afla mai multe -
- Testarea întrebărilor la interviu
- Aplicație de testare web
- Ciclul de viață defect în testarea software-ului
- Cariere în testare software
- Lista de cadre de testare pentru Java