Universitatea din Petroșani

Conversie profesionala : Informatică -4 semestre

Student : Popa Ștefania Ramona
Data : 23/06/2022

Referat Inginerie Software

Dezvoltarea aplicatiilor bazate pe testare

 Dezvoltarea aplicatiilor bazate pe testare

Dezvoltarea aplicatiilor bazate pe testare este un proces software care se bazeaza pe repetarea

unui ciclu foarte scurt. In primul rand dezvoltatorul scrie un caz nul de testare automata care
defineste o imbunatatire voita sau o functie noua, apoi produce un cod pentru a trece acest test
si in cele din urma refactorizeaza noul cod la standarde acceptabile. Kent Beck, care este
creditat cu dezvoltarea sau redescoperirea tehnica, a declarat in 2003 ca dezvoltarea bazata pe
testare incurajeaza designul simplu si inspira incredere.

Dezvoltarea bazata pe testare este relationata cu primele conceptele de programare a unei

testari primare, concepte de programare extrema, inceputa in 1999, dar, mai recent, a creat
mai mult interes general in jurul sau. Programatorii aplica, de asemenea, conceptul la
imbunatatirea si depanarea codului original dezvoltandu-l cu tehnici cunoscute mai de demult

Cerinte

Dezvoltarea bazata pe testare impune dezvoltatorilor crearea de teste automate unitare care
definesc cerintele de cod (imediat), inainte de a scrie codul in sine. Testele contin afirmatii
care sunt fie adevarate fie false. Trecand cu bine testele este confirmat comportamentul
corect, prin urmare dezvoltatorii evolueaza si refactorizeaza codul. Dezvoltatorii folosesc
xUnit, pentru a crea si a rula automat seturi de cazuri de testare.

Test-driven ciclu de dezvoltare

Urmatoarea secventa este bazata pe cartea intitulata Test-Driven Development (Dezvoltarea

prin Exemplu).

1. Adaugarea unui test

In dezvoltarea condusa de teste, fiecare caracteristica noua incepe cu scrierea unui test. Acest
test trebuie sa esueze in mod clar, deoarece este scris inainte ca aceasta functie sa fi fost
implementata. (Daca reuseste, atunci fie noua caracteristica exista deja, fie testul este defect.)
Pentru a scrie un test, dezvoltatorul trebuie sa inteleaga in mod clar
specificatiile,caracteristicile si cerintele.Dezvoltatorul poate realiza acest lucru prin cazuri de
utilizare care sa acopere cerintelele si conditiile de exceptie. Acest lucru ar putea implica, de
asemenea, o varianta, sau modificarea unui test existent..

2. Rulati toate testele pentru a vedea daca cel nou esueaza

Aceasta valideaza faptul ca testarea functioneaza corect si ca noul test nu trece din greseala,
fara a solicita un cod nou. Acest pas, de asemenea, verifica si testul in sine, in varianta
negativa: se exclude posibilitatea ca noul test va trece mereu, si, prin urmare, sa fie lipsit de
valoare. Noul test ar trebui sa nu reuseasca, pentru motivul asteptat. Acest lucru sporeste
increderea ca testarea este eficienta,si va trece doar in cazuri voite.

3. Scrierea unui cod oarecare

Urmatorul pas este scrierea unui cod care va permite trecerea testului. Este important ca acest
cod scris sa fie conceput doar pentru a trece testul, buna functionare pe viitor neputand fi
prezisa, anticipata sau permisa la nici un nivel.

4. Rularea testelor automate pentru a le vedea reusind

Daca toate cazurile de testare trec acum, programatorul poate fi sigur ca acel cod indeplineste
toate cerintele de testare.Acesta este un bun punct de la care sa inceapa etapa finala a ciclului.

5. Cod de refactorizare

Acum, acest cod a fost curatat, in functie de necesitati. Prin re-rularea testelor, dezvoltatorul
poate fi sigur ca operatiunea nu este daunatoare functionalitatii existente. Conceptul de
eliminare a dublurii este un aspect important pentru orice software de proiectare.

In acest caz, se aplica de asemenea eliminarea oricarei suprapunere intre codul de testare si
codul de productie.

Repetarea

Incepand cu un alt test nou, ciclul se repeta pentru a preintampina functionalitatea.

Pasii ar trebui sa fie intotdeauna mici, cu cat mai putini numerotati de la 1-10 in fiecare test.

In cazul in care noul cod nu satisface rapid un test nou, sau testul esueaza in mod neasteptat,
programatorul ar trebui sa anuleaze sau sa revina de preferinta pentru evitarea depanarii
excesive. Integrarea continua ajuta prin furnizarea de puncte de control reversibil. Atunci
cand se utilizeaza biblioteci externe, este important sa nu se faca cresteri, sau daca se fac,
acestea sa fie atat de mici incat sa eficientizeze testarea bibliotecii in sine, cu exceptia cazului
in care exista un motiv sa creada ca biblioteca este virusata sau nu este suficient de abilitata
pentru a servi nevoilor programului principal.

Dezvoltarea stil

Exista diferite aspecte in utilizarea dezvoltarii condusa de teste, de exemplu, principiile de

'pastrati-l simplu, elementar ' (KISS) si 'Nu este nevoie sa-l folositi ' (YAGNI).

Concentrandu-ne pe scrierea codului necesar trecerii testelor totul poate fi mai curat si mai
clar decat prin recompunerea unei alte metode.

Pentru a inmagazina concepte de design avansate (cum ar fi un model de proiectare), teste

scrise, vor genera acest design. Codul poate ramane mai simplu decat modelul tinta, dar inca
mai trece toate testele necesare. Acest lucru poate fi nelinistitor la inceput, dar permite
dezvoltatorului sa se concentreze numai la ceea ce este important.
Scrieti testele inainte de orice. Testele ar trebui sa fie scrise inaintea functiilor care trebuiesc
testate. Acest lucru s-a demonstrat a avea doua avantaje. Aceast lucru ajuta la asigurarea
faptului ca aplicatia a fost scrisa pentru testare, ca dezvoltatorii trebuie sa ia in considerare
modul de a testa aplicatia de la inceput, mai degraba decat sa revina asupra acesteia mai
tarziu. De asemenea, se asigura ca testele pentru fiecare caracteristica vor fi scrise.

Cand scrierea de cod caracteristica se face la inceput exista o tendinta a dezvoltatorilor si a

organizatiilor de dezvoltare de a impinge dezvoltatorul la avansarea caracteristicii urmatoare,
astfel prezenta fiind in inregime compromisa.

In primul rand se compromit cazurile de testare. Ideea este de a se asigura ca testul chiar
functioneaza si poate detecta o eroare. Odata ce acest lucru este demonstrat, functionalitatea
de baza poate fi pusa in aplicare. Acest lucru a fost numit 'test-driven mantra de dezvoltare',
cunoscut sub numele de detector rosu / verde (in cazul in care nu reuseste - rosu si verde –
valabil).

Dezvoltarea condusa de teste repeta in mod constant cazuri de testare adaugand unele noi,
trecandu-le, si refactorizandu-le. Primirea rezultatelor asteptate testului la fiecare etapa
consolideaza increderea programatorului si creste productivitatea.

Practicile avansate pot duce la acceptanta de dezvoltare condusa de teste (ATDD) in cazul in

care criteriile specificate de catre client sunt automatizate in testele de acceptare, care conduce
apoi procesul (UTDD). Acest proces asigura clientul de un mecanism automat pentru a decide
daca software-ul indeplineste cerintele lor. Cu ATDD, echipa de dezvoltare are acum un
obiectiv specific pentru a satisface, testele de acceptanta, care il in continuu axat pe ceea ce
clientul vrea cu adevarat din aceasta poveste de utilizator.

vizibilitate mai mare a membrilor clasei anexand si atribute. In NET Framework si cateva alte
limbaje de programare, clasele partiale pot fi folosite pentru a expune metodele private si
datele pentru accesarea testelor.

Este important ca astfel de elemente compromitatoare de testare sa nu ramana in codul de

productie. In C si alte limbaje, cum ar fi compilatorul directive #if DEBUG #endif pot fi
plasate in jurul a astfel de clase suplimentare si intr-adevar, orice alt cod de testare relationat
cu le impiedica sa fie compilate in cod eliberat. Inseamna ca, codul testat nu este exact acelasi
cu cel al unitatii testate. Rularea constanta a mai putinor, dar mai cuprinzatoarelor teste poate
garanta inexistenta unui cod de productie end-to-end, testele de integrare pe versiunea finala
pot asigura apoi (printre altele) ca nici un cod de productie exista, ca subtil se bazeaza pe
aspectele legate de harnasament de testare.

Exista o dezbatere in randul practicienilor de dezvoltare condusa de teste, evidenta in blog-

urile lor si alte scrieri, daca este intelept sa se apeleze la metodele de testare private si
protejate de date.

Bibliografie:

1. https://en.wikipedia.org/wiki/Test-driven_development
2. Beck, K. ‘Test-Driven Development by Example’, Addison Wesley, 2003
3. 'Extreme Programming', Computerworld (online), December 2001,
webpage:  Computerworld-appdev-92
4. Newkirk, JW and Vorontsov, AA. Test-Driven Development in Microsoft .NET,
Microsoft Press, 2004.
5. Koskela, L. 'Test Driven: TDD and Acceptance TDD for Java Developers',
Manning Publications, 2007
6. Erdogmus, Hakan; Morisio, Torchiano. 'On the Effectiveness of Test-first
Approach to Programming'.
7. https://iit-iti.nrc-cnrc.gc.ca/publications/nrc-47445_e.html
8. Proffitt, Jacob. 'TDD Proven Effective! Or is
it?'. https://theruntime.com/blogs/jacob/archive/2008/01/22/tdd-proven-effective-or-
is-it.aspx