Cu toate acestea, cu mesajul, rezultatele testelor devin mult mai plăcute la citire.
Dezvoltatorii scriu de obicei teste unitare numai pentru opțiunile oferite de dezvoltator / arhitect / documentație / etc pentru comportamentul funcției. pentru
StringUtils. de laDouble (), documentația indică faptul că funcția este de a converti numărul punctului variabil într-un șir.
Testul unitar al acestei funcții acoperă numai funcțiile descrise. Scopul testării unității este de a vă asigura că funcția funcționează corect și că nu căutați condiții,
în care nu funcționează corect.
În plus, testul unității este deja o documentație concisă și ușor de înțeles a funcției. Cele patru linii descriu în mod clar și fără echivoc modul în care se comportă funcția: returnează un nou obiect șir al cărui valoare este numărul transferat în virgulă mobilă, scrisă în notație zecimală.
Și cel mai important bonus pentru testarea unității este fixarea comportamentului codului. Acum știi că funcția se comportă într-un anumit mod. Iar codul care o folosește se bazează pe acest comportament. Dacă doriți să schimbați această funcție, testul unității va asigura acest lucru
comportamentul funcției rămâne același (sau testul nu reușește). Prin urmare, restul codului nu va observa modificări în implementarea funcției, ceea ce înseamnă că de acum înainte puteți schimba liniștit orice parte a codului: testele unității nu vă vor permite să întrerupeți nimic.
Al doilea test de unitate
Următorul test de unitate este scris pentru inversarea funcției de conversie de tip "string-to-floating point":
Aceasta este o funcție simplă și, prin urmare, testul este de asemenea foarte simplu: valoarea de intrare, valoarea de referință și comparația cu rezultatul. De obicei, atunci când scrieți astfel de teste simple, variabilele nu generează în mod explicit valori, ci le scrieți direct în funcția assert *.
Cu toate acestea, în assertEquals un parametru suplimentar a apărut în acest test! Faptul este că este imposibil să comparăm numerele cu un punct plutitor direct unul cu altul, deoarece nu au o reprezentare binară exactă. De obicei, numerele sunt comparate cu unele erori: putem spune că 3.1415000000001 este echivalent
3.1415000000002 cu o eroare de până la 0.000000000001. Și această eroare este transmisă celui de-al treilea parametru assertEquals pentru un număr cu virgulă mobilă. A doua parte a testului este evidentă - se verifică dacă NaN este returnat pentru nulul transmis.
Testul unității a treia
JUnit. cadru. AssertionFailedError. așteptat. <[ Ljava. lang. String ; @61b383e9> dar a fost. <[ Ljava. lang. String ; @5099681b>
De aceea, JUnit oferă o funcție specială pentru compararea array-urilor assertArrayEquals, care compară echivalența dintre fiecare element al ambelor matrici unul cu celălalt. Desigur, elementele cu aceeași poziție în matrice sunt comparate, iar matrici de diferite lungimi sunt imediat recunoscute ca neechivalente. Trebuie notat că funcția inversă pentru assertArrayEquals nu este furnizată.
Testul pentru ultima funcție rămasă (joinArray), vă propun să vă scrieți.
Exemplu de test, pentru comparație:
Articole similare
Trimiteți-le prietenilor: