1. TESTAREA PROGRAMELOR OO

1.1. INTRODUCERE N TESTAREA POO

Introducere n testare Testarea software este o etap important i plin de provocri din dezvoltarea programelor. n cadrul acestui proces sunt descoperite evidene ale defectelor i se verific dac programul este conform cu specificaiile. Testarea nu trebuie confundat cu depanarea, -care implic descoperirea surselor erorilor-, i nici cu etapa de corectare a erorilor.

Testarea este o parte necesar (dar insuficient) din asigurarea calitii programelor. Asigurarea calitii cuprinde activiti destinate prevenirii i nlturrii defectelor, iar testarea poate contribui la mbuntirea calitii prin identificarea problemelor devreme n procesul de dezvoltare, nainte de scrierea codului. Testarea nainte de scrierea codului presupune o munc mai strns a dezvoltatorilor cu testerii i viceversa.

Perspectiva testrii este atitudinea testerului, care are sarcina dificil de a pune sub semnul ntrebrii toate aspectele legate de softul testat. Fr a citi codul, un tester trebuie s anticipeze greelile i optimizrile pe care le poate face un dezvoltator i apoi s construiasc teste pentru detectarea acestora. De aceea, n multe privine, a fi un tester bun este mai dificil dect a fi un dezvoltator bun, ntruct testarea solicit o bun nelegere a procesului de dezvoltare i a produselor sale dar i abilitatea de anticipa erori posibile. Cutarea greelilor trebuie ghidat att de cutarea sistematic, ct i de intuiie iar scopul final este de a demonstra faptul c un soft se comport conform specificaiei sale, i nu execut nimic din ceea ce nu i se cere s execute.

Importana testarii rezid nu doar din faptul c aceasta ofer o asigurare c un sistem software face ceea ce trebuie s fac (i nimic n plus) dar i din asigurarea utilizatorilor mpotriva cderilor programului ce pot duce la pierderi de timp, proprieti, clieni, sau chiar viei. Scopul procesului este scrierea de programe mai mentenabile, reutilizabile, flexibile, etc.

Ne vom ocupa n cadrul primului capitol de testarea sistemelor orientate obiect, structurate pe componente. Acestea au avantajul c testarea poate ncepe din timpul dezvoltrii sistemului (testarea modelelor de analiz i design) ceea ce reduce costurile i sporete eficiena. Vom urmri ce, cnd i cum testm n programele orientate obiect, comparativ cu testarea procedural (spre exemplu, motenirea i polimorfismul introduc noi provocri testerilor), i vom presupune ca procesul de dezvoltare al programului este incremental.

Noiunile de testare prezentate sunt utile programatorilor, -care deja testeaz software, dar vor s cunoasc mai multe despre testarea programelor orientate obiect; dar i managerilor- responsabili cu dezvoltarea software, care doresc s tie cum i unde testarea se ncadreaz n planul global. De asemenea, dezvoltatorii sunt rspunztori cu testarea programelor pe care le produc, i trebuie s considere testarea n timpul analizei, design-ului i activitilor de implementare.

Scenariul de dezvoltare software Vom presupune n continuare ca procesul este incremental, cu iteraii la fiecare etap (increment) (modificri n modul de dezvoltare a programului introduc implicit modificri n maniera de testare). n plus, vom considera i c dispunem de modelele software n UML, i

c design-ul software respect principiile unui design de calitate, n ceea ce privete motenirea, ascunderea datelor, abstractizarea, cuplajul slab i coeziunea ridicat.

Reprezentrile software pe care se va face testarea vor fi atat codul surs al programului i fiierele de date ct i modelele create n cadrul etapelor de analiz i design.

Programarea orientat pe obiecte Spre deosebire de programarea procedural, programarea orientat pe obiecte focalizeaz obiectele, nu funciile ce transform intrrile n ieiri. Un program orientat obiect este o mulime de obiecte ce modeleaz o problem i colaboreaz pentru a produce o soluie. Conceptul din spatele acestei abordri este c structura i componentele unei probleme nu se vor schimba frecvent n timp, dar soluia problemei- da. n consecin, un program structurat dup problem (nu dup o soluie imediat) va fi mai adaptabil modificrilor ulterioare. n plus, un programator familiar cu problema poate recunoate uor componentele n software, deci programul este mai mentenabil, iar componentele fiind derivate direct din problem, pot fi reutilizate n dezvoltarea altor probleme similare.

Avantajul principal al programelor orientate obiect este c ne pun la dispoziie modelul de analiz i cel de design, naintea implementrii (codului), deci se poate ncepe testarea nc din timpul analizei. Testele pentru analiz se rafineaz apoi n teste pentru design, care se rafineaz, la rndul lor, n teste ale implementrii, deci testarea se poate ntreptrunde cu procesul de dezvoltare.

Testarea modelelor de analiz i design are multiple avantaje. n primul rnd, cazurile de test se pot identifica devreme, chiar odat cu determinarea cerinelor, i aceast testare timpurie ajut analitii i design-erii s neleag i s exprime mai bine cerinele, i s se asigure c cerinele specificate sunt testabile. n al doilea rnd, erorile se pot detecta devreme n procesul de dezvoltare, economisind timp, bani i efort (de ce problemele sunt descoperite mai rapid, vor fi mai uor i mai ieftin de reparat). n fine, un alt avantaj este c testarea modelului asigur ca testerii i dezvoltatorii s aib o nelegere consistent a cerinelor sistemului. ntruct testarea trebuie adaptat criteriilor de calitate solicitate, dac o companie i propune s creeze software reutilizabil i design-uri extensibile, atunci la testare trebuie depistate problemele prin prisma acestor obiective. Tehnicile tradiionale de testare nu sunt potrivite cu obiectivele de mai sus.

n abordarea prezent vom considera c testarea este un proces separat de procesul de dezvoltare, dar relaionat cu el i ne vom ghida dup principiul: Testeaz devreme. Testeaz des. Testeaz suficient. De asemenea, procesul de dezvoltare va fi unul iterativ, bazat pe repetarea urmatorilor pasi:

1. Analizeaz puin. 2. Creeaz puin din design. 3. Implementeaz puin. 4. Testeaz ce poi.

(Testeaz ce poi include ceea ce poi tehnic face, n condiiile constrngerilor de timp i resurse).

Un avantaj al sistemelor dezvoltate incremental este faptul c testarea se poate face la sfritul fiecrei etape. Pentru un program orientat obiect exista urmtoarele tipuri de testri:

Testarea modelului Testarea claselor Testarea interaciunilor Testarea sistemului (i subsistemelor) Testarea acceptrii Testarea n situaii finale

Testarea software este de obicei o combinaie de inspecii, revizii, si execuii de teste desfurate cu scopul de a observa eventuale erori.

Inspeciile sunt examinri ale programului pe baza unei liste de probleme tipice (semantica limbajului de programare, conveniile de implementare- de exemplu, asigurarea c fiecare variabil este iniializat nainte de prima utilizare/ c fiecare pointer refer o locaie corect etc.) Compilatoarele moderne pentru limbaje OO pot detecta multe probleme de pe listele tradiionale pentru inspecii.

Reviziile sunt examinri ale programului cu scopul de a gsi erori, nainte de executarea sa, ce se desfoar n cursul dezvoltrii software, analiznd dac nelesul fiecrei pri de program satisface cerinele aplicaiei. Scopul unei revizii este de a descoperi erori de genul cerine greit nelese sau probleme n logica programului; unele revizii pot verifica dac algoritmii sunt att de eficieni pe ct pot fi, dac numele de variabile sunt alese inspirat, etc.

Execuiile de test presupun testarea software n contextul unui program care ruleaz. Prin executarea programului, testerul ncearc s determine dac programul are comportamentul dorit, prin perechi de date intrare-ieire verificate. Problemele acestui tip de testare constau n determinarea acelor intrri ce pot duce la erori, n calcularea ieirilor corecte pentru intrri date i n determinarea unui mod de observare a ieirilor. Ne vom concentra n acest curs pe acest tip de testare, dar ideea de execuie va fi extins pentru a include i execuia simbolic a reprezentrilor non-executabile ale unui sistem.

Perspectiva testrii poate fi: Sceptic: solicit dovada calitii; Obiectiv: nu presupune nimic; Contiincioas: nu scap ariile importante; Sistematic: se pot reproduce cutrile efectuate.

Exerciiu

1. Considerai o aplicaie ce va fi folosit pentru a programa slile de conferin dintr-o cldire. Aplicaia are o IUG ce permite utilizatorului s indice data, ora, i durata (n incremente de 15 minute). Apoi afieaz o list cu slile de conferin disponibile la ora respectiv i permite rezervarea unei sli.

Sistemul permite i anularea unei rezervri. Proiectul trebuie dezvoltat incremental adic, n etape cresctoare de funcionalitate. Considerai urmtoarele dou planuri. Care va reui mai bine? Ce testare se poate face la sfritul fiecrui increment?

Plan A Plan B

Increment 1: Crearea interfeei grafice;

Increment 2: Crearea subsistemului de stocare a datelor;

Increment 3: Dezvoltarea subsistemului aplicaie (rezervrile).

Increment 1: Dezvoltarea capacitii de a introduce data, ora, durata, i afiarea disponibilitii slilor;

Increment 2: Dezvoltarea capacitii de a rezerva o camer;

Increment 3: Dezvoltarea capacitii de a anula o rezervare.

Programele Orientate Obiect din perspectiva testrii

Conceptele de baz ale POO sunt Obiectul, Mesajul, Interfaa, Clasa, Motenirea, Polimorfismul. Le vom analiza pe fiecare din perspectiva testrii.

1. Obiectul este o entitate operaional-computational de baz ntr-un program OO, ce ncapsuleaz att valori specifice ale datelor ct i codul ce opereaz asupra acestor valori. Un program OO este o comunitate de obiecte ce coopereaz pentru a rezolva o problem. Un principiu GOOD ne spune ca un obiect trebuie s fie o reprezentare a unei entiti specifice din cadrul problemei sau al soluiei. Din prisma testrii, trebuie verificat dac un obiect se comport conform specificaiei, i dac interacioneaz corect cu alte obiecte n timpul execuiei.

Ciclul de via al unui obiect ncepe la crearea obiectului, trece printr-o succesiune de stri i sfrete la distrugerea obiectului. Starea corect a unui obiect depinde de vrsta sa, o stare inconsistent, crearea tardiv sau distrugerea prea timpurie a obiectelor fiind surse uzuale de erori. Orice obiect ncapsuleaz date i prin aceasta, el este uor de manevrat i identificat n cadrul sistemului, dar ascunderea informatiilor poate ngreuna testarea, ntruct unele modificri ale obiectului nu sunt vizibile.

2. Mesajele reprezinta cereri ca anumite operaii s fie executate de obiecte. Un mesaj include numele operaiei si lista de parametri actuali. n C++ mesajul este apelul unei funcii membru, iar n Java mesajul este invocarea unei metode.Colaborarea ntre obiecte se realizeaz prin transmiterea de mesaje (Figura).

Figura

emitor receptor

mesaj

Valoare ntoars/ exceptie

Din perspectiva testrii orice mesaj are un emitor -care decide cnd trimite mesajul, i poate grei n aceasta decizie i orice mesaj are un receptor -care poate nu este (nc) pregtit pentru mesajul primit. n plus, orice mesaj poate include parametri actuali, folosii de receptor n prelucrarea mesajului. Obiectele folosite ca parametri trebuie s se afle n starea corect nainte (i dup) procesarea mesajului, i trebuie s implementeze interfaa ateptat de receptor.

3. Interfaa este o agregare de declaraii de comportament, nrudite n raport cu un anumit concept. O interfa este un set constructiv pentru specificaii, ce definete mulimea complet a comportamentelor publice ale unei clase. n Java exist conceptual dedicat de interface, iar n C++ o interfa este o clas de baz abstract, doar cu metode pur virtuale, publice. Interfeele ncapsuleaz specificaii de operaii, specificaii ce vor sta la baza construirii de clase; i dac interfaa cuprinde comportamente nerelaionate cu ansamblul, implementarea va avea un design nesatisfcator. Interfaa trebuie privit i prin prisma relaiilor sale cu alte interfee/ clase: ea se poate specifica drept tipul unui parametru al unui comportament, pentru a permite ca orice implementator al interfeei s fie folosit ca parametru.

4. Clasa reprezint o mulime de obiecte cu aceeai baz conceptual, constituind un element de baz n definirea programelor orientate-obiect, n timp ce obiectele sunt elemente de baz n executarea programelor orientate-obiect. Crearea de obiecte definite de o anumit clas se numeste instaniere (un obiect este o instan a unei clase). Specificaia unei clase definete ce poate s fac fiecare obiect al clasei, iar implementarea clasei descrie cum face fiecare obiect ceea ce face. n C++ fiierele header (.h) descriu specificaia, iar fiierele surs (.cpp) conin implementarea (Figura). n Java, dei specificaia i implementarea sunt n acelai fiier, exist totui o separaie logic ntre ce i cum.

Figura. Header (CE?) / sursa (CUM?)

Clasele statice. Din perspectiva testrii, o clas cu membri statici trebuie tratat ca un obiect, i trebuie creat o succesiune de teste att pentru clas n sine, ct i pentru instanele sale. Trebuie s fim ntotdeauna sceptici n legtur cu datele statice, non-constante, asociate cu o clas, deoarece acestea pot afecta comportamentul instanelor.

I. Specificaia unei clase definete ce reprezint clasa, ce poate o instan a clasei s fac, si include cte o specificaie pentru fiecare operaie a clasei.

Operaie = aciune ce poate fi aplicat unui obiect, cu un anumit efect. Operatiile se clasifica n:

Operaii inspector (accesator)- care furnizeaz informaii despre obiecte, fr a le modifica (valori ale unor date membru, starea obiectului etc.). (n C++ ele trebuie declarate const);

Operaii modificatoare- care schimb starea unui obiect prin modificarea valorii unor atribute ale obiectului

Testarea operaiilor inspector difer de a operaiilor modificator. Exist operaii care sunt i inspectori, i modificatori, i operaii care execut modificri doar n anumite condiii, i pe care le vom clasifica drept operaii modificator. Este o bun decizie de design OO ca o operaie s fie ori modificator, ori inspector, dar nu ambele n acelai timp, acest aspect uurnd testarea. Constructorii (ce iniializeaz instane noi) i destructorii (care efectueaz procesrile necesare nainte de sfritul vieii obiectului) sunt diferii de accesatori i modificatori prin faptul c sunt implicit invocai la crearea/ distrugerea obiectelor (unele invocri sunt vizibile n program, unele nu).

Exemplu: X=a+b+c Tmp1=a+b; Tmp2=tmp1+c; X=tmp2

Specificarea operaiilor. Fiecare operaie din specificaia clasei trebuie s aib ataate un neles i nite constrngeri (fiecare operaie s aib o specificaie care descrie ce face aceasta). O bun specificare a semanticii operaiilor este critic att pentru dezvoltare ct i pentru testare. Semantica trebuie specificat n diferite puncte:

Precondiii Postcondiii Invariani

Precondiiile unei operaii descriu condiii ce trebuie s fie ndeplinite nainte ca operaia s se poat executa, si se exprim n termenii atributelor obiectului ce conine operaia i/sau atributelor parametrilor actuali ai mesajelor ce solicit executarea operaiei.

Postcondiiile unei operaii descriu condiii ce trebuie s fie ndeplinite dup execuia operaiei, i se exprim n termeni de:

atributele obiectului ce conine operaia; atributele parametrilor actuali ai mesajului ce solicit execuia operaiei; o valoare de rspuns a operaiei i/sau excepiile ce pot apare

Invarianii descriu condiii ce trebuie ndeplinite constant pe parcursul duratei de via a obiectului. Un invariant de clas descrie o mulime de granie operaionale pentru o instan a unei clase, fiind o postcondiie implicit pentru fiecare operaie (dar invarianii pot fi nclcai n timpul execuiei). Acetia se pot exprima n termeni de atribute/stri ale obiectului.

Specificarea operaiilor in OCL. Dac diagramele de clase definesc clasele (atribute i operaii), iar diagramele de stare ilustreaz comportamentul unei instane a clasei, specificarea semanticii operaiilor se poate face cu un limbaj special: Object Constraint Language (OCL)- Limbajul Constrngerilor Obiectuale. Constrngerile OCL se exprim n contextul unei diagrame de clase, i implic atribute, operaii i asocieri definite n diagram. Semantica operaiilor este descris n termeni de precondiii i postcondiii (Figura). Condiiile invariante pentru o clas (interfa) trebuie s fie ndeplinite la nceputul i la finalul oricrei operaii. O bun specificare a unei operaii este absolut necesar pentru testare (este imposibil s testezi un cod cu scop vag sau ambiguu). Existena unor astfel de specificaii mbuntete i calitatea codului (inclusiv reutilizabilitatea claselor).

Figura . OCL pentru operaiile clasei PuckSupply

Vom descrie n continuare dou tehnici de design a claselor prin prisma precondiiilor i a postcondiiilor: programarea contractual (care accentueaz precondiiile dar are postcondiii mai simple) i programarea defensiv care este reversul primeia.

Programarea contractual. n aceast tehnic de design propus de Bertrand Meyer, o interfa se definete n termenii obligaiilor primitorului/ transmitorului implicai ntr-o interaciune. Astfel:

Precondiiile descriu obligaiile transmitorului (nainte ca transmitorul s fac o cerere primitorului, transmitorul trebuie s se asigure c precondiiile sunt ndeplinite). Cnd construim design-ul interfeei unei clase, precondiiile trebuie s fie suficiente pentru: o a permite primitorului s ajung la postcondiii; o a permite transmitorului s determine dac toate precondiiile sunt ndeplinite

nainte de trimiterea unui mesaj.

Postcondiiile descriu obligaiile primitorului (care trebuie s verifice c acestea sunt ndeplinite). Trebuie ca postcondiiile s acopere toate ieirile posibile ale unei operaii, n ipoteza c precondiiile sunt ndeplinite.

Este util s definim metode accesor pentru verificarea condiiilor.

Programarea defensiv. n acest caz, interfaa se definete n primul rnd din perspectiva primitorului, i a presupunerilor fcute de acesta asupra strii sale, i asupra valorii intrrilor (argumente sau valori de date globale), la momentul cererii. Operaiile ntorc o indicaie asupra strii cererii: succes/ eec pentru un anumit motiv (valoare de intrare greit). Scopul principal al programrii defensive este s determine garbage in pentru a elimina garbage out. Dezavantajele acestei abordri sunt:

mrete complexitatea software: transmitorul trebuie s corecteze n funcie de ieirile posibile ale operaiei (lipsa de ncredere nu poate fi doar de partea primitorului, ci i a transmitorului -care verific ieirile operaiei);

Crete dimensiunea codului i a timpului de execuie.

n concluzie, programarea defensiv reflect o lips de ncredere a transmitorului fa de primitor, iar n programarea contractual, responsabilitatea e mprit mutual ntre transmitor i primitor (primitorul proceseaz o cerere pe baza unor intrri presupuse a ndeplini precondiiile, iar transmitorul presupune postcondiiile ndeplinite dup procesarea cererii). Cele dou tehnici se pot combina. Design-ul interfeelor prin programare contractual elimin necesitatea ca primitorul s verifice precondiiile deci programarea contractual este mai eficient din perspectiva programului i programatorului, dar dezavantajul este ca n contextul execuiei programului, nu putem fi siguri de respectarea contractului. Aadar, trebuie ca toate interaciunile s fie testate n programarea contractual.

Deci, prin prisma testrii, programarea contractual simplific testarea claselor dar complic testarea interaciunilor (trebuie s ne asigurm c fiecare transmitor ndeplinete precondiiile), n timp ce programarea defensiv complic testarea claselor (cazurile de test trebuie s acopere toate rezultatele posibile) dar i testarea interaciunilor (trebuie s ne asigurm c se produc toate rezultatele posibile i c sunt tratate corect de transmitor).

O idee ce vine n sprijinul testrii este aceea de a verifica din timpul design-ului dac precondiiile, postcondiiile i invarianii sunt testabili:

Sunt constrngerile exprimate clar? Specificaia include metode de verificare a precondiiilor?

Din perspectiva testrii, n programarea contractual trebuie testate doar situaiile n care precondiiile sunt satisfcute, iar n programarea defensiv trebuie s testm fiecare intrare posibil pentru a verifica dac ieirea este tratat corespunztor.

Figura Specificaia clasei PuckSupply n programarea prin contract

Figura .Specificaia clasei PuckSupply n programarea defensiv

Specificaiile operaiilor unei clase descriu comportamentul clasei respective. o descriere mai complex a comportamentului unei clase gsim n diagramele de stare (UML), alctuite din stri i tranziii, n care este descris cum afecteaz diversele operaii tranziia dintr-o stare n alta. Spre exemplu, clasa PuckSupply poate trece prin dou stri :empty, non-empty (n funcie de valorile unui anumit atribut al clasei: size).

II. Implementarea claselor cuprinde definirea valorilor atributelor (datelor membru, variabilelor), scrierea codului funciilor membru/ metodelor i a constructorilor i destructorilor. Iat cteva surse uzuale de erori n implementarea claselor :

Atributele noilor instane nu sunt iniializate corect

n colaborarea cu alte clase n implementarea codului unei clase, dac acele clase nu sunt implementate corect, aceasta duce la erori n codul clasei care le-a folosit n definiia sa

Implementarea clasei satisface specificaia, dar nu avem garania c specificaia este corect

Implementarea nu conine toate operaiile sau definete incorect operaiile

Clasa nu ofer o modalitate de verificare a precondiiilor de ctre transmitor.

5. Motenirea permite refolosirea specificaiei i implementrii unei clase pre-existente (superclas/ clas de baz) de ctre o subclas/ clas derivat. Relaia de motenire este ierarhic, un arbore cu descendeni i ancestori. Un principiu GOOD spune motenirea ar trebui folosit doar pentru implementarea relaiilor de tip este-un / este-un-fel-de (principiul substituiei prezentat mai jos ne va explica de ce). Din perspectiva testrii, ntr-o relaie de motenire erorile se propag de la o clas la descendenii si. Acest lucru poate fi prevenit prin testarea unei clase imediat ce a fost dezvoltat. Avantajul motenirii const n faptul c permite reutilizarea cazurilor de test (de la clasa de baz la derivate).

6. Polimorfismul este abilitatea de a trata un obiect ca aparinnd la mai mult dect un singur tip. Aa cum menionam mai sus, motenirea ar trebui folosit doar pentru a modela relaiile este-un sau este-un-fel-de, deci dac D este o subclas a lui C atunci s putem spune D este un fel de C. Principiul susbstituiei (Barbara Liskov) ne spune c instana unei subclase D a lui C trebuie s poat fi folosit fr excepii/ erori oriunde se folosete o instan a superclasei C (cu alte cuvinte, o subclas trebuie s fie un subtip: specificaia subclasei trebuie s respecte complet specificaia ancestorului direct; deci subclasa poate fi privit ca o submulime a mulimii bazei conceptuale comune -clasa de baz-). Un mod de a fora substitutabilitatea este s constrngem modificrile de comportament de la clas la subclas. Comportamentul unei clase se poate defini n termenii strilor observabile ale unei instane i a semanticii operaiilor definite pentru o instan a clasei, iar comportamentul unei subclase se poate defini n termenii schimbrilor incrementale ale strilor observabile i operaiilor definite de clasa de baz.

Principul care ne ajut s controlm modificrile ce apar n clasa derivat spune c aceasta trebuie s nu cear mai mult, i s nu promit mai putin (require no more, promise no less). Astfel, pentru respectarea principiului substituiei, se admit doar urmtoarele modificri n comportamentul unei subclase:

Precondiiile fiecrei operaii s fie aceleai sau mai slabe (-mai puin restrictive din perspectiva clientului)

Postcondiiile fiecrei operaii s fie aceleai sau mai puternice (s fac cel puin la fel de mult ca cele definite n superclas)

Invariantul de clas s fie la fel sau mai puternic (eventual s adauge constrngeri noi)

Din perspectiva strilor observabile, modificarile permise se vd astfel: Strile observabile i toate tranziiile ntre ele din clasa de baz trebuie s se

pastreze n subclas Subclasa poate s adauge tranziii ntre aceste stri Subclasa poate aduga stri observabile noi dac sunt concurente sau substri ale

unei stri existente

Vom traduce aceste restricii i n contextul programrii contractuale. Am vzut n programarea contractual c precondiiile stabilesc obligaiile transmitorului, iar postcondiiile i invarianii stabilesc obligaiile primitorului n orice interaciune. Deci cerina pentru precondiii cel puin la fel de slabe nseamn c n ndeplinirea obligaiilor fa de A, transmitorul ndeplinete automat i obligaiile fa de B (mai puin restrictive), iar cerina pentru postcondiii i invariani cel puin la fel de puternici nseamn c primitorul mplinete obligaiile fa de transmitor n termenii contractului lui A (chiar dac primitorul face ceva n plus dect se ateapt transmitorul).

Exemplu. Sa considerm modelul din Figura

Pentru fiecare operaie motenit:

1. Metoda tryIt() din A satisface precondiiile lui doIt() din B, nainte de a chema doIt();

2. Dac se substituie o instan C sau D, precondiiile pentru C::doIt() sau D::doIt() nu trebuie s adauge condiii noi fa de cele pentru B::doIt() (altfel ar trebui s adaptm A pentru acomodarea cu C i D);

3. Invariantul definit pentru B trebuie s fie adevrat i n instanele C i D; se pot aduga invariani noi

Polimorfismul este mecanismul specific programrii orientate obiect care st n spatele principiului substituiei i presupune ca aceeai metod s poat apare cu diferite definiii n cadrul ierarhiei de motenire. O referin polimorfic ascunde clasa actual a referentului, toi referenii fiind manevrai prin intermediul interfeei comune, iar asocierea unei anumite metode la o operaie specificat ntr-un mesaj are loc n timpul execuiei (legare dinamic). n C++ este implementat folosind funcii virtuale, iar n Java folosind motenirea sau implementarea de interfee.

Atat limbajul C++ ct i Java ofer suport pentru determinarea clasei actuale a referentului la execuie. Inspeciile la execuie creeaz un punct de mentenan, n cazul extinderii ierarhiei de clase, prin urmare GOOD prevede ca astfel de inspecii s fie minimale.

Clasele abstracte se scriu cu scopul de a defini o interfa pentru descendeni. Folosirea abstractizrii permite exploatarea polimorfismului la design, ntruct prile programului afectate de schimbri trebuie s se limiteze la cele care construiesc instane ale claselor.

Din perspectiva testrii, polimorfismul permite extinderea incremental a sistemelor prin adugarea de clase, n loc de modificarea celor existente, iar n extinderi pot aprea interaciuni neateptate. De asemenea, mecanismul permite ca operaiile s aib parametri

referii polimorfic, (aceasta mrete numrul de tipuri posibile de parametri ce trebuie testai) i permite unei operaii s specifice rspunsuri sub forma de referine polimorfice (aici clasa real a referinei pote fi incorect sau neateptat pentru transmitor).

O prim conlcuzie important este c natura dinamic a limbajelor orientate obiect acord mai mult importan testrii unei suite de configuraii din timpul execuiei.