Test-driven development
 

Има ли кога овде да практикује 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.

Који су кориснији по твом мишљењу (јунит или фунц)? Мени се чини да јунит захтевају много више инвестиција а на крају не открију готово никакве проблеме. Функционални су управо обрнути: мала инвестиција и висока вероватноћа да детектује багове.

Да ли мислиш и да је кориснији у динамичким језицима? Ја никад нисам радио са Пајтоном, али јесам са нпр. Перлом и ЈаваСкриптом и имам утисак да јунит тестови служе готово као замена за компајлер у смислу обезбеђивања од багова са типовима као и за документацију (из њих се види шта тачно треба да проследиш као параметар функције, итд).

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.

'Korisnije' se verovatno odnosi na samo postojanje unit testova, ne na TDD, i odgovor je vrlo verovatno - da. Imati dinamicke tipove je tradeoff - menjas brzinu razvoja za deo sigurnosti.

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 :)

Јесте али као што рекох, јунит тестовима нисам открио скоро никад ништа, па не знам колико је та сигурност основана.

Капирам. Додуше, Јава има алате којима се та цена смањује - подршка за рефакторинг у Еклипси, итд.

Мени се чини да цена ТДД-а код статичких језика расте и због додатног времена за компајлирање - бар је то случај са С++ом.