Acesta este un extras din Cartea electronică de testare a unității, de Marc Clifton, oferită cu amabilitate de Syncfusion.
Mantra obișnuită pe care o auzim în legătură cu orice metodologie software este aceea că îmbunătățește gradul de utilizare și calitate, reduce timpul de dezvoltare și de testare și aduce produsul pe piață mai rapid și cu mai puține bug-uri. Acestea sunt scopuri înalte, dar nu am văzut încă o metodologie care să livreze Graalul dezvoltării de software.
În cele din urmă, motivul principal pentru scrierea testelor unității este să dovedească corectitudinea, iar acest lucru se întâmplă numai dacă scrieți teste unitare bine. Testarea unitară nu va îmbunătăți direct utilizabilitatea sau calitatea produsului dvs. Puteți totuși să faceți o mizerie a aplicației dacă este dovedită corectă sau nu - și cu siguranță nu este garantată reducerea timpului de dezvoltare și de testare (mai multe despre aceasta mai târziu) sau aducerea produsului pe piață mai devreme.
Deci, hai să fim clari și reali din procesul de obținere: testul unității poate fi folosit pentru a verifica corectitudinea și orice efect secundar care are loc în ceea ce privește procesul de dezvoltare trebuie să fie echilibrat cu efortul de a scrie și de a menține teste unitare utile.
Testele unice bine scrise vă vor oferi o măsurabil gradul de încredere că nenumăratele metode care cuprind aplicația dvs. se vor comporta corect. Cea mai simplă modalitate de a face această măsurare în mod obiectiv este un test de acoperire: Care este procentul din metodele din aplicația dvs. care au teste unitate scrise împotriva lor? Deși această întrebare nu se adresează în mod direct dacă o metodă ar trebui considerată o unitate (discutată mai târziu) sau dacă testele sunt semnificative, este totuși o măsură pe care o puteți lua în orice moment și poate fi folosită drept referință pentru corectitudinea aplicatia ta.
Testarea unităților este un proces iterativ - vor exista întotdeauna erori care sunt ratate la testarea unităților. Cu toate acestea, numărul de bug-uri raportate în timp și numărul de probleme nerezolvate față de soluțiile rezolvate furnizează informații relevante privind sănătatea aplicației dvs. Deși este imposibil să spunem: "Cu testarea unităților, numărul de bug-uri a fost redus cu 50%", este posibil să se măsoare câte bug-uri au aplicația dvs. din cauza unei acoperire incompletă a testelor de unitate. Pe măsură ce scrieți teste unitare pentru a verifica problema și remedierea, puteți măsura, de asemenea, câte teste de unități pe care le-ați scris împotriva erorilor raportate în comparație cu numărul total de teste unitare.
Toate aceste criterii de referință aduc un grad de obiectivitate procesului dvs. de dezvoltare. Prin urmare, unul dintre avantajele testării unității este acela că furnizează tuturor, de la dezvoltatori la manageri, informații obiective care pot fi reintroduse în procesul de dezvoltare pentru a îmbunătăți acest proces.
Un alt beneficiu este repetabilitatea, cunoscută și sub numele de teste de regresie. Întrucât o aplicație se maturizează, vrem să asigurăm existența, lucru codul nu este rupt. Prin scrierea testelor de unitate față de metode în timp ce sunt scrise și prin adăugarea testelor unitare pentru bug-uri în timp ce sunt raportate, toate acestea pot fi retestate automat atunci când se adaugă un nou cod sau se modifică codul existent. Testarea unităților devine un instrument semnificativ de reducere a timpului când vine vorba de testarea dacă o aplicație se comportă corect după o schimbare minoră sau semnificativă a codului. În timp ce testarea unității nu înlocuiește testul de utilizare, testarea performanțelor, testarea încărcării și așa mai departe, aceasta contribuie cu siguranță la eliminarea timpului pierdut în legătură cu întrebarea obișnuită: "Aceasta a funcționat înainte; de ce nu-i așa?
Este ușor să testați că o metodă face ceea ce trebuie atunci când toate procesele din metodă sunt executate liniar. Cu toate acestea, odată ce adăugați un dacă
declarație sau a intrerupator
declarație, pe care o creați complexitatea ciclomatică, care este un mod fantezist de a spune că codul dvs. are acum mai multe căi de execuție. Cele mai utile teste de unitate sunt cele care testează fiecare ramură de cod unic care apare în metoda dvs. Scrierea acestor tipuri de teste unitare poate fi dureroasa, dar merita efortul, deoarece garanteaza ca cel putin fiecare ramura de cod a fost executata, ceea ce nu este ceva ce poate aparea in timpul testelor de acceptare, testelor de utilizare sau a altor teste care asigurarea calitatii (dacă aveți unul) efectuează.
În cadrul acestei serii, vom examina mai multe strategii și sfaturi pentru a efectua testarea eficientă a unităților.