Test-driven development
|
Na ruby.rs sastancima su momci iz http://renderedtext.com/ demonstrirali TDD kroz rspec i cucumber, mislim da su oni baš dosledni u toj priči. Ako hoćeš, mogu da pošaljem nekom od njih link do ovog threada pa možda napišu nešto.
BTW, sad vidim da imaju nekoliko članaka posvećenih BDD i TDD na svom blogu: http://renderedtext.com/blog/archive/ |
Mi na poslu koristimo na nekim projektima (onim većim), na manjim ne.
Inače, mi nismo baš 100% TDD, u smislu da krećemo od testa, već testove (unit i func) pišemo uglavnom nakon što je kod napisan. Izbor je veliki, čak i suviše, ja sam radio sa Nunit-om (i MbUnit, ni ne znam više) , Moq za mockovanje i Ninjectom za DI, ali i nekim malim DI "bibliotekama" koje su pisali likovi unutar firme, boga pitaj zašto.. Mislim da neki projekti sad koriste MSTest koji je deo VS-a, ali ja se ne sećam da sam radio sa istim, ne bi trebalo da je problem. E da, znam da je sa Moq-om bilo problema oko mockovanja statičkih metoda, pa je onda tamo korišćena biblioteka Typemock koja može da se koristi za te slučajeve. Nisam baš 100% siguran više da je bio Typemock, ali mogu da proverim ako ti treba. Možeš da kreneš od TestDriven.net i instaliraš isti, pa onda on ti daje podršku za razne biblioteke Nunit, MbUnit, itd, šta voliš. |
Koristimo TDD u 2 relativno velika Python/Django projekta, i TL; DR ovoga sto cu sada napisati je da kao i svaki alat i metodologija ima svoje prednosti i mane koje treba istraziti i zatim se odluciti za ili protiv.
Od alata i biblioteka, koristimo Python-ov unittest (manje vise de facto standard za unit-testove) i Mock (sjajna biblioteka, ko je Python programer obavezno nek je pogleda ako vec nije... ne stvarno, jako je dobro napisan), plus dodatne neke alate za logovanje, a Django ima svoj test runner. Prvo prednosti, koje su, pored standardnih selling point-a za mene to sto tera programera da razmislja PRVO o interfesju komponente i kako ce ona da komunicira sa ostatkom sistema. Ali ne samo to. Svaka naknadna izmena interfejsa za sobom povlaci dodatni technical debt izmene testova (CI alatka sa velikim ekranom koji bude crven negde, isto pomaze pri disciplini pisanja testova). Po mom utisku ovo kroz vreme dovodi do solidno dizajniranih ortogonalnih komponenti. Dodatno Django ima koncepte koji dosta pomazu ovakvom pisanju softvera (nezavisne 'modele' i 'aplikacije', koje mogu da 'saradjuju' - koliko god ne volim Javu dosta ovih koncepata bas odatle potice, ili su barem tamo postali mejnstrim). Sa te strane TDD totalno opravdava svoju ulogu. Manje izmene i dodavanje manjih feature-a postaje bezbolnije u takvom sistemu i uz Unit testove. Manje izmene i dodavanje manjih feature-a je nekad dobar deo ovog posla, i imati solidne testove i pisanje testova prvo, stvarno cini taj deo - u nedostatku bolje reci - laksim. Sada bih naveo 2 (ipo) mane tj. vise zamerki, koje sam ja primetio: Ja licno nemam utisak da TDD smanjuje bug count na kraju dana, ili ako ga smanjuje to su bug-ovi relativno male slozenosti. U zavisnosti od prirode sistema ovo moze biti manje ili vise izrazeno i treba uzeti u obzir kad se odlucuje za TDD yay or nay. U proseku ce Unit testovi nahvatati isto bug-ova koliko i kvalitetna kultura code review-a, barem se meni tako cini. Dakle - nije resenje za problem bugova u softveru :) TDD takodje nije besplatan i dolazi po cenu technical debt-a Prvo vrlo ocigledno - ima vise koda. Na XX k LOC ovo pocinje da se oseti. Drugo, svi mi ponekad ne zamislimo bas sve kako treba od starta uvek, a TDD koliko god bio predstavljan kao Agile, nekad cini ovaj deo tezim posebno u kasnijim fazama projekta. Ovo je druga strana medalje onoga iz prvog pasusa. Poslednje sto bih naveo je da TDD gubi svoje prednosti ako je zadatak high-level dizajn dela sistama i ne slaze se bas lepo sa rapid-prototyping tehnikama. Ukratko - TDD je moderna metodologija koja ima svoje prednosti i sitaucije u kojima je vrlo koristan, a i neke gde bas nije. Potrebno je malo vezbe da se vidi koje su koje. Voleo bih da vidim komentare ljudi sa drugim iskustvima. Za kraj da kazem da je TDD u dinamicki tipiziranim jezicima kao sto je Python imam utisak dosta bezbolniji nego npr. u Javi. |
Citat:
|
Citat:
|
Mislim da je velika vrednost jednih i drugih u tome što omogućuju da neko novi na projektu brzo krene sa izmenama koda i slično, jer testovi daju sigurnost da nešto nisu polomili.
E sad koji su važniji, unit ili func, ne znam, imaju mesto i jedni i drugi, opet u prvom redu zbog ovog gore što sam naveo, bar ja tako mislim. Zato se i koriste ja mislim mnogo na većim projektima, koji su kompleksni a održavaju godinama i godinama, a ljudi koji ih programiraju se onda menjaju u firmi ili na timu, itd. Kako dovesti nekog na tim da menja veliki projekat, a da nema testove da potera.. može, ali mnogo je rizično jer i ne može niko ručno da testira toliko toga kao što možeš testovima. A najmanje neki novi čovek ima pojma šta sve treba ručno da proveri, na šta sve njegova izmena ima uticaja, itd, itd. |
Citat:
E sad Python je na pola puta, jer za razliku od Javascript-a i Perla (poooosebno Perla :) ) nikad ne radi type coercion, tj. mora biti eksplicitan i dobrim stilom se smatra koriscinje tkz. 'duck typing'-a, koji recimo resava 50% (odokativno) unit testova koji bi se odnosili na proveru tipova. TDD je metodologija razvoja, i mislim da njena korisnost ima veze sa prirodom projekta, frameworka, nacinom vodjenja projekta itd. a ne samo jezika. Moj komentar se pre odnosio na to da ce 'cena' TDD biti ociglednija u Javi jer ce izmene interfejsa cak i samo metode izazvati mnogo vise posla, plus ima obavezne try-catch throws itd. - generalno vise posla koji se ne smanjuje rastom projekta. Ako se obe stvari uzmu u obzir mozda ispadne da na kraju bude isto posla - to da je bezbolnije je moj subjektivan utisak samo :) |
Citat:
|
Citat:
Мени се чини да цена ТДД-а код статичких језика расте и због додатног времена за компајлирање - бар је то случај са С++ом. |
@tata: Ja sam nekako mislio da je podela na unit i functional testing cisto akademska? Jel moze neki primer sta podrazumevas pod unit testom (a sta pod funkcionalnim), ako postoji takva razlika da smatras da unit testovi ne nalaze bagove u kodu?
Moje iskustvo sa tdd nije veliko, ali uglavnom scenario zbog koga smo ga koristili je ovaj koji degojs pominje, kad je naknadno potrebno izmeniti deo sistema, cesto samo jednu metodu. Kad se radi sa pipavim stvarima (npr. neki racun sa novcem), mnogo se prijatnije osecam kad imam stari set testova, izmenim/dodam par novih testova, pa tek onda menjam kod. Kad pustim testove znam da sve radi kao i ranije, osim onoga sto sam menjao. Znaci mnogo mi je sa TDD bitnija mogucnost da mogu da testiram ostatak sistema na side-efekte, nego samo testiranje dela koji trenutno razvijam (sto je valjda cilj TDD). Mada naravno pomaze i za ovo drugo, ali nemam osecaj da mi je tu krucijalno, a za zahvate na starom kodu bas jeste... |
Citat:
|
Aha, zbunilo me to malo, jer su nas na faxu ucili da su funkcionalni testovi "iz ugla korisnika", ono tipa: ako kliknem ovo dugme, iskoci ovaj prozor...
A sve zavisi od pogleda valjda, ja obicno imam na svakom modelu po jedan "glavni" metod koji zavrsi ceo jedan logicki korak (dodaj korisnika, izracunaj porez, itd..), gledam da mi u kontrolerima uvek bude minimum koda... tako da u sustini kad za tu metodu napisem unit test, onda prakticno ujedno dobijem i "funkcionalni" test za tu celu akciju... Sad bas imam neke probleme sa updejtom modula koji racuna razne statistike, procente, revenue share i sl. (prilicno komplikovano) i bez automatskog testiranja se ne bih usudio da ga otvorim u editoru :) |
^Pa i jeste to func test, osim što se direkt testiranje korisničkog interfejsa ne radi baš jer je teško za programiranje (posebno povratne informacije). Zato aplikaciju radiš tako da svaku akciju u GUI, možeš da testiraš pozivajući neki kod ispod, tu do izražaja dolazi ono da GUI bude lepo odvojen od ostatka aplikacije (ne trpa se nikakva logika u sam GUI).
A unit testovi se strogo ograničavaju (na samo taj neki metod koji testiraju), znači ne idu dalje, dublje, u aplikaciju, i vrlo su kratki i brzi. Zbog toga se i koristi "mockovanje" da bi se kreirali lažni objekti koji simuliraju sve ono što je "dublje" u aplikaciji i tako se unit test ograniči. Npr. ako imaš neki objekt koji je negde dublje u aplikaciji, koji ima funkciju: int SaveNewPatient(Patient p) { // sacuvaj p u bazi podataka, vrati Id.. } E pazi sad, kada pišeš unit test za neku funkciju iznad koja se desi kada korisnik klikne Save, ona npr. radi validaciju, pa poziva ovu SaveNewPatient koja radi sa bazom (ili web servisom, itd)... imaš problem jer ti bi da uradiš test samo one prve funkcije gde je validacija, a onda ode dalje, poziva ovu što radi sa bazom. Ako se to desi, da odeš dublje od onog metoda gore koji si hteo da testiraš (onaj gde je validacija, itd), nije više unit test, jer si otišao dublje. I onda se koristi to mockovanje, kako ne bi išao dublje prilikom izvršenja testa. Mock objekt ima sve iste metode i svojstva kao pravi objekt (znači implementira isti interfejs), ali u biti samo simulira rad istog, npr. int SaveNewPatient(Patient p) { return 1; // ne idemo u bazu, vraćamo Id 1, kao da je došlo iz baze } I to je to. Kada teramo unit testove, onda se zameni implementacija interfejsa tj. pa se umesto pravih koriste ovi lažni objekti, i tako smo unit test izolovali da ne ide dublje. I tu zamenu rade one DI bilblioteke. Znači za rad sa bazom postoji definisan neki interfejs, npr: int SaveNewPatient(Patient p); bool DeletePatient(Patient p); itd. Kod koji radi sa bazom implementira taj interfejs. Ali i mock objekt implementira taj interfejs. Kad pišemo svoj kod (kod aplikacije i kod testa), mi tražimo od DI biblioteke da nam da objekt koji implementira taj interfejs, kako bi radili sa bazom. Programiramo uvek against interface znači. DI će da nam vrati mock objekt ako teramo unit testove, a kada nije unit test, DI vrne pravi objekt. Pošto je kod (aplikacije ili testa) pisan "against interface", on radi lepo u oba slučaja, pojma nema da li zove pravi ili mock objekt, njemu je isto. Znači negde na startu prvo se podesi DI biblioteka, pa kažemo: DI.KadTraziTip(IDatabase).Vrati(DALDatabase) ali kada je unit test u pitanju konfigurisali smo: DI.KadTraziTip(IDatabase).Vrati(LazniDatabase) i to je to. Mi kod pišemo uvek tako da radimo sa IDatabase interfejsom. Prilikom testa, DI će da nam vrati LazniDatabase objekt, a kada nije unit test, vratiće DALDatabase objekt: baza = DI.DajMiObjektZaTip(IDatabase); baza.SaveNewPatient(...); Uh, nadam se da se nisam negde sapleo, otprilike tako ide.. :-) |
Vreme je GMT +2. Trenutno vreme je 20:16. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.