NUnit - cadru unitate de testare - gândire cu voce tare

De la mine Mi-aș dori să adăugați. Materialul este suficient de util, descrisă mai sus, și arată o mulțime de oportunități, în cazul în care înainte de această lucrare cu NUnit, ca atare, nu este efectuată.

Ei bine, probabil, va începe (ooh și namuchalas ca eu sunt acum cu înregistrare)

Deci, ce a apărut în NUnit versiunea 2.5?

1. Noi constrângeri.
2. comparatoare definite de utilizator.
3. Abilitatea de a defini acuratețea compararea numerelor în virgulă mobilă, data și ora.
4. teste parametrice.
5. Combinatorie si-teste în pereche.
6. Teorii.
7. Browser Excepție (în GUI-client).
8. execuția în paralel a testelor (pnunit).

model bazat pe Constrângere

Probabil că, înainte de a trece la descrierea unor noi constrângeri și modificatori, are sens să spun câteva cuvinte despre ceea ce este constrangerile si modificatori

Modelul tradițional de inspecție, a cărei rădăcini se află, probabil, în primul cadru unitate de testare publică, JUnit, înseamnă că avem o anumită clasă (Assert), având un set de metode statice pentru a verifica diferite condiții.

Cu această abordare, metodele de testare sunt după cum urmează:

Prima versiune a NUnit Testele folosind modelul tradițional, și este încă păstrat pentru compatibilitate inversă, dar acum modelul de bază controale bazate pe utilizarea obiectelor individuale (constrângeri de punere în aplicare interfață IConstraint), fiecare dintre care implementează un anumit cec:

Multe obiecte au constrângeri modificatori - proprietăți sau metode pentru a specifica parametri suplimentari. Aceste proprietăți și metode returneaza o referinta la obiectul in sine, astfel încât acesta poate fi folosit „într-un lanț“:

În cele din urmă, NUnit include clase speciale sunt „ajutoare de sintaxă“ - este si a, care vă permit să înregistreze starea de aproape limbaj „uman“:

În opinia mea, modelul bazat pe constrângere are doar trei plus:

În primul rând, condițiile mai ușor de percepție vizuală - cu toate acestea, există opinii diferite cu privire la această problemă.

În al doilea rând, cu atât mai ușor condițiile de scriere - AreEqual () metoda are 24 variante, și este destul de dificil de a alege dreapta, chiar dacă folosiți IntelliSense, iar selecția și constrângerile de utilizare ajutoare sintaxa metoda potrivită este mult ușurată.

Și, în sfârșit, model bazat pe constrângere este mai corectă din punct de vedere metodologic - pentru fiecare tip de test răspunde o clasă separată, ceea ce înseamnă că codul este mai ușor de înțeles.

Constrângerile noi

Cred că acum este momentul să răspundă la întrebarea de ce a apărut noi constrângeri în NUnit 2.5. Aceste constrângeri sunt enumerate mai jos:

1. RangeConstraint
2. Constrângerile Path (SamePathConstraint, SamePathOrUnderConstraint)
3. Constrângerile de colectare (UniqueItemsConstraint, CollectionOrderedConstraint)
4. ThrowsConstraint
5. DelayedConstraint

Desigur, nici un revelații aici, dar pentru a lucra cu NUnit este acum mai ușor!

gama Constrângere

RangeConstraint vă permite să verificați că valoarea se încadrează în acest interval:

După cum puteți vedea, este doar un scurt substitut pentru construcția de mai sus, după cum urmează:

Constrângerile Path

SamePathConstraint vă permite să verificați dacă în același mod:

SamePathOrUnderConstraint vă permite să verificați că real-calea este aceeași ca sau „mai jos“ așteptat-un fel:

De asemenea, nimic special, doar un plus la îndemână pentru moduri de comparație.

Constrângerile de colectare

De mult mai mare interes sunt constrîngerile pentru compararea colecții: UniqueItemsConstraint și CollectionOrderedConstraint.

UniqueItemsConstraint, după cum sugerează și numele, vă permite să verificați dacă colecția conține doar elemente unice:

CollectionOrderedConstraint verifică dacă elementele de colectare a urmat într-o anumită ordine. Următoarele exemple sunt prezentate exemple de realizare folosind această constrângere.

aruncări Constrângere

În cele din urmă a apărut în constrângerea NUnit excepții de urmărire:

Anterior, pentru a verifica dacă unele cod aruncă o excepție, era necesar să se utilizeze doar o astfel de structură voluminoasă:

După cum puteți vedea, folosind Aruncări Constrângerea trebuie să scrie mai puțin cod, este posibil să se verifice mai multe condiții, cu excepții într-un singur test, și în cele din urmă, există mai multe oportunități pentru a verifica conținutul obiectului excepție!

Constrângere întârziat

În cele din urmă, DelayedConstraint vă permite să verificați dacă evenimentul are loc după o anumită perioadă de timp. Un mic exemplu:

Ie DelayedConstraint poate fi utilizat pentru urmărirea fără mișcări suplimentare ale unor acțiuni care sunt efectuate asincron în raport cu testul. Așa că această situație nu pare exagerată, voi da un exemplu mai real de viață:

În acest exemplu, clasa CommandProcessor efectuează comenzi de procesare asincrone au fost atribuite și la sfârșitul tratamentului Demască prelucrate de pavilion. Verificarea faptului că comanda a fost procesată cu succes, fabricate folosind DelayedConstraint, timpul maxim de așteptare este de 1 secundă, sondajul realizat de pavilion, cu un interval de 100 de milisecunde.

Atunci când se compară elementele din ecuație capacitatea de a utiliza comparatoare definite de utilizator:

Și două opțiuni: mai multe

O astfel de abordare poate fi utilă în cazurile în care este necesar să se efectueze o pluralitate de comparații „complex“ de obiecte pentru care, cu toate acestea, este de nedorit suprascrie Egali () metodă, dar cel mai mare efect se obține atunci când se compară colecții:

Înainte de versiunea 2.5 pentru punerea în aplicare a unui astfel de comparație a trebuit să utilizeze soluții, cum ar fi utilizarea LINQ:

Dar, în același timp, în cazul unei defecțiuni, în loc de posturi informative:

Samples.CollectionSamples.CustomComparerTest:
De așteptat și reale sunt ambele valori diferă la indexul [1]
lungimile sirurilor sunt ambele 1. Șiruri difera la indexul 0.
Așteptat: «B»
Dar a fost: «x»
---- ^

am primit neconvingătoare:

Samples.CollectionSamples.LinqComparerTest:
De așteptat: Adevărat
Dar a fost: Fals

Compararea numere reale cu virgulă

Așa cum am spus, în NUnit 2.5 au posibilitatea de a specifica precizia cu care doriți să compare numere în virgulă mobilă. Pentru a face acest lucru în trei EqualConstraint modificator adăugat: In cadrul, Procent și Ulps.

În cadrul Modificator vă permite să specificați valoarea absolută a erorii, care va compara două numere în virgulă mobilă:

Dar, din cauza restricțiilor privind lungimea mantisa valoarea absolută a erorii nu este pentru totdeauna, de exemplu, poate fi imposibil pentru testul parametric, care lucrează într-o gamă largă de valori, pentru a alege valoarea erorii - este sau va fi prea mare pentru a testa pentru valorile „mici“ au fost ceea ce înseamnă, sau prea puțin, pentru a testa cu succes a trecut valorile „mari“. Pentru a compensa aceste probleme sunt modificatori și procentul Ulps.

Procent Modificator vă permite să specificați eroarea în procente:

Un modificator Ulps vă permite să specificați precizia în „unități în ultimul loc“, adică De fapt, în ceea ce privește erorile mașinii aritmetice:

Comparați data și ora

În plus, modificatori specificat de precizie în comparație cu numere în virgulă mobilă în NUnit 2.5 au apărut modificatori pentru specificarea preciziei atunci când se compară data și ora. exemplu de viață - de tip DATETIME în SQL Server vă permite să salvați data și ora până la 3 milisecunde, așa că, dacă vom scrie valoarea data și ora în baza de date SQL Server, și apoi citiți imediat valoarea, în majoritatea cazurilor primite de la SQL valoarea Server nu se va potrivi cu originalul.

Acest lucru poate fi ușor de verificat:

Așa cum s-ar putea fi de așteptat, testul eșuează.

Anterior acestui test pentru a lucra, a trebuit să adăugați manual codul pentru a converti DateTime la SqlDateTime, acum puteți adăuga doar Milisecunde modificator:

În afară de Milisecunde modificator sunt altele: zile, ore, minute, secunde și căpușele.

Testele parametrice versiunea 2.5

Această abordare nu este lipsită de probleme, deoarece Nu toate valorile pot fi specificate ca atribute. De exemplu, atributul nu poate specifica un tip de valoare zecimală, care este utilizat în aplicații de afaceri.

teste parametrice simple

NUnit 2.5 au fost „nativ“ teste parametrice și un număr mare de opțiuni pentru specificarea argumentelor acestor teste.

În primul rând, puteți seta parametrii în atribute, așa cum a fost făcută prin utilizarea RowTest:

Puteți simplifica acest test, folosind doar un astfel de design distractiv:

Puteți specifica un set de valori de testare în matrice - iar acum poate fi parametrii de orice tip, de exemplu, aceeași zecimal:

Puteți lega la fiecare set de valori de test date suplimentare, de exemplu, că în cazul în care un anumit set de argumente, există o excepție specifică în mod explicit sau rezultatul:

Și, puteți determina proprietatea IEnumerable de tip, iar în acest caz nu sunt restricționate în alegerea sursei de date - acestea pot fi luate dintr-un fișier sau o descărcare din baza de date:

Combinatorie si-teste în pereche

testarea combinatorie

În plus față de testele parametrizate simplu, NUnit va fi de două tipuri de teste - este o combinatorie si teste-perechi.

Cu teste simple de combinatorii - metoda de testare NUnit dă la intrare toate combinațiile posibile ale parametrilor de intrare:

Rezultatul testului:

***** Samples.CombinatorialSamples.CombinatorialTest ( «a», »-«»x»)
o-x
***** Samples.CombinatorialSamples.CombinatorialTest ( «o», »-«»y»)
a-y
***** Samples.CombinatorialSamples.CombinatorialTest ( «a», »+», »x»)
a + x
***** Samples.CombinatorialSamples.CombinatorialTest ( «a», »+», »y»)
a + y
***** Samples.CombinatorialSamples.CombinatorialTest ( «b», »-«»x»)
b-x
***** Samples.CombinatorialSamples.CombinatorialTest ( «b», »-«»y»)
b-y
***** Samples.CombinatorialSamples.CombinatorialTest ( «b», »+», »x»)
b + x
***** Samples.CombinatorialSamples.CombinatorialTest ( «b», »+», »y»)
b + y

Apropo, atributul combinatorie este opțională, dar eu prefer să o fac pentru a îmbunătăți lizibilitatea.

Teste pereche

Al doilea tip de testare - o pereche-teste. In pairwise, sau „toate perechi“, o metodă de testare pentru testarea de introducere a transmis toate combinațiile posibile de perechi de parametri:

Asta e ceea ce vedem atunci când rulează acest test:

***** Samples.PairwiseSamples.PairwiseTest ( «a», »-«»x»)
o-x
***** Samples.PairwiseSamples.PairwiseTest ( «a», »+», »y»)
a + y
***** Samples.PairwiseSamples.PairwiseTest ( «b», »-«»y»)
b-y
***** Samples.PairwiseSamples.PairwiseTest ( «b», »+», »x»)
b + x
***** Samples.PairwiseSamples.PairwiseTest ( «b», »+», »y»)
b + y

Ce pot folosi teste-pereche? Desigur, în scopul de a reduce costul de executie de testare - chiar și pe un eșantion mic poate fi văzut câștigătoare Pairwise-test comparativ cu un test de combinatorice - 5 până la 8 combinații!

Probabilitatea ca orice eroare este cauzată de o combinație unică a tuturor parametrilor sunt semnificativ mai mici decât probabilitatea ca eroarea va provoca o combinație a celor două (trei etc.) setările și numărul de combinații pentru testul tuturor perechilor, în funcție de numărul de argumente este crescut mult mai lent decât numărul de combinații pentru teste combinatorii.

De exemplu, dacă avem 10 parametri, iar fiecare parametru are 10 valori, pentru testul combinatorie numărul de combinații va fi 1010, în timp ce pentru testul all-pereche, numărul de combinații este de numai 155!
În general vorbind, acest lucru nu este în întregime adevărat, corect să spunem „nu mai mult de 155“. Numărul minim de cazuri de testare necesare pentru a acoperi toate perechile posibile de valori pot fi setate doar forță brută, care necesită o cantitate mare de resurse. Algoritmul este utilizat NUnit, care a inventat și implementat în utilitatea sa, „Jenny“ Bob Jenkins. În acest algoritm generează aleatoriu mai multe cazuri de testare, iar apoi este selectat unul dintre ele pentru a oferi cea mai bună acoperire - și așa mai departe până când sunt „închise“, toate perechile de valori.

Atributele ValueSource, Range, aleatorii și secvențiale-teste

atribut ValueSource

Un set de valori care vor fi utilizate pentru a testa argumentul poate fi setat cu atributul ValueSource (la fel cum se face pentru exemple de test):

atribut Range

Cu atributul Range, puteți specifica o serie de valori ale argumentului: