*DD FAIL? Wurbe#5
Posted on January 23, 2008
Filed Under Evenimente, Munca, Tehnologie | 16 Comments
Luni a fost cea de-a 5-a intalnire Wurbe. A fost o mini-conferinta la sediul Adobe Romania. Sapte oameni au luat cuvantul, printre care si eu. Subiectele au fost de la unit testing la web testing frameworks. In sala au fost cam 70 de oameni. Doar o mica parte dintre cei prezenti erau familiarizati cu subiectele legate de dezvoltare cu unit teste sau test driven development. Aparent foarte putina lume practica asa ceva si in general lumea nu intelege asocierea test – development.
Ori testez ori dezvolt, nu?
Nu.
Nu exista dezvoltare fara o forma minima de verificare/validare/testare. Fie ca rulezi programul si inspectezi manual rezultatul, fie ca faci asta automat, e imposibil sa dezvolti ceva fara sa verifici/validezi/testezi ca liniile tale de cod fac ceea ce trebuie. Avantajul unor teste unitare automate este ca nu trebuie sa le scrii decat o singura data dupa care le poti rula la fiecare modificare. Verificarea/validarea/testarea manuala, insa, nu are loc la fiecare modificare de cod, sau nu in intregime. Daca mergem mai departe si ne imaginem un sistem sofware in loc de cateva linii de cod este usor de realizat ca vom avea o multime de “unitati” de cod dependente una de cealalta. Revenind la testare automata vs testare manuala ne dam seama ca dupa putin timp este practic imposibil sa mai verifici/validezi/testezi toate “unitatile” de cod dependente de cea pe care o manipulezi la un moment dat.
Tot ce am scris eu mai sus se poate sintetiza intr-o problema de combinatorica. Pe care din lene nu am s-o expun aici. Si din lene stiu ca nimeni nu va avea vreodata disciplina intelectuala sa poata sa surprinda toate componentele unui sistem pe care il modifica. Concluzie: in fiecare zi de “codare” fara unit teste nu faci altceva decat sa produci bug-uri pe care, ulterior, tu sau un alt ghinionist va trebui sa le repare si care, la randul lui, daca nu va crea teste automate va produce alte bug-uri si uite asa se creaza “tar pit”-ul lui Frederick Brooks.
Costul (bani/timp/alte resurse) de modificare a unui sistem traditional creste exponential cu timpul. Tot ce inseamna “agile development” nu promite decat un singur lucru: costul modificarilor evolueaza logaritmic.Nu am sa iterez prin beneficiile unit testelor sau ale TDD-ului. Vreau doar sa subliniez ca testarea unitara face parte din “coding” si suplimenteaza portiuni din design.
Ei bine, asta nu prea intelegea publicul la Wurbe#5. Cel mai ciudat mi se pare ca oricare “alpha-geek” intelege esenta.
Wurbe#5 a fost un maraton in care prezentatorii si cativa oameni din public au incercat sa clarifice o realitate prea putin inteleasa si acceptata. Din perspectiva aceasta prezentarea mea a fost un esec. Am ratat sa identific publicul inainte. Astfel elementele expuse nu erau compatibile cu ceea ce putea fi digerat de catre majoritatea prezenta. Sper, totusi, ca am reusit sa starnim curiozitatea si sa ridicam niste intrebari in randul oamenilor. Pentru cei care nu au digerat prezentarile mai complexe au fost si doua prezentari la care am cascat si zambit la tentativele esuate lui Chelu’ de a le derula pe “fast-forward”.
Restul a fost ok, pizza buna, bere si putin ping-pong pe final.
Cosmin
Reactii:
Comments
16 Responses to “*DD FAIL? Wurbe#5”
Leave a Reply
-
Cautare
-
Feeds
-
Categorii
-
Evenimente
-
Cele mai dezbatute articole
-
Arhiva
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
Din pacate nu toti sunt situati in dreapta gaussienei. Pun pariu ca in sala cel putin jumatate nu stiau ce inseamna “Agile” si nici macar nu au mirosit de aproape vreun proiect care sa aiba mai mult de cateva mii de linii de cod.
E drept ca venind de pe planeta Google sau Adobe fenomenul poate sa para ciudat, dar era clar ca atunci cand se inscriu mai multe zeci de persoane la un astfel de eveniment nu prea poti depasi un anume nivel de complexitate al prezentarii.
Exista si o parte nasoala relativ la TDD … unit-testing inseamna cod scris suplimentar, cod ce mareste evident dimensiunea proiectului. Si exista o vorba ce se aplica si in cazul de fata: codul nescris are zero buguri.
Metodologiile agile sunt utile in marea majoritate a timpului, dar sa nu uitam niciodata ca informatica este bazata pe cunostinte imperative si cunoastem extrem de putine adevaruri absolute. Ce merge pentru un proiect, nu merge neaparat si pentru altul.
Si eu n-as aprecia complexitatea unui proiect dupa numarul de linii de cod. Daca am gandi mai mult si mai modular (caracteristica ce nu ne sta in fire) probabil n-ar exista proiecte mai mari de cateva mii de linii de cod.
As always, depinde prin ce definesti un “proiect” …
TDD unit-testing ! E adevarat ca primul il implica pe al doilea, but still. Ca atare, daca ti-e frica de inflatia de cod nimic nu te impiedica sa scrii teste cand ai tu chef doar pentru portiunile judecate “sensibile” prin design si pentru zonele unde s-au constatat buguri frecvente. Unde riscul de a avea buguri in teste (care sunt foarte simple in marea majoritatea a cazurilor) este mai mic decat riscul de a avea bug-uri propriu-zise. Decisions, decisions …
Cosmin uiti o chestie. wurbe e comunitatea dezvoltatorilor de web daca tin eu bine minte. In romania in mai mult de 80% din cazuri web inseamna php+mysql in aplicatii de cateva mii de lini de cod in cel mai ‘rau’ caz si site-uri de prezentare toate facute in php.
Eu am incercat sa gasesc ceva pentru unit testing in php (nu am cautat prea mult ca vine sesiunea si cica as fii ultimul an
) dar nu am gasit mai nimic. Asa ca dezvoltatori de php nu prea au solutii pentru unit testing efectiv. In schimb niste teste cu watir sau Selenium RC + java.awt.Robot ar putea prinde la cativa oameni care au fost acolo 
As vrea sa profit de ocazie pentru a-l felicita pe Bogdan Roman pentru prezentare, in primul rand pentru ca este singurul dintre vorbitori care ne-a aratat material 100% original pe subiect (ok era si Chelu cu un picusor de cod propriu la Giston, sa admitem, circumstante atenuante). In al doilea rand, Bogdan a fost foarte profesionist, s-a vazut ca s-a pregatit si nu a incropit prezentarea cu o zi inainte cum am facut de exemplu eu (si presupun ca nu am fost singurul … )
Ocazie cu care mi-a daramat prejudecatile privitore la Selenium, tot e bine ca am aflat de existenta Selenium RC in anul de gratie 2008 si mai mult ca sigur am sa ma joc un pic cu el una din zilele astea. A reusit asadar sa converteasca minim un individ…
Nu pot sa inchei fara un sincer: Die, Vista, die ! grrr
… prin “original” inteleg contributie la o scula de testare, nu ca restul am fi avut slide-uri copiate de cine stie unde
“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.
@Adrian Spinei:
Ciudat. Azi dimineata i-am spus lui Bogdan ca m-a convins ca Selenium e o alegere mai buna decat Watir.
@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.
Pentru PHP eu am folosit: http://simpletest.sourceforge.net/
@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.
Super
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!”.
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.
@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.
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.