Comentarii la: *DD FAIL? Wurbe#5

De către: Ionut Bizau

Ionut Bizau — Mon, 28 Jan 2008 22:59:24 +0000

La noi se scriu teste > 50% din timp. Avem o suita de unit teste care ruleaza sub un minut si o droaie de teste functionale care dureaza intre 30 si 50 de minute (acum lucrez la paralelizarea lor pe calculatoarele “libere”).
Poate pare un efort prea mare, dar avantajele sunt pe masura:
1) refactoring. Suntem intr-o faza a proiectului unde am facut niste schimbari de-ti sta mintea in loc: splitari de tabele, modificare tabele la “insert only” (in loc de update se insereaza o noua inregistrare)… Astea intr-un sistem la care se lucreaza de 5 ani (se si simte cand codul e vechi si parca l-au trecut toate intemperiile de cand a fost plantat) si o echipa de ~20 de oameni. Imi amintesc la alte joburi cand aveam de modificat chiar si numele unei coloane intr-un tabel – fugi imediat si testeaza de mana… Aici nici nu mi-as permite asta, ca nu pot sti ce implicatii ar avea o schimbare.
2) controlarea bugurilor. Daca repari un bug scrii un test care se asigura ca s-a rezolvat. Asta te va ajuna mai incolo daca “gandacul” ar mai incerca sa revina.
3) impartirea muncii. Cand comit ceva e raspunderea mea sa rulez testele cu succes. Nu mai se ajunge in situatii de genul “bine mai, acuma ai facut si tu aia cand voiam sa fac eu ai’lalta? cine face acuma merge? uite ca stricasi tot.”
4) ajutor pentru nou-veniti. Scriind niste teste vezi exact ce si cum se intampla in aplicatie. Mai avem si code reviews unde poti sa inveti de la altii – dar testele iti dau voie sa faci ceva practic fara a strica nimic.

De către: cosmin

cosmin — Mon, 28 Jan 2008 14:52:19 +0000

@Andrei Maxim: foarte frumos comentariu. Ai dreptate. Este vorba de test driven design folosind un test-first approach (TDD). Tot de aici as sublinia diferenta dintre unit testing simplu si TDD care reiese din avantajele insirate de tine. Ca parte comuna ar fi testele in regresie oferita de unit testing.

De către: Andrei Maxim

Andrei Maxim — Mon, 28 Jan 2008 13:56:53 +0000

Sunt abordari cumva diferite cand vine vorba de unit-testing vs. TDD. Din pacate n-am asistat la conversatii, dar vazand discutia de pe blog parca as interveni putin.

Personal, eu inteleg prin unit-testing codul scris ca sa testeze bucati din codul ce va ajunge in productie. Da, ocupa mult timp (Ron Jeffries spunea pe grupul de TDD ca el scrie cam 50% din timp cod si 50% teste), necesita ceva experienta pentru a se ajunge la niste “best practices” astfel incat sa ajungi sa scrii/vezi doar testele relevante. Recomand Pragmatic Unit Testing de la Pragmatic Programmers pentru acest aspect.

Al doilea subiect, cel de Test-Driven Development, e un pic mai delicat. Acesta nu inseamna “testele inainte, codul dupa” ci mai degraba un fel de contract. Spune care anume sunt caracteristicile unui anumit obiect si abia apoi scriem codul.

De fapt, procesul nu-i prea diferit de felul in care programam in fiecare zi: “adresa are un cod postal care e format doar din 5 cifre… boon, validam asta, daca nu bagam un mesaj de eroare/aruncam o exceptie/returnam nil” si asa mai departe. Tocmai de aceea e foarte dificil sa iti creezi reflexul de TDD (si, din proprie experienta, mult mai usor e sa-l pierzi). E nevoie de un efort unitar din partea tuturor care ating codul respectiv.

Avantajele remarcate de mine sunt cumva mai subtile. De exemplu, codul devine mult mai simplu, mult mai evident. Refactoring-ul e mult mai usor. Bug-urile sunt mult mai putine, dar nu pentru ca testez ci pentru ca gandesc mai in detaliu ce face acea mica bucata de cod.

Imi pare tare rau ca am ratat Wurbe #5, sunt convins ca mi-ar fi placut mult.

De către: Ionut Bizau

Ionut Bizau — Thu, 24 Jan 2008 22:49:21 +0000

Agile development & testarea automata intra la categoria “AHA!”. Te descurci rezonabil fara ele si nevoia lor nu e evidenta, dar odata ce le-ai folosit o data spui “AHA! Deci asta-mi lipsea!”.

De către: Claudiu

Claudiu — Thu, 24 Jan 2008 15:01:20 +0000

Super

De către: Diana

Diana — Thu, 24 Jan 2008 12:36:16 +0000

@Adrian Spinei & @Bogdan Roman
Si mie mi-a placut prezentarea lui Bogdan chiar daca initial Selenium nu era o optiune pentru ceea ce aveam nevoie. Acum cred ca poate destul de multe
Combinatia Selenium + awt.Robot suna promitator si chiar as vrea sa aflu tips&tricks de la cei care o vor folosi.

De către: Alex

Alex — Thu, 24 Jan 2008 10:31:36 +0000

Pentru PHP eu am folosit: http://simpletest.sourceforge.net/

De către: Adrian Spinei

Adrian Spinei — Wed, 23 Jan 2008 21:31:23 +0000

@Cosmin: Nu e ciudat, chiar e o alegere mai buna cel putin pe hartie: multibrowser, multiplatforma, bindinguri pe o herghelie de limbaje. Ramane de vazut daca si pe unde “scartaie” integrarea cu awt.Robot, trebuie totusi spus ca WatiR-ul are un tovaras de nadejde in AutoIT, iar WatiN-ul foloseste automationul din .net care orice am zice noi e facut cu cap si te lasa sa pilotezi o sumedenie de lucruri.

De-asta l-am intrebat la Q&A cat de mult a brutalizat jucaria…

@Alex: exista phpunit si destul de demult (http://www.phpunit.de/) [ma rog, eu vorbesc, care nu stiam de Selenium RC]. Btw, testarea unitara server-side si blackox sunt complementare, nu spune nimeni ca daca o faci pe una nu mai ai “voie” sau “timp” sa o faci pe cealalta. So.

De către: cosmin

cosmin — Wed, 23 Jan 2008 21:10:48 +0000

@Adrian Spinei:

Ciudat. Azi dimineata i-am spus lui Bogdan ca m-a convins ca Selenium e o alegere mai buna decat Watir.

De către: cosmin

cosmin — Wed, 23 Jan 2008 20:42:52 +0000

“Eu am incercat sa gasesc ceva pentru unit testing in php dar nu am gasit mai nimic. Asa ca dezvoltatori de php nu prea au solutii pentru unit testing efectiv”
@Alex:
“EUnit is a unit testing framework for Erlang. It is very powerful and flexible, is easy to use, and has small syntactical overhead.”
Se gasesc framework-uri pentru Ada, Lisp, Prolog, Fortran, SQL, si cam orice poate fi interpretat sau compilat. Nu trebuie sa cauti prea mult: au formatul XUnit (de exemplu PhpUnit) sau daca nu, poti sa cauti “X Unit” unde X e orice nume de limbaj sau “X Test”. Dar e mai usor sa spui ca nu se gaseste.