In concluzie

Acesta este un extras din Cartea electronică de testare a unității, de Marc Clifton, oferită cu amabilitate de Syncfusion.

Testarea unităților este, de asemenea, valoroasă pentru alte scopuri.

Ca exemple de utilizare

Unul dintre avantajele secundare ale testelor de unitate este că creează o bază de cod mare, exemplificând modul de utilizare a codului. De exemplu, codul pe care l-am văzut mai devreme:

[Test] public void Numele fișieruluiParsingTest () Dictionary opțiuni = CommandLineParser.Parse ("- f foobar"); Assert.That (opțiuni.Count == 1, "Count așteptat să fie 1"); Assert.That (opțiunile.ContainsKey ("- f"), "Opțiunea așteptată" -f ""); Assert.That (opțiuni ["- f"] == "foobar");

documentează un caz de utilizare preconizat valabil pentru parserul liniei de comandă. Luați în considerare și testarea unităților de testare - nu numai pentru propriul cod, ci și pentru a oferi exemple pentru bibliotecile terților. (A se vedea exemplele ulterioare și lucrurile interesante dezvăluite despre structura Rectangle.)

Black Box Testing

Testul pentru cutia neagră presupune că nu cunoașteți nimic despre interiorul clasei sau serviciului și verificați comportamentul acestuia strict de la interfețele expuse publicului. Acest lucru este necesar în mod frecvent atunci când nu aveți codul disponibil. De exemplu, când lucrăm cu o companie de gestionare a înregistrărilor, am fost obligați să folosim un serviciu web furnizat de o agenție guvernamentală pentru a actualiza înregistrările. Prin scrierea testelor unitare pentru serviciul web, am putut dovedi că documentația furnizată nouă nu a dus la comportamentul așteptat al serviciului web.

Puteți utiliza această tehnică și atunci când lucrați cu codul furnizat de diferite departamente. De exemplu, grupul de baze de date ar putea avea propriile teste de unitate albă; cu toate acestea, ar trebui să verificați, de asemenea, că dintr-o perspectivă cutie neagră, declanșatoarele și constrângerile au fost programate corect, prin inspectarea rezultatului tranzacțiilor din funcția care vă este expusă.

Testați-vă ipotezele

Testarea unităților poate fi o modalitate simplă de a reuni câteva teste referitoare la ipotezele noastre despre un API. Să luăm System.Drawing.Rectangle structura și testarea unor presupuneri aparent rezonabile cu privire la implementare.

Testul presupus de constructor

Sunt două Dreptunghi constructori: unul având Punct și mărimea parametrii, cealaltă având parametrii x, y, lățime și înălțime. Documentația nu indică dacă dimensiunea (lățimea sau înălțimea) trebuie să fie pozitivă, așa că să scriem un test pentru a verifica dacă putem construi un dreptunghi cu lățimea sau înălțimea negativă:

[TestMethod] void public RectangleNegativeSizeConstructorTest () Dreptunghi r = nou dreptunghi (0, 0, -4, -6);

Tot ceea ce facem aici în acest test verifică faptul că nu se aruncă nicio excepție atunci când construim dreptunghiul, și într-adevăr, acesta este cazul:

Rectangular Constructor Test

Ipoteze de test referitoare la valorile proprietăților

Acum, să testați ipotezele noastre cu privire la anumite proprietăți. Proprietatile Top, Stânga, Fund, și Dreapta sunt descrise ca (a se vedea
http://msdn.microsoft.com/en-us/library/system.drawing.rectangle.aspx):

Sus: Obtine coordonata y a marginea superioara a acestei structuri Rectangle.

Stânga: obține coordonatele x ale marginii din stânga a acestei structuri Rectangle.

Partea de jos: obține coordonata y care este suma valorilor de proprietate Y și Height ale acestei structuri Rectangle.

Dreapta: obține coordonatele x care reprezintă suma valorilor proprietăților X și Width ale acestei structuri Rectangle.

Deci, cu dreptunghiul precedent, cu lățimea și înălțimea negativă și deci cu coordonatele [(-4, -6), (0, 0)], am face următoarele ipoteze:

[TestMethod] void publice TestLeft () Dreptunghi r = nou dreptunghi (0, 0, -4, -6); Assert.IsTrue (r.Left == -4, "Stânga așteptată == -4 dar a fost" + r.Left ");  [TestMethod] void public TestTop () Rectangul r = nou dreptunghi (0, 0, -4, -6); Assert.IsTrue (r.Top == 0, "Expected Top == 0 dar a fost" + r.Top);  [TestMethod] void public TestRight () Rectangul r = nou dreptunghi (0, 0, -4, -6); Assert.IsTrue (r.Right == 0, "Dreptul așteptat == 0 dar a fost" + r.Right);  [TestMethod] void public TestBottom () Rectangul r = nou dreptunghi (0, 0, -4, -6); Assert.IsTrue (r.Bottom == -6, "Bottom așteptat == -6 dar a fost" + r.Bottom);

Cu toate acestea, nu este cazul:

Testarea ipotezelor privind proprietățile dreptunghiului

De fapt, determinarea vârfului și a fundului pare total arbitrară, deoarece am efectuat teste pe exact aceleași dimensiuni dreptunghiulare și am observat rezultate diferite în Top și Fund valorile proprietăților.

Testează ipotezele privind rezultatele metodei

Documentația MSDN afirmă că Rectangle.Intersect metodă:

Returnează oa treia structură dreptunghiulară care reprezintă intersecția a două alte structuri dreptunghiulare.
Dacă nu există intersecție, se returnează un dreptunghi gol.

Prin urmare, putem construi un simplu test:

[TestMethod] void public TestIntersection () Rectangle r1 = dreptunghi nou (0, 0, 10, 10); Dreptunghi r2 = dreptunghi nou (10, 10, 5, 5); Assert.IsFalse (r1.IntersectsWith (r2), "Așteptat R1 și R2 să nu se intersecteze."); Assert.IsTrue (Rectangle.Intersect (r1, r2) == Rectangle.Empty, "Așteptat un dreptunghi de intersecție gol");

cu rezultatul:

Testarea ipotezelor noastre despre metodele de returnare

Acest lucru ne informează că așteptările noastre, bazate pe documentație, sunt incorecte.

In concluzie

Testarea unităților este un instrument important în procesul de testare. În timp ce testarea integrării și utilizabilității sunt adesea mai orientate spre client (raportare, etape, verificarea cerințelor de nivel înalt), testarea unităților este prima linie de apărare a unui programator, a echipei sale și a managerilor de echipă. Dacă este folosit în mod judicios (nu uitați să nu creați mii de lumini verde), acesta poate fi un mod eficient de verificare a corectitudinii computaționale a codului și pentru re-crearea de bug-uri și verificarea faptului că acestea au fost reparate.

Cu toate acestea, practicile bune de testare a unităților necesită o abordare disciplinată, un angajament față de timpul și efortul necesar pentru punerea în aplicare și menținerea testelor și, din perspectiva unui coder, necesită, de asemenea, bune practici de programare și, adesea, impune decizii arhitecturale. Acestea din urmă ar putea zbura în fața constrângerilor "pur și simplu" (care ar putea fi destul de legitime) și ar putea afecta performanța. În plus, practicile de programare și arhitecturile care unesc forțele de testare pe care le utilizează sunt adesea de mare folos pentru întregul proces de dezvoltare a aplicațiilor, reducând astfel costurile și îmbunătățind mentenabilitatea, nu pentru că codul este testat unitate, ci pentru că codul este scris mai bine așa că poate sa fi testat unitatea.

Cod