Dezvoltarea aplica [632061]

Dezvoltarea aplica
ț
iilor bazată pe

testare

(Test-driven development)

Tu
ț
ă Mihai Constantin Denis

Cuprins

1.
Ce este dezvoltarea bazată pe testare.

2.
Principiile
​
dezvoltării bazată pe testare
​
.

3.
Ciclul dezvoltării bazată pe testare.

4.
Dezvoltarea bazată pe testare
ș
i testarea tradi
ț
ională.

5.
Beneficii
ș
i avantaje.

6.
Limitări

7.
Bibliografie

1

1.
Ce reprezintă dezvoltarea

aplica
ț
iilor bazată pe testare

Dezvoltarea
aplica
ț
iilor
bazată
pe
testare
prescurtată
TDD
poate
fi
definită
ca
o

practică
de
programare
care
instruie
ș
te
dezvoltatorii
să
scrie
un
cod
nou
numai
dacă
un

test
automatizat
a
e
ș
uat.
Acest
lucru
evită
duplicarea
codului.
Scopul
principal
al

dezvoltării bazată pe testare este de a face codul mai clar, simplu
ș
i fără bug-uri.

Dezvoltarea
bazată
pe
testare
începe
cu
proiectarea
ș
i
dezvoltarea
testelor

pentru
fiecare
func
ț
ionalitate
mică
a
unei
aplica
ț
ii.
În
abordarea
dezvoltării
bazată
pe

testare, prima dată se dezvoltă testul care specifică
ș
i validează ce va face codul.

În
procesul
normal
de
testare
a
software-ului,
se
generează
mai
întâi
codul
ș
i

apoi
vom
testa.
Testele
ar
putea
e
ș
ua,
deoarece
testele
sunt
făcute
chiar
înainte
de

dezvoltare.
Pentru
a
trece
testul,
echipa
de
dezvoltare
trebuie
să
dezvolte
ș
i
să

refactorizeze
codul.
Refactorizarea
codului
înseamnă
schimbarea
acestuia
fără
a-i

afecta comportamentul.

Conceptul
simplu
al
dezvoltării
bazată
pe
testare
este
de
a
scrie
ș
i
corecta
testele

e
ș
uate
înainte
de
a
scrie
cod
nou
(înainte
de
dezvoltare).
Acest
lucru
ajută
la
evitarea

dublării codului atunci când scriem par
ț
i mici de cod pentru a trece testele.

Prin
combinarea
programării,
a
testării
unită
ț
ii
ș
i
a
refacerii,
dezvoltarea
bazată

pe
testare
este
o
practică
de
structurare
care
permite
ob
ț
inerea
unui
cod
curat,
u
ș
or
de

modificat
ș
i
de
răspuns
la
nevoile
exprimate,
care
rămân
prima
prioritate
în
dezvoltarea

unei aplica
ț
ii.

2

2. Principiile dezvoltării bazată pe

testare

Dezvoltarea bazată pe testare are 3 faze:

1.
Înainte
de
a
scrie
codul
de
implementare,
se
scrie
un
cod
care
să
demonstreze

că
implementarea
func
ț
ionează
sau
nu.
Se
urmăre
ș
te
testul
e
ș
uat
înainte
de
a

trece
la
pasul
următor,
acesta
este
modul
în
care
ș
tim
că
un
test
de
trecere
nu

este un fals pozitiv.

2.
Se
scrie
cât
mai
curând
posibil
codul
de
produc
ț
ie
suficient
pentru
a
trece
testul

unitar,
chiar
dacă
aceasta
înseamnă
a
permite
solu
ț
iile
cele
mai
slabe.
Desigur,

dacă
apare
imediat
o
solu
ț
ie
bună
ș
i
simplă,
trebuie
implementată,
dar
în
caz

contrar
nu
este
grav,
codul
va
fi
îmbunătă
ț
it
în
timpul
fazelor
de
refactorizare.

Scopul aici este de a ob
ț
ine cât mai curând posibil trecerea testelor unitare.

3.
Faza
de
refactorizare
este
adesea
neglijată,
dar
este
esen
ț
ială
deoarece
elimină

posibilele
duplicări
de
coduri,
dar
face
posibilă
ș
i
modificarea
arhitecturii,

factorizării,
prezentării.
Această
refactorizare
prive
ș
te
atât
codul
de
produc
ț
ie,
cât

ș
i
codul
de
testare
ș
i
nu
trebuie
să
modifice
comportamentul
extern
al

programului,
care
se
materializează
printr-o
bară
de
execu
ț
ie
a
testului
care

rămâne verde.

3

3. Ciclul dezvoltării bazată pe testare

1.
Adaugarea unui test.

În
dezvoltarea
bazată
pe
testare,
fiecare
caracteristică
nouă
începe
cu
scrierea

unui
test.
Pentru
a
scrie
un
test,
dezvoltatorul
trebuie
să
în
ț
eleagă
în
mod
clar

specifica
ț
iile
ș
i
cerin
ț
ele
func
ț
ionalită
ț
ii.
Dezvoltatorul
poate
scrie
testul
în
orice

framework
de
testare
adecvat
mediului
software.
Ar
putea
fi
o
versiune

modificată
a
unui
test
existent.
Aceasta
este
o
caracteristică
diferen
ț
iată
a

dezvoltării
bazată
pe
testare
fată
de
testarea
unitară
unde
testele
unitare
sunt

create
după
ce
codul
este
scris,
în
acest
mod
face
dezvoltatorul
să
se

concentreze
asupra
cerin
ț
elor
înainte
de
a
scrie
codul,
o
diferen
ț
ă
subtilă
dar

importantă.

2.
Se rulează toate testele
ș
i se observa dacă noul test e
ș
uează.

Aceasta
confirmă
faptul
că
testul
func
ț
ionează
corect,
arată
că
noul
test
nu
trece

fără
a
cere
un
nou
cod
deoarece
comportamentul
necesar
există
deja
ș
i
exclude

posibilitatea
ca
noul
test
să
e
ș
ueze,
prin
urmare
să
treacă
întotdeauna.
Noul
test

ar
trebui
să
e
ș
ueze
din
motive
justificate.
Acest
pas
cre
ș
te
încrederea

dezvoltatorului în noul test.

3.
Se scrie codul.

Următorul
pas
este
să
scrie
ț
i
un
cod
care
determină
trecerea
testului.
Noul
cod

scris
în
acest
stadiu
nu
este
perfect
ș
i
poate,
de
exemplu,
să
treacă
testul
într-un

mod
nu
tocmai
bun.
Acest
lucru
este
acceptabil
deoarece
va
fi
îmbunătă
ț
it
ș
i

ajustat la Pasul 5.

În
acest
moment,
singurul
scop
al
codului
scris
este
de
a
trece
testul.

Programatorul
nu
trebuie
să
scrie
cod
care
depă
ș
e
ș
te
func
ț
ionalitatea
pe
care

testul o verifică.

4.
Se rulează testele
ș
i se refactorizează codul.

Dacă
toate
cazurile
de
testare
trec
acum,
programatorul
poate
avea
încredere
că

noul
cod
îndepline
ș
te
cerin
ț
ele
de
testare
ș
i
nu
întrerupe
sau
degradează
nicio

func
ț
ionalitate
existentă.
În
caz
contrar,
noul
cod
trebuie
ajustat
până
când
o

face.
Codul
de
bază
care
cre
ș
tere
trebuie
să
fie
ajustat
în
mod
regulat
în
timpul

4

dezvoltării
bazată
pe
testare.
Codul
nou
poate
fi
mutat
de
unde
a
fost
convenabil

pentru
a
trece
un
test
într-un
loc
în
care
apar
ț
ine
din
punct
de
vedere
logic.

Duplicarea
trebuie
eliminată.
Numele
de
obiecte,
de
clase,
de
module,
de

variabile
ș
i
de
metode
ar
trebui
să
reprezinte
în
mod
clar
scopul
ș
i
utilizarea
lor,

deoarece
se
adaugă
func
ț
ionalită
ț
i
suplimentare.
Pe
măsură
ce
se
adaugă

func
ț
ionalită
ț
i
noi,
corpurile
metodelor
pot
deveni
mai
lungi
ș
i
alte
obiecte
mai

mari.
Ele
beneficiază
de
a
fi
împăr
ț
ite
ș
i
păr
ț
ile
lor
numite
cu
aten
ț
ie
pentru
a

îmbunătă
ț
i
lizibilitatea
ș
i
mentenabilitatea,
care
vor
deveni
din
ce
în
ce
mai

valoroase
ulterior
în
ciclul
de
via
ț
ă
al
software-ului.
Ierarhiile
de
mo
ș
tenire
pot
fi

rearanjate
pentru
a
fi
mai
logice
ș
i
mai
utile
ș
i,
probabil,
pentru
a
beneficia
de

modelele
recunoscute
de
design.
Există
instruc
ț
iuni
specifice
ș
i
generale
pentru

refactorizarea
ș
i
pentru
crearea
unui
cod
curat.
Prin
rerularea
continuă
a
testelor

pe
parcursul
fiecărei
faze
de
refactorizare,
dezvoltatorul
poate
fi
sigur
că

procesul nu modifică nicio func
ț
ie existentă.

Conceptul
de
eliminare
a
duplicării
este
un
aspect
important
al
oricărui
design

software.
În
acest
caz,
totu
ș
i,
se
aplică
ș
i
înlăturarea
oricărei
duplicări
între
codul

de
testare
ș
i
codul
de
produc
ț
ie,
de
exemplu,
numere
sau
stringuri
în
ambele

pentru a efectua testul de trecere în Pasul 3.

5.
Se repetă ciclul.

Începând
cu
un
alt
test
nou,
ciclul
se
repetă
pentru
a
avansa
func
ț
ionalitatea.

Dimensiunea
pa
ș
ilor
ar
trebui
să
fie
întotdeauna
mică,
cu
câte
1
până
la
10

editări
între
fiecare
test.
Dacă
noul
cod
nu
satisface
rapid
un
test
nou
sau
dacă

alte
teste
e
ș
uează
în
mod
nea
ș
teptat,
programatoru l
trebuie
să
anuleze
sau
să

revină
pentru
a
preveni
excesul
bugurilor.
Integrarea
continuă
ajută
la
furnizarea

unor
stări
la
care
se
poate
reveni.
Atunci
când
se
folosesc
biblioteci
externe,
este

important
să
nu
se
facă
modificări
atât
de
mici,
încât
să
nu
fie
testată
decat

librăria
în
sine,
cu
excep
ț
ia
cazului
în
care
există
vreun
motiv
să
creadă
că

biblioteca
are
probleme,
sau
nu
este
suficient
de
completă
pentru
a
servi
nevoile

software-ului aflat în curs de dezvoltare.

5

4. Dezvoltarea bazată pe testare
ș
i

testarea tradi
ț
ională

Abordarea
dezvoltării
bazată
pe
testare
este
în
primul
rând
o
tehnică
de

specificare. Se asigură că este testat temeinic codul sursă la nivel de confirmare.

Cu
ajutorul
testelor
tradi
ț
ionale,
un
test
de
succes
găse
ș
te
unul
sau
mai
multe

defecte.
Este
la
fel
ca
dezvoltarea
bazată
pe
testare.
Când
un
test
nu
reu
ș
e
ș
te,
a
ț
i
făcut

progrese, deoarece
ș
ti
ț
i că trebuie să rezolva
ț
i problema.

Dezvoltarea
bazată
pe
testare
vă
asigură
că
sistemul
dvs.
îndepline
ș
te

într-adevăr
cerin
ț
ele
definite
pentru
acesta.
Vă
ajută
să
vă
construi
ț
i
încrederea
în

sistemul dvs.

În
dezvoltarea
bazată
pe
testare
se
pune
mai
mult
accent
pe
codul
de
produc
ț
ie

care
verifică
dacă
testarea
va
func
ț
iona
corect.
În
cadrul
testelor
tradi
ț
ionale,
se
pune

mai
mult
accent
pe
proiectarea
cazurilor
de
testare.
Dacă
testul
va
arăta
executarea

corectă / necorespunzătoare a aplica
ț
iei pentru a îndeplini cerin
ț
ele.

În
dezvoltarea
bazată
pe
testare,
ob
ț
ine
ț
i
un
test
de
acoperire
de
100%.
Fiecare

linie de cod este testată, spre deosebire de testarea tradi
ț
ională.

Combina
ț
ia
dintre
testarea
tradi
ț
ională
ș
i
dezvoltarea
bazată
pe
testare
duce
la

importan
ț
a testării siste mului mai degrabă decât la perfec
ț
ionarea sistemului.

În
Agile
Modeling
(AM),
trebuie
"testat
cu
un
scop".
Trebuie
să
se
ș
tie
de
ce
se

testează ceva
ș
i ce nive l trebuie să fie testat.

6

5. Beneficii
ș
i avantaje

Un
studiu
din
2005
a
constatat
că
utilizarea
dezvoltării
bazată
pe
testare

însemna
scrierea
mai
multor
teste
ș
i,
la
rândul
lor,
programatorii
care
au
scris
mai
multe

teste
au
avut
tendin
ț
a
de
a
fi
mai
productivi.
Ipotezele
legate
de
calitatea
codului
ș
i
o

corela
ț
ie
mai
directă
între
dezvoltarea
bazată
pe
testare
ș
i
productivitate
au
fost

neconcludente.

Programatorii
care
folosesc
dezvoltarea
bazată
pe
testare
pe
proiecte
noi
au

raportat
că
au
sim
ț
it
rareori
nevoia
de
a
invoca
un
program
de
depanare.
Utilizat

împreună
cu
un
sistem
de
control
al
versiunilor,
atunci
când
testele
nu
reu
ș
esc
în
mod

nea
ș
teptat,
revenirea
codului
la
ultima
versiune
care
a
trecut
toate
testele
poate
fi

adesea mai productivă decât depanarea.

Dezvoltarea
bazată
pe
testare
oferă
mai
mult
decât
simpla
validare
a

corectitudinii,
dar
poate
conduce,
de
asemenea,
proiectarea
unui
program.

Concentrându-se
mai
întâi
pe
cazurile
de
testare,
trebuie
să
ne
imaginăm
cum

func
ț
ionalitatea
este
folosită
de
către
clien
ț
ii.
Deci,
programatorul
este
preocupat
mai

întâi
de
interfa
ț
a
decât
de
implementare.
Acest
beneficiu
este
complementar
proiectării

deoarece
abordează
codul
prin
intermediul
cazurilor
de
testare,
nu
prin
afirma
ț
ii
sau

preconcep
ț
ii matematic e.

Un
avantaj
semnificativ
al
dezvoltării
bazată
pe
testare
este
că
oferă
posibilitatea

de
a
face
pa
ș
i
mici
atunci
când
se
scriu
programe
software.
Acesta
permite
unui

programator
să
se
concentreze
asupra
sarcinii
la
îndemână,
deoarece
primul
obiectiv

este
de
a
trece
testul.
Cazurile
excep
ț
ionale
ș
i
tratarea
erorilor
nu
sunt
luate
în

considerare
ini
ț
ial,
iar
testele
de
creare
a
acestor
circumstan
ț
e
externe
sunt

implementate
separat.
Dezvoltarea
bazată
pe
testare
asigură
în
acest
fel
că
tot
codul

scris
este
acoperit
de
cel
pu
ț
in
un
test.
Aceasta
oferă
echipei
de
programare
ș
i

utilizatorilor ulteriori un nivel mai înalt de încredere în cod.

De
ș
i
este
adevă rat
că
este
necesar
să
se
scrie
mai
mult
cod
cu
dezvoltarea

bazată
pe
testare
decât
fără
din
cauza
codului
de
testare
unitar,
timpul
total
de

implementare
a
codului
ar
putea
fi
mai
scurt
pe
baza
unui
model
de
Müller
ș
i
Padberg.

7

Numărul
mare
de
teste
ajută
la
limitarea
numărului
de
defecte
din
cod.
Testarea
din

timp
ș
i
frecventă
ajută
la
detectarea
defectelor
la
începutul
ciclului
de
dezvoltare,

împiedicându-le
să
devină
probleme
endemice
ș
i
costisitoare.
Eliminarea
defectelor
la

începutul procesului evită, de obicei, depanarea lungă
ș
i întârziată a proiectului.

Dezvoltarea
bazată
pe
testare
poate
duce
la
un
cod
mai
modularizat,
flexibil
ș
i

extensibil.
Acest
efect
se
întâmplă
de
multe
ori
deoarece
metodologia
cere

dezvoltatorilor
să
se
gândească
la
software
în
termeni
de
unită
ț
i
mici
care
pot
fi
scrise
ș
i

testate
independent
ș
i
integrate
mai
târziu.
Acest
lucru
conduce
la
clase
mai
mici,
mai

concentrate,
mai
u
ș
or
de
cuplat
ș
i
interfe
ț
e
mai
curate.
Utilizarea
modelului
de
proiectare

mock
contribuie,
de
asemenea,
la
modularizarea
generală
a
codului,
deoarece
acest

model
necesită
scrierea
codului
astfel
încât
modulele
să
poată
fi
u
ș
or
schimbate
între

versiuni mock pentru testarea unită
ț
ii
ș
i versiuni "reale" pentru implementare.

Deoarece
nu
este
scris
cod
mai
mult
decât
este
necesar
pentru
a
trece
un
caz
de

testare
e
ș
uat,
testele
automate
tind
să
acopere
fiecare
parte
de
cod.
De
exemplu,

pentru
ca
un
dezvoltator
să
adauge
o
ramură
else
la
o
instruc
ț
iune
if
existentă,

dezvoltatorul
ar
trebui
mai
întâi
să
scrie
un
test
e
ș
uat
care
să
motiveze
ramura
else.
Ca

urmare,
testele
automate
rezultate
din
dezvoltarea
bazată
pe
testare
tind
să
fie
foarte

profunde:
ele
detectează
orice
schimbări
nea
ș
teptate
în
comportamentul
codului.
Acest

lucru
detectează
problemele
care
pot
apărea
în
cazul
în
care
o
modificare
ulterioară
în

ciclul de dezvoltare modifică în mod nea
ș
teptat alte func
ț
ionalită
ț
i.

Madeyski
a
furnizat
dovezi
empirice
printr-o
serie
de
experimente
de
laborator
cu

peste
200
de
dezvoltatori
privind
superioritatea
practicii
dezvoltării
bazată
pe
testare

fa
ț
ă
de
abordarea
tradi
ț
ională
sau
testarea
abordării
corectitudinii,
în
ceea
ce
prive
ș
te

cuplarea
mai
mică
dintre
obiecte
(CBO)
.
Dimensiunea
medie
a
efectului
reprezintă
un

efect
mediu
(dar
aproape
de
mare)
pe
baza
meta-analizării
experimentelor
efectuate,

care
este
o
constatare
substan
ț
ială.
Acesta
sugerează
o
modulare
mai
bună,

reutilizarea
ș
i
testarea
mai
u
ș
oară
a
produselor
software
dezvoltate
datorită
practicii
de

programare
bazată
pe
testare.
Madeyski
a
măsurat,
de
asemenea,
efectul
practicii

dezvoltării
bazată
pe
testare
asupra
testelor
unitare
folosind
branch
coverage
(BC)
ș
i

mutation
score
indicator(MSI),
care
sunt
indicatori
ai
eficacită
ț
ii
detectării
erorilor
la

testele unitare, respectiv.

Notificarea din timp a erorilor.

8

Dezvoltatorii
î
ș
i
testează
codul,
dar
în
lumea
bazelor
de
date,
acestea
sunt

adesea
testări
manuale
sau
scripturi
unice.
Folosind
dezvoltarea
bazată
pe
testare,

construie
ș
ti,
în
timp,
o
suită
de
teste
automate
pe
care
tu
ș
i
oricare
alt
dezvoltator
le
po
ț
i

refolosi după voin
ț
ă.

Un cod mai bine proiectat, mai curat
ș
i mai extensibil.

Aceasta
ajută
la
în
ț
elegerea
modului
în
care
va
fi
folosit
codul
ș
i
modul
în
care

acesta interac
ț
ionează cu alte module.

Rezultă o decizie de proiectare mai bună
ș
i un cod mai mentenabil.

Dezvoltarea
bazată
pe
testare
permite
scrierea
unui
cod
mai
mic
având
o

responsabilitate
unică,
mai
degrabă
decât
proceduri
monolitice
cu
responsabilită
ț
i

multiple. Acest lucru face ca codul să fie mai simplu de în
ț
eles.

Dezvoltarea
bazată
pe
testare
obligă,
de
asemenea,
să
se
scrie
doar
codul
de

produc
ț
ie pentru a trece testele pe baza cerin
ț
elor utilizatorului.

Încredere în refactorizare.

Dacă
se
refactorizeaza
codul,
pot
exista
posibilită
ț
i
de
breakpoint-uri
în
cod.

Deci,
având
un
set
de
teste
automate,
se
pot
remedia
aceste
breakpoint-uri
înainte
de

lansare.
Se
va
avertiza
corespunzător
dacă
se
vor
detecta
breakpoint-uri
în
cazul

utilizării testelor automate.

Folosind
programarea
bazată
pe
testare,
ar
trebui
să
rezulte
un
cod
mai
rapid
ș
i

mai extensibil, cu mai pu
ț
ine erori care pot fi actualizate cu riscuri minime.

Bună pentru munca în echipă

În
absen
ț
a
unui
membru
al
echipei,
al
ț
i
membri
ai
echipei
pot
continua
cu

u
ș
urin
ț
ă
să
lucreze
la
cod.
De
asemenea,
ajută
la
schimbu l
de
cuno
ș
tin
ț
e,
făcând
astfel

echipa mai eficientă în ansamblu.

Bun pentru dezvoltatori

De
ș
i
dezvoltator ii
trebuie
să-
ș
i
petreacă
mai
mult
timp
scriind
cazuri
de
testare,

este
nevoie
de
mult
mai
pu
ț
in
timp
pentru
depanarea
ș
i
dezvoltarea
de
noi

func
ț
ionalită
ț
i. Se scrie un cod mai curat, mai pu
ț
in complicat.

9

6. Limitări

Dezvoltarea
bazată
pe
testare
nu
efectuează
testări
suficiente
în
situa
ț
iile
în
care

sunt
necesare
teste
complet
func
ț
ionale
pentru
a
determina
trecerea
sau
e
ș
ecul,

datorită
utilizării
extinse
a
testelor
unitare.
Exemple
sunt
interfe
ț
ele
utilizatorilor,

programele
care
func
ț
ionează
cu
bazele
de
date
ș
i
unele
care
depind
de
configura
ț
ii

specifice
de
re
ț
ea.
Dezvoltarea
bazată
pe
testare
încurajează
dezvoltatorii
să
introducă

codul
minim
în
astfel
de
module
ș
i
să
maximizeze
logica
care
se
află
în
codul
de

bibliotecă testabil.

Suportul
managementului
este
esen
ț
ial.
Fără
ca
întreaga
organiza
ț
ie
sa
creadă

ca
dezvoltarea
bazată
pe
testare
va
îmbunătă
ț
i
produsul,
managementul
poate
sim
ț
i
că

timpul petrecut scriind testele este irosit.

Testele
unitare
create
într-un
mediu
de
dezvoltare
bazată
pe
testare
sunt
de

obicei
create
de
dezvoltatorul
care
scrie
codul
testat.
Prin
urmare,
testele
pot
duce
la

apari
ț
ia
diferitelor
probleme:
dacă,
de
exemplu,
un
dezvoltator
nu
î
ș
i
dă
seama
că

anumi
ț
i
parametri
de
intrare
trebuie
să
fie
verifica
ț
i,
cel
mai
probabil
nici
testul,
nici
codul

nu
vor
verifica
ace
ș
ti
parametri.
Un
alt
exemplu:
dacă
dezvoltatorul
interpretează
gre
ș
it

cerin
ț
ele
pentru
modulu l
pe
care
îl
dezvoltă,
codul
ș
i
testele
unitare
pe
care
le
scrie
vor
fi

ambele
gre
ș
ite
în
acela
ș
i
mod.
Prin
urmare,
testele
vor
trece,
dând
un
fals
sentiment
de

corectitudine.

Un
număr
mare
de
teste
unitare
care
trec
pot
aduce
un
sentiment
fals
de

securitate,
rezultând
mai
pu
ț
ine
activită
ț
i
suplimentare
de
testare
a
software-ului,
cum
ar

fi testarea de integrare
ș
i testarea conformită
ț
ii.

Testele
fac
parte
din
cheltuielile
de
între
ț
inere
ale
unui
proiect.
Testele
scrise

gre
ș
it,
de
exemplu
cele
care
includ
ș
iruri
de
erori
scrise
manual,
sunt
predispuse
la
e
ș
ec

ș
i
sunt
costisitoare
de
între
ț
inut.
Acest
lucru
este
valabi l
mai
ales
în
cazul
testelor

fragile.
Există
riscul
ca
testele
care
generează
în
mod
regulat
e
ș
ecuri
false
să
fie

ignorate,
astfel
încât
atunci
când
apare
un
e
ș
ec
real,
este
posibil
să
nu
fie
detectat.
Este

posibilă
scrierea
testelor
pentru
între
ț
inere
redusă
ș
i
u
ș
oară,
de
exemplu
prin
reutilizarea

10

ș
irurilor
de
eroare,
acest
lucru
ar
trebui
să
fie
un
obiectiv
principal
în
timpul
fazei
de

refactorizare a codului descrisă mai sus.

Scrierea
ș
i
men
ț
inerea
unui
număr
excesiv
de
teste
costă
timp.
De
asemenea,

modulele
mai
flexibile
(cu
teste
limitate)
ar
putea
accepta
noi
cerin
ț
e
fără
a
fi
nevoie
să

se
schimbe
testele.
Din
aceste
motive,
testarea
numai
pentru
condi
ț
ii
extreme
sau
o

mică parte de date poate fi mai u
ș
or de reglat decât un set de teste extrem de detaliate.

Nivelul
de
acoperire
ș
i
detaliile
de
testare
realizate
în
timpul
ciclurilor
repetate
de

dezvoltare
bazată
pe
testare
nu
pot
fi
u
ș
or
recreate
la
o
dată
ulterioară.
Prin
urmare,

aceste
teste
originale
devin
din
ce
în
ce
mai
pre
ț
ioase
pe
măsură
ce
trece
timpul.

Tactica
este
aceea
de
a
le
repara
cât
mai
devreme.
De
asemenea,
dacă
o
arhitectură

slabă,
un
design
slab
sau
o
strategie
slabă
de
testare
conduce
la
o
schimbare
târzie,

ceea
ce
face
ca
zeci
de
teste
existente
să
e
ș
ueze,
atunci
este
important
ca
acestea
să

fie
rezolvate
individual.
Simpla
ș
tergere,
dezactivarea
sau
modificarea
bruscă
a

acestora poate duce la goluri nedetectabile în acoperirea testului.

11

7. Vizibilitatea codului

În
proiectarea
orientată
pe
obiecte
acest
lucru
încă
nu
oferă
acces
la
date
ș
i

metode
private.
Prin
urmare,
pot
fi
necesare
lucrări
suplimentare
pentru
testele
unitare.

În
Java
ș
i
în
alte
limbi,
un
dezvoltator
poate
folosi
reflec
ț
ii
pentru
a
accesa
câmpuri
ș
i

metode
private.
Alternativ,
o
clasă
interioară
poate
fi
utilizată
pentru
a
ț
ine
testele

unitare,
astfel
încât
acestea
să
aibă
vizibilitate
asupra
membrilor
ș
i
atributelor
clasei
pe

care
o
înconjoară.
În
cadrul
.NET
Framework
ș
i
în
alte
limbaje
de
programare,
pot
fi

folosite clase par
ț
iale p entru a expune metode
ș
i date private pentru accesul testelor.

Este
important
ca
astfel
de
practici
de
testare
să
nu
rămână
în
codul
de

produc
ț
ie.
În
C
ș
i
în
alte
limbaje,
directivele
compilatoru lui,
cum
ar
fi
#if
DEBUG
…

#endif,
pot
fi
plasate
în
jurul
unor
astfel
de
clase
suplimentare
ș
i
toate
celelalte
coduri

legate
de
testare,
pentru
a
preveni
compilarea
acestora
în
codul
de
produc
ț
ie.
Aceasta

înseamnă
că
codul
de
produc
ț
ie
nu
este
exact
acela
ș
i
cu
cel
din
testele
unitare.

Func
ț
ionarea
regulată
a
testelor
de
integrare
mai
pu
ț
ine,
dar
mai
cuprinzătoare,
privind

construirea
versiunii
finale,
poate
asigura
(printre
altele)
că
nu
există
cod
de
produc
ț
ie

care să se bazeze subtil pe aspecte ale testării.

Există
o
dezbatere
printre
practican
ț
ii
dezvoltării
bazată
pe
testare,
documentate

în
blogurile
lor
ș
i
în
alte
scrieri,
dacă
este
în
ț
elept
să
testa
ț
i
metode
ș
i
date
private

oricum.
Unii
sus
ț
in
că
membrele
private
sunt
doar
ni
ș
te
detalii
de
implementare
care
se

pot
schimba
ș
i
ar
trebu i
să
li
se
permită
să
facă
acest
lucru
fără
a
întrerupe
numărul
de

teste.
Astfel,
ar
trebui
să
fie
suficient
să
testa
ț
i
orice
clasă
prin
interfa
ț
a
sa
publică
sau

prin
interfa
ț
a
sa
subcla să,
pe
care
unele
limbaje
o
numesc
interfa
ț
a
"protejată".
Al
ț
ii

spun
că
aspectele
cruciale
ale
func
ț
ionalită
ț
ii
pot
fi
implem entate
în
metode
private
ș
i

testarea
acestora
oferă
în
mod
direct
avantaje
ale
testelor
unitare
mai
mici
ș
i
mai

directe.

Dezvoltarea
bazată
pe
testare
nu
este
o
solu
ț
ie
minune
pentru
a
avea
o
suită

optimă
de
test
fără
efort.
Este
important
să
re
ț
inem
că,
în
cadrul
acestei
practici,
codul

de
test
este
la
fel
de
important
dacă
nu
mai
important
decât
codul
de
produc
ț
ie.

Îngrijirea
codului
de
testare
în
timp
este,
prin
urmare,
esen
ț
ială.
Pentru
a
fi
eficient,
un

12

test
trebuie
să
fie
curat,
caracterizat
prin
lizibilitatea
acestuia.
Aceasta
se
ob
ț
ine
prin

efectuarea
unui
test
simplu,
clar
ș
i
cât
mai
dens,
adică
făcându-l
să
con
ț
ină
cât
mai

multe
lucruri
posibil
într-un
minim
de
cod.
Astfel,
un
test
unitar
ar
trebui
să
reprezinte
un

singur concept
ș
i să con
ț
ină doar o singură afirma
ț
ie.

În cele din urmă, un test curat trebuie să urmeze 5 reguli:

1.
Să fie rapid: un test trebuie să fie rapid pentru a fi executat de multe ori.

2.
Independent: testele nu trebuie sa depindă unul de altul.

3.
Repetabil: un test trebuie să fie reproductibil în orice mediu.

4.
Validare
automată:
un
test
trebuie
să
aibă
un
rezultat
binar
(E
ș
uare
sau

Succes) pentru o concluzie rapidă
ș
i u
ș
oară.

5.
În
timp
util:
un
test
trebuie
scris
la
momentul
potrivit,
adică
chiar
înainte
de

codul de produc
ț
ie, acesta va fi validat.

13

8. Bibliografie

1.
https://en.wikipedia.org/wiki/Test-driven_development

2.

Introduction to Test Driven Development (TDD)

3.
https://hackernoon.com/introduction-to-test-driven-development-tdd-61a13bc92d
92

4.
https://www.guru99.com/test-driven-development.html

5.
https://medium.com/javascript-scene/tdd-changed-my-life-5af0ce099f80

6.
https://www.todaysoftmag.ro/article/387/test-driven-development-tdd

7.
https://medium.freecodecamp.org/test-driven-development-what-it-is-and-what-it-
is-not-41fa6bca02a2

14