Testarea programelor orientate pe obiecte

20 noiembrie 2014

Marius Minea

Testarea programelor orientate pe obiecte

Probleme n testarea orientat

a pe obiecte [Binder]
Fiecare nivel de ierarhie creeaz
a alt context pentru elementele mos, tenite:
corectitudinea superclasei nu garanteaz
a pe cea a clasei derivate

Se comport
a corect metodele superclasei n contextul subclasei?
Exemplu, pentru o clasa B care mos, teneste o metoda m din A
1. putem s
a omitem complet re-testarea lui B.m ?
2. sunt de ajuns cazurile de test pentru A.m ?
3. trebuie cazuri de test noi ? care ?

Marius Minea

Testarea programelor orientate pe obiecte

Liskov Substitution Principle

subclasa poate fi folosit
a oriunde in locul superclasei
pre(m, Class) pre(m, SubClass)
post(m, SubClass) post(m, Class)
inv(SubClass) inv(Class)
Dar: trebuie sa cunoas, tem invariantii pentru a-i verifica
Ca minim: analiz
am ce membri sunt modificati

Marius Minea

Testarea programelor orientate pe obiecte

Exemplul clasic dreptunghi - patrat

public class Rectangle {

private int height; private int width;
public void setHeight(int value) { this.height = value; }
public void setWidth(int value) { this.width = value; }
public int getArea() { return this.height * this.width; }
}
public class Square extends Rectangle {
public void setHeight(int value) { super.setHeight(value);
super.setWidth(value); }
public void setWidth(int value) { super.setWidth(value);
super.setHeight(value); }
}
Marius Minea

Testarea programelor orientate pe obiecte

Probleme n testarea orientat

a pe obiecte (cont.)
Interact, iunile dintre apeluri s, i starea obiectului sunt complexe
Exist
a interact, iuni nedorite ntre metode ?
Polimorfismul s, i legarea dinamic
a cresc num
arul de c
ai de execut, ie
ngreuneaz
a analiza static
a pentru determinarea c
ailor prin cod
void foo(A obj) { obj.m(); }
poate fi de fapt metoda m pentru oricare subclasa a lui A
Incapsularea limiteaz
a observabilitatea st
arii la testare
Legarea dinamic
a cres, te potent, ialul de nent, elegere s, i erori
Erori de interfat,
a sunt favorizate de existent, a multor componente mici
Controlul st
arii obiectelor e dificil, fiind distribuit n tot programul
Marius Minea

Testarea programelor orientate pe obiecte

Specific s, i probleme n testarea OO (cont.)

[McGregor&Sykes]

Datorate not, iunilor fundamentale de limbaj:

Obiecte
ascund informat, ia ngreuneaz
a observarea st
arii n testare
au stare persistent
a dac
a e inconsistent
a cauzeaz
a erori
au o durat
a de viat,
a erori prin construirea/distrugerea inoportun
a
Mesaje / metode importante n testarea interact, iunii obiectelor
pot fi apelate n st
ari nepotrivite ale obiectului
au parametri (folosit, i/actualizat, i): se afl
a n starea potrivit
a?
implementeaz
a corect interfet, ele dorite? (vezi probleme de subtip)
Interfat,
a
= specificat, ie comportamental
a
Dou
a abord
ari privind precondit, iile de funct, ionare corect
a:
bazat
a pe contract: le presupune / programare defensiv
a: le verific
a
influent, eaz
a complexitatea implement
arii s, i test
arii:
simplific
a/complic
a testarea clasei/testarea de integrare
Obs: programarea defensiv
a verific
a s, i rezultatele (des, i n practic
a
adesea serverul/receptorul e considerat de ncredere, doar clientul nu)
Marius Minea

Testarea programelor orientate pe obiecte

Specific s, i probleme n testarea OO (cont.)

Clasa
specificat, ie: pre/postcondit, ii de metode, invariant, i de clas
a testate!
Specificat, ia trebuie s, i ea validat
a !
implementare: potent, ial de erori prin:
Constructori/destructori (init, ializare/(de)alocare incorect
a)
Colaborare inter-clase: membri/parametri obiecte pot avea erori
Un client are mijloacele de a verifica precondit, iile necesare?
Mos, tenirea
Poate propaga erorile la descendent, i oprite prin testarea la timp
Impune aspectul tipic de cod OO (multe apeluri, put, ine prelucr
ari,
metode scurte) acoperirea de cod/decizie e put, in relevant
a
Ofer
a un mecanism de refolosire a testelor, din super- n subclas
a
Testarea poate detecta mos, tenirea doar pentru refolosirea codului
(f
ar
a a fi o specializare, adic
a a mos, teni specificat, a)
Marius Minea

Testarea programelor orientate pe obiecte

Specific s, i probleme n testarea OO (cont.)

Polimorfismul
Testarea trebuie s
a verifice principiul substitut, iei. In subclas
a
metodele au precondit, ii mai slabe/postcondit, ii mai puternice
invariantul implic
a cel al clasei de baz
a (e mai puternic)
Din perspectiva st
arilor observabile (prin program / test):
Subclasa p
astreaz
a toate st
arile observabile s, i tranzit, iile ntre ele
Poate ad
auga tranzit, ii (comportament suplimentar)
Poate ad
auga st
ari observabile ca sub-st
ari ale celor init, iale
Problema yo-yo: dificultatea nt, elegerii ( test
arii) secvent, ei de apeluri
eroare probabil
a: apelul versiunii gres, ite de metod
a din ierarhie
Abstract, ia n ierarhia de clase reflectat
a n teste (general specific)

Marius Minea

Testarea programelor orientate pe obiecte

Axiome de testare

[Weyuker 86,88], aplicate n contextul OO de [Perry & Kaiser 90]

Antiextensionalitate: Implement
ari diferite la aceeas, i funct, ionalitate
pot necesita suite de test diferite.
1) O metod
a redefinit
a necesit
a (s, i) alte teste (depinz
and de cod)
2) Aceeas, i metod
a mos, tenit
a necesit
a teste n funct, ie de clas
a!
Ex: A: +m(), +n()
B: +m()
C: +n()
s, i m apeleaz
a n()
C::m mos, tenes, te B::m dar apeleaz
a alt n() cere alte teste!
Antidecompozit, ie:
Un set de teste adecvat pentru un program nu e
neap
arat adecvat pentru o component
a a lui.
(ea poate fi exercitat
a n alt context dec
at programul respectiv)
Testarea adecvat
a a unui client nu e suficient
a pentru biblioteci
(clientul ar putea folosi doar o parte din funct, ionalitate)
Deriv
and dintr-o clas
a testat
a trebuie re-testate metodele mos, tenite
(codul ad
augat poate interact, iona cu starea cu metodele mos, tenite)
Marius Minea

Testarea programelor orientate pe obiecte

10

Axiome de testare (cont.)

Anticompozit, ie:
Un set de teste adecvat pentru componente nu e
neap
arat suficient pentru combinat, ia lor.
adev
arat
a s, i pentru combinat, ie secvent, ial
a:
p c
ai de test n P s, i q c
ai de test n Q produc p q > p + q c
ai n P ; Q
cu at
at mai mult c
and execut, ia alterneaz
a repetat ntre P s, i Q
Testarea de modul nu poate substitui testarea de integrare!
O metod
a testat
a n clasa de baz
a nu e suficient testat
a n clasa
derivat
a (pentru c
a poate fi compus
a n alte feluri)
General Multiple Change
Programe care au acelas, i flux de control
dar alte valori / operat, ii necesit
a suite de test diferite.

Marius Minea

Testarea programelor orientate pe obiecte

11

Exemple de erori: Incapsulare

Exemplu: clas
a mult, ime cu metode de
add(element) // precondit, ie: element nu e n mult, ime
// genereaz
a except, ie Duplicate n caz contrar
remove(element)
Testare: dou
a add(x) consecutive genereaz
a except, ie
dar totus, i elementul poate fi ad
augat a doua oar
a
eroare descoperit
a doar cu 2 add, 2 remove
mai dificil dec
at dac
a starea obiectului ar fi direct observabil
a

Marius Minea

Testarea programelor orientate pe obiecte

12

Exemple de erori: Mos, tenire

Problema: n realizarea unei clase trebuie nt, elese detaliile s, i convent, iile
de reprezentare ale tuturor claselor de baz
a pentru a fi siguri de o
implementare corect
a.
Mos, tenirea sl
abes, te ncapsularea
Dou
a clase mari de probleme:
1) init, ializarea
dac
a se uit
a execut, ia corect
a a init, ializ
arii pentru superclas
a
2) omiterea redefinirii unor metode t, in
and cont de specificul clasei
metode de copiere, sau isEqual

Marius Minea

Testarea programelor orientate pe obiecte

13

Acoperirea n testarea OO

Consider
am un apel de metod
a n cod:
target-methods criterion: toate implement
arile de metod
a apelabile
receiver-classes criterion: toate variantele pentru clasa receptor
Exemplu [Rountev, Milanova, Ryder 2004]
class A { public void m() { ... } }
class B extends A { public void m() { ... } }
class C extends A { ... }
A a;
...
a.m();
target-methods:
testeaz
a apeluri la A.m();, B.m()
receiver-classes (mai cuprinz
ator): testeaz
a a de tip A, B, C
Marius Minea

Testarea programelor orientate pe obiecte

14

Modele de eroare n testarea OO [Offutt]

Folosire inconsistent
a ca tip
Deriv e folosit
a inconsistent s, i ca Base (chiar f
ar
a redefiniri)
Ex: Stack (acces la un cap
at) implementat din Vector (acces arbitrar)
folosirea Vector::removeAt(idx) pe Stack violeaz
a invariantul clasei
Cauza: eroare de proiectare. Detect, ie: testarea invariant, ilor de clas
a
Erori de definit, ie de stare
1) Metodele derivate interact, ioneaz
a diferit cu starea obiectului
Detect, ie: verificare c
a metodele definesc/folosesc aceias, i membri
2) Redefinirea local
a a unui membru (ascunde membru omonim mos, tenit)
dar metodele mos, tenite acceseaz
a membrul vechi inconsistent,
a
3) Metod
a redefinit
a face alt calcul asupra aceluias, i membru
inconsistent,
a a st
arii n raport cu specificat, ia (mos, tenit
a)
Erori de constructor
Apel virtual n constructor n derivat, acces la stare neinit, ializat
a
... s, i altele (anomalii de vizibilitate, etc.)
Marius Minea

Testarea programelor orientate pe obiecte

Particularit
at, i ale test
arii OO

15

Nivele: intra- s, i inter-metod

a, intra- s, i inter-clas
a
Problema vizibilit
at, ii (limitat
a de ncapsulare):
expandarea explicit
a n surs
a a ierarhiei de clase (flattening)
suport de limbaj/implementare pentru accesul de c
atre clasa de test
folosirea de metode accesor pentru observarea st
arii
Polimorfismul: necesit
a instant, ierea prin test a tuturor subtipurilor
posibile pentru un obiect declarat dintr-un tip de baz
a
analiz
a static
a pentru determinarea tuturor posibilit
at, ilor
Testarea bazat
a pe flux de date
Sunt importante datele transmise/starea modificat
a; acoperirea de
cod/decizie d
a informat, ie redus
a pe corpuri mici de metod
a
Cuplajul: definit prin perechi def-use ntre metode
i.e. un membru definit(scris) n m1() s, i folosit(citit) n m2()
folosit pentru a selecta metodele care sunt testate mpreun
a
Marius Minea

Testarea programelor orientate pe obiecte

16

Testarea ierarhiilor de clase

Distingem: teste pornind de la specificat, ie sau implementare (cod)
S: noi teste pentru metode vechi, la modificarea specificat, iei
S: postcondit, ii/invariant, i noi pentru teste vechi, n clase derivate
I: noi teste pentru metode noi, n funct, ie de criteriul de acoperire dorit
Exemple:
Modificare m() n superclas
a: re-testare m() + metode dependente;
re-testare m() n contextul subclaselor
Modificare subclas
a: retestare metode mos, tenite care pot interact, iona
Suprascriere m(): augmentare teste Base::m pt. acoperire adecvat
a
Suprascriere m() folosit
a de Base::n: test n n subclas
a
Modificare interfat,
a (clas
a abstract
a): retestarea ntregii ierarhii!
Marius Minea

Testarea programelor orientate pe obiecte

17

Tipare de testare OO [Binder]

La nivel de metod
a
Category/Partition (analiz
a I/O, partit, ionare/echivalent,
a)
Combinational Function Test (acoperire a condit, iilor)
Recursive Function Test
Polymorphic Message Test (client al unui server polimorfic)
La nivel de clas
a
Invariant Boundaries
Nonmodal Class Test (clas
a f
ar
a constr
angeri de secvent, iere)
Modal Class Test (clas
a cu constr
angeri de secvent, iere)
Quasi-Modal Class Test (constr
angeri dependente de stare)
Pentru componente reutilizabile
Abstract Class Test (interfat,
a)
Generic Class Test (parametrizat
a)
New Framework Test
Popular Framework Test (modific
ari n cadru de aplicat, ie intens folosit)
Marius Minea

Testarea programelor orientate pe obiecte

18

Exemplu: Polymorphic Message Test

Pentru un apel de metod
a virtual
a (ntr-un client), testeaz
a toate
clasele posibile la care s-ar putea face apelul
Necesitate / erori posibile:
precondit, ii incorecte de apel pentru anumite subclase
apel (prin pointer incorect) la clasa neintentionata
modificarea ierarhiei de clase
Procesul de legare dinamic
a ' ramificare n cod
acoperirea tuturor instant, elor posibile ' branch coverage

Marius Minea

Testarea programelor orientate pe obiecte

19

Nonmodal Class Test

clas
a ne-modal
a = accept
a orice mesaj (apel) n orice stare
ex. DateTime accept
a orice secvent,
a de get/set (use/def)
Tipuri de comportament de test
define-operation: set pentru intrare valid
a / verific
a r
aspuns
define-exception: set pentru intrare invalid
a / verific
a r
aspuns
define-exception-corruption: stare nu e corupt
a dup
a except, ie
use-exception-test: se revine normal dup
a utilizare
use-correct-return: se revine cu valoarea corect
a dup
a utilizare
use-corruption: obiectul nu e corupt dup
a utilizare

Marius Minea

Testarea programelor orientate pe obiecte

20

(Quasi-)Modal Class Test

Modal Class Test:
clas
a cu constr
angeri permanente/fixe privind ordinea operat, iilor
se creeaz
a un model cu st
arile obiectului s, i tranzit, iile ntre ele
Probleme:
tranzit, ie lips
a: o operat, ie e respins
a ntr-o stare valid
a
act, iune incorect
a: r
aspuns incorect pentru stare/metod
a dat
a
stare rezultant
a invalid
a: metoda produce tranzit, ie n stare incorect
a
stare rezultant
a corupt
a
mesaj acceptat c
and ar trebui respins
Quasi-modal class test
clas
a unde constr
angerile la mesaje se schimb
a odat
a cu starea clasei
ex. clasele de tip container / colect, ie (stiv
a plin
a/goal
a, etc.)
Tipic: am dori acoperire tip N+ (orice mesaj n orice stare)
Marius Minea

Testarea programelor orientate pe obiecte

21

Testarea la nivel de clas

a
Abordarea Small Pop
scriere clas
a, scriere teste, rulare (f
ar
a alte detalieri/intermedieri)
valabil
a pentru clase simple n contexte stabile
Abordarea Alpha-Omega se trece obiectul de la creare la distrugere,
prin fiecare metod
a
constructori
accesori (get)
predicate
modificatori (set)
iteratori
destructori

Marius Minea