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. Rulati testele automate si le veti 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.

Document online: Contabilitatea institutiilor publice - test grila Document online: Impozitul pe profit - cote de impozitare, calculul profitului impozabil

Beneficii

Un studiu din 2005 a constatat ca utilizarea dezvoltarii condusa de teste a insemnat scrierea mai multor teste si, la randul sau, programatorii care au scris mai multe teste au tins sa fie mai productivi. Ipoteze referitoare la codul de calitate si o corelare mai directa intre dezvoltarea condusa de teste si productivitatea acesteia au fost neconcludente.

Programatorii folosind dezvoltarea condusa de teste pe noi proiecte ('greenfield'), doar rareori simt nevoia de a utiliza un program de depanare. Folosit in combinatie cu un sistem de control al versiunii, atunci cand testele esueaza in mod neasteptat, readucerea codului la ultima versiune care a trecut toate testele poate fi de multe ori mai productiva decat depanarea.

Dezvoltarea condusa de teste ofera mai mult decat doar simpla validare a corectitudinii, dar poate conduce, de asemenea, la proiectarea unui program. Prin concentrarea asupra cazurilor primul test, trebuie sa ne imaginam ce functionalitate va avea pentru client (in primul caz, cazuri de testare). Deci, programatorul va fi preocupat de interfata inainte de punerea in aplicare.

Acest beneficiu este complementar programului Design by Contract pentru ca apropie de ea prin codul de cazuri de testare, mai degraba decat prin afirmatii matematice sau idei preconcepute.

Dezvoltarea condusa de teste ofera posibilitatea de a lua masuri mici atunci cand este necesar. Acesta permite unui programator sa se concentreze pe fiecare sarcina in sine pentru ca tinta lui ramane functionalitatea testului. Cazurile exceptionale si tratarea erorilor nu sunt luate in considerare initial, si testele pentru a crea aceste conditii secundare sunt puse in aplicare separat. Dezvoltarea bazata pe teste ne asigura in acest mod ca tot codul scris este acoperit de cel putin un test. Aceasta ofera echipei de programare un nivel mai ridicat de incredere in cod.

Desi este adevarat ca un program TDD cere mai des un cod decat un program fara TDD, din cauza codului test de unitate, datorita timpului de implementare codul este de obicei mai scurt. Un numar mare de teste ajuta la limitarea numarului de defecte in cod. Natura precoce si frecventa de testare ajuta la depistarea defectelor la inceputul ciclului de dezvoltare, impiedicandu-le sa devina probleme endemice si costisitoare. Eliminarea defectelor la inceputul procesului, de obicei, evita depanari ulterioare in proiect.

Dezvoltarea condusa de teste poate duce codul la o modularizate, mai flexibila, si extensibila. Acest efect de multe ori apare , deoarece dezvoltatorii de software gandesc in termeni de unitati mici care pot fi scrise independent si testate si integrate impreuna mai tarziu.

Aceasta duce la mai mici, mai multe clase si interfete mai curate.

Utilizarea modelului Object Design, de asemenea, contribuie la modularizare de ansamblu a codului, deoarece acest model presupune ca acel cod sa fie scris astfel incat modulele sa poata fi schimbate cu usurinta pentru unitatea de testare si pentru implementarea versiunii.

Deoarece nici un cod nu mai este solicitat in afara de cel necesar trecerii unui test eronat, teste automate au tendinta de a acoperi fiecare modalitate de cerere a unui cod. De exemplu, pentru un dezvoltator TDD, pentru a adauga o ramura la cele existente, dezvoltatorul ar trebui mai intai sa scrie un caz test care sa esueze pentru a motiva programul. Ca rezultat, testele automate care rezulta din TDD tind sa fie foarte amanuntite: vor fi detectate orice modificari neasteptate in comportamentul codului. Aceasta detecteaza probleme care pot aparea in cazul in care o modificare mai tarziu, in ciclul de dezvoltare, modifica in mod neasteptat alte functionalitati.

Vulnerabilitatile

Dezvoltarea condusa de teste este dificil de utilizat in situatiile in care testele pe deplin functionale sunt necesare pentru a determina succesul sau esecul. Exemple sunt interfetele pentru utilizator, programe care lucreaza cu baze de date, si unele care depind de configuratii de retea specifice. Dezvoltarea condusa de teste incurajeaza dezvoltatorii sa utilizeze un numar mic de coduri pentru asemenea module, pentru maximizarea logica ce este prezenta in codul de baza.

Sprijinul managerial este esential. Fara sprijinul intregii echipe care are intentia de a imbunatati produsul, conducerea poate simti ca timpul petrecut pe scris teste este irosit.

Testele s-au dovedit parte dintr-un proiect de intretinere plasat deasupra unui proiect. Testele prost scrise, de exemplu, cele care includ siruri de coduri eronate sau care sunt ele insele predispuse la esec, sunt scumpe pentru a fi mentinute. Exista riscul ca testele care genereaza in mod regulat esecuri false sa fie ignorate, astfel incat atunci cand apare o eroare reala acesta nu poate fi detectata. Este posibil sa fie scrise teste usor de intretinut, de exemplu, prin reutilizarea de siruri de caractere de eroare, si acest lucru ar trebui sa fie un scop in timpul fazei 'Refactor' descrise mai sus.

Nivelul de acoperire si de testare dobandit in timpul ciclurilor repetate de teste nu poate fi cu usurinta re-creat la o data ulterioara. Prin urmare, aceste teste originale au devenit tot mai pretioase, astfel cum trece timpul. Daca o arhitectura saraca,un design prost sau o strategie de testare duce la o schimbare care mai tarziu va cauza esecul, este important ca acestea sa fie fixate in mod individual. Stergerea pur si simplu, dezactivarea sau modificarea pripita a acestora poate duce la erori ne-detectabile in testare.

Lacune neasteptate in aria de testare pot exista sau pot aparea din cauza unui numar de motive. Poate unul sau mai multi membrii ai unei echipe nu au fost atat de hotarati sa scrie teste in mod corespunzator, poate unele seturi de teste au fost invalidate, sterse sau prezinta handicap accidental sau intentionat. Daca se intampla acest lucru, increderea in aceste teste va fi diminuata. Este posibil ca erorile sa nu fie detectabile in momentul introducerii informatiilor.

Unitatea de teste creata are de obicei de un dezvoltator, care va scrie, de asemenea, codul care este de testat. Testele pot avea, prin urmare, aceleasi erori ca ale codului.

Daca, de exemplu, un dezvoltator nu isi da seama ca anumiti parametri de intrare trebuie sa fie verificati, cel mai probabil nici codul nu va fi verificat la intrare. In cazul in care intelege gresit specificatiile codului,atat testul cat si codul vor fi sortite esecului.

Numarul mare de teste valide poate aduce un fals sentiment de siguranta , care rezulta in mai putine activitati suplimentare de asigurare a calitatii, cum ar fi testarea de integrare si testarea conformitatii.

Cod Vizibilitate

Codul Test-Suite in mod clar trebuie sa aiba acces la codul pe care il testeaza. Pe de alta parte, criteriile normale de proiectare, cum ar fi ascunderea de informatii, incapsulare si separarea de preocupari nu ar trebui sa fie compromisa.

In designul orientat obiect acest lucru inca nu ofera acces la date private si metode.

Prin urmare, munca suplimentara poate fi necesara pentru teste unitare. In Java si alte limbaje, un dezvoltator poate utiliza reflectia pentru a accesa campurile care sunt marcate private.

Alternativ, o clasa de interior poate fi folosita pentru teste unitare, astfel incat acestea vor avea 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.

Falsuri, imitatii si teste de integrare

Unitatile de teste sunt numite astfel deoarece fiecare incearca, o unitate de cod.

O suita de teste pentru a fi utilizate in TDD nu ar trebui sa depasesca granitele procesului intr-un program, sa acceseze conexiuni numai de retea. Procedand astfel se produc intarzieri, descurajaza dezvoltatorii care ruleaza suita intreaga. Introducerea pe module externe sau de date, de asemenea,transforma teste de unitate in teste de integrare.

In cazul in care un modul deviaza intr-un lant de module interconectate, nu este atat de clar unde sa se caute cauza esecului.

Atunci cand codul in curs de dezvoltare se bazeaza pe o baza de date, un serviciu Web, sau orice alt proces extern sau serviciu, executarea unei unitati de separare-testabile este, de asemenea, o oportunitate si o forta motrice pentru a proiecta un cod mai modular, mai testabil si reutilizabil.Doua masuri sunt necesare:

1. Ori de cate ori accesul extern va fi necesar in design-ul final, o interfata ar trebui definita care sa descrie accesul care va fi disponibil. A se vedea principiul inversiunii de dependenta pentru o discutie in ceea ce priveste beneficiile de a face acest lucru.

2. Interfata trebuie sa fie implementata in doua moduri, unul care sa acceseze

intr-adevar procesul extern, si altul, care este un fals sau imitatie. Obiectele imitatie trebuie sa faca ceva mai mult decat a adauga un mesaj, cum ar fi 'Persoana obiect salvat' intr-un jurnal urma, fata de care un test de afirmatie poate fi rulat pentru a verifica comportamentul corect. Imitatiile difera in sensul in care contin afirmatii de testare care pot face testul sa nu reuseasca, de exemplu, daca numele persoanei si alte date nu sunt cele asteptate. Falsurile si metodele de machete obiect care returneaza date, aparent de la un magazin de date sau un utilizator, pot ajuta la procesul de testare prin returnarea mereu de aceleasi date, realiste, pe care se pot baza testele. Ele pot fi de asemenea setate in modurile predefinite, astfel incat datele eronate pot fi dezvoltate si testate fiabil. Operatiunile eronate, altele decat magaziile de date pot fi, de asemenea, utile in dezvoltarea condusa de teste. Falsurile de criptare nu pot participa la criptarea datelor transmise; numerele false alese aleatoariu pot returna intotdeauna 1.

O completare in ceea ce priveste injectarea de dependenta este ca in baza de date reala sau alte surse externe, codul de acces nu este niciodata testat de procesul de TDD in sine.

Pentru a evita erori care pot aparea de la acest lucru, sunt necesare alte teste care trebuie sa confirme faptul ca, acel cod testat este identic cu cel real implementat in interfetele de mai sus. Aceste teste sunt destul de separate de teste de unitate TDD, si sunt intr-adevar testele de integrare.

Testele de integrare care modifica orice magazin de date ar trebui sa fie intotdeauna atent concepute cu luarea in considerare a starii initiale si finale ale fisierelor sau bazelor de date, chiar daca orice test esueaza. Acest lucru este deseori realizat folosind o combinatie dintre urmatoarele tehnici:

* Metoda teardown, care este parte integranta, a testat mai multe cadre.

* try catche in cele din urma structuri de manipulare exceptie in cazul in care sunt disponibile.

* Baze de date tranzactii in cazul in care o operatiune atomic include, probabil, o scriere, o lectura si o operatiune de stergere potrivita cu scopul in sine.

* Avand o faza initiala a bazei de date inainte de a rula orice teste si rulare inapoi la faza initiala dupa fiecare test. Acest lucru poate fi automatizat cu ajutorul unui cadru, cum ar fi Ant sau Nant sau un sistem continuu de integrare, cum ar fi CruiseControl.

* Aducerea bazei de date la o stare curata inainte de teste si dupa testare. Acest lucru poate fi relevant in cazul in care curatarea poate face dificil de diagnosticat esecurile test prin eliminarea starii finale a bazei de date inainte de predarea diagnosticului final detaliat .

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