unitate de testare (unitate de testare sau de unitate de testare) - este izolat verificarea fiecărui element individual prin rularea testelor într-un mediu simulat. Pentru a face acest lucru, utilizați driverele și stub-uri. Unitatea de testare - primul pentru a realiza codul sursă. Evaluarea fiecărui element în mod izolat și confirmând corectitudinea muncii sale, doar rezolva problema mult mai ușor decât în cazul în care elementul a fost o parte a sistemului.
Unitatea (Element) - cea mai mică componentă care poate fi compilat.
Conducătorii auto - module de testare, care se execută elementul de testare.
Fișe - înlocuirea componentelor care lipsesc, care sunt invocate elementul și efectuați următorii pași:
- a reveni la elementul fără a efectua orice alte acțiuni;
- mesaje de afișare urme și, uneori, pentru a oferi continua testarea tester;
- returnează o valoare constantă sau oferă tester pentru a introduce valoarea de retur;
- efectuat punerea în aplicare simplificată a componentelor care lipsesc;
- Imită condiții excepționale sau de urgență.
Testarea alb-box. Pentru a construi teste utilizat o structură internă a logicii de cod și de control. În acest caz, este posibil ca codul va fi verificat așa cum a fost scris, dar nu garantează corectitudinea logicii.
Testarea black-box. Pentru construirea testelor utilizate și cerințele caietului de sarcini de software. dezavantaje:
- în acest fel, este imposibil de a găsi erori vzaimounichtozhayuschihsya
- Unele erori apar rar (erori de memorie), și pentru că acestea sunt dificil de a găsi și să se joace
Strategia de unitate de testare
Unitatea de testare este una dintre practicile cheie ale metodologiei Extreme Programming. Susținătorii XP citează următoarele argumente în favoarea acestei practici:
- Scrierea teste ajută să intre într-un ritm de lucru
- Se dă încredere că codul funcționează.
- Acesta oferă o marjă de siguranță pentru modificările de integrare sau cod suplimentare.
Sunt de acord, participarea la ritmul de lucru - o sarcină nobilă. Încrederea în performanță - de asemenea, bun. Dar „auto-sănătate“ Eu prefer cod într-adevăr funcțional. Chiar și în timp ce eu nu sunt exact „sigur“.
Un factor cheie în evaluarea perspectivele oricărei metode - costul proiectului. Activitatea suplimentară privind crearea de teste, de codificare și verificarea acestora a rezultatelor contribuie în mod semnificativ la costul total al proiectului. Iar faptul că produsul va fi de o calitate superioară nu depășesc întotdeauna faptul că acesta va fi mult mai scump.
În opinia mea, unitate de testare este justificată în cazul în care este:
- Reduce timpul de depanare
- Aceasta permite rezolvarea problemelor, la un cost mai mic decât alte abordări
- Acesta permite depanarea ieftine atunci când codul de modificări mai târziu
Câștigul total de la utilizarea de teste unitare trebuie să fie mai mare decât costurile de stabilire și menținere la zi.
În cazul în care rezultatul corectării erorilor de integrare schimbă codul sursă, este probabil să conducă la o eroare. În cazul în care, ca urmare a adăuga noi funcționalități, modificați codul sursă, este probabil să conducă la o eroare. Și cel mai bun aspect cu ajutorul testelor unitare create anterior.
Scopul unitate de testare:
Se obține codul de lucru la cel mai mic cost. Și utilizarea sa este justificată dacă și numai dacă este mai eficient decât alte metode.
Rezultă o serie de concluzii:
- Nu are nici un sens să scrie teste pentru întregul cod. Unele erori sunt mai ușor de găsit într-o etapă ulterioară. De exemplu, regula pentru OEP poate fi: nu are nici un sens să scrie teste pentru o clasă, care este folosit doar de o singură clasă. Efectiv scrie teste pentru clasa de asteptare si de a crea teste de testare toate părțile codului.
- Testele de scriere sunt potențial supuse unor schimbări mai favorabile pentru codul decât pentru codul, care nu este de așteptat să se schimbe. scheme logice se schimbă frecvent decât simpla. În consecință, în primul rând are sens să scrie teste unitare pentru logica complexe. Și logica simplu pentru a scrie mai târziu, sau chiar pentru a testa alte metode.
- Pentru a planifica în mod corespunzător o interfețe de testare bune pot fi schimbate mai puțin frecvent. Același lucru se poate spune cu privire la scrierea codului sursă. Într-adevăr, crearea arhitecturii bune de multe ori determină viitorul curs al proiectului. Și există optim, la care arhitectura etapă „suficient de bun.“ Toate adevărat, dar vreau să vorbesc despre altceva:
În cazul în care proiectul este folosit pentru test de unitate, planificarea atentă a interfețelor devine mai profitabilă. punerea în aplicare de testare unitate ar trebui să preceadă introducerea planificării interfețe.
planificarea de testare
Prima întrebare cu care ne confruntăm: „Cât timp ar trebui să testez.“ Răspunsul, care este dat de multe ori: testele trebuie să fie suficient pentru a evita zonele netestate rămân. Puteți introduce chiar și o regulă formală:
Mai întâi de toate testele trebuie să respecte codul nu este, și cerințele. O regulă care ar trebui să se aplice:
Testele trebuie să se bazeze pe caietul de sarcini.