Već mjesec dana se bavim TDD-om, radio sam neke testove, testirao neke simple metode, akcije u MVC-u i slično, ali nisam radio testove na nečemu značajnom. Pa me zanima koliko se u praksi koristi TDD, znači na, da tako na zovem, pravim aplikacijama? Prvenstveno ciljam na .NET i NUnit, no savjet sa bilo koje platforme je dobrodošao.
Hvala.
Automatizacija testiranja je genijalna ideja, ne znam kako to nikome prije nije palo napamet nego se tek nedavno počelo masovnije koristiti. Uglavnom, meni kao programeru s ogromnim iskustvom (godina i pol) se čini kao super ideja ali mi je izvedba zasad nakaradna te mi na kraju ispadne više truda pisati testove nego testirati na svoj Dobar Stari Način.
No, predviđam da će se poboljšanjem TDD-a odnosno programčića za izvođenje istog porasti i moja želja za njegovim korištenjem, jer kažem, kao ideja zvuči fenomenalno.
Neću otkriti na kojem sam programskom jeziku stekao ovakvo mišljenje radi očuvanja tajnosti svog identiteta. Na drugim jezicima je to možda bolje rješeno.
Ne znam zbog čega se kriješ i zašto kriješ platformu, ali za ove malo stvari koje sam do sada testirao koristio sam Resharperov Unit Test alat, a i NUnit-ov. Hvale ih i programeri iz .NET zajednice, alati su skroz ok. Mene više brine ovo što sam pitao. Kako sve to zvuči kad gabariti aplikacije porastu? Uskoro krećem sa novim projektom pa ne znam da li da radim i Unit testove ili ne sa njim.
Po mojem iskustvu, najveca dobit TDD-a zapravo ne lezi u test-suiteu koji s vremenom razvijes, vec u 'prisilnom' ucenju KISS principa i dizajna softwarea bottom-up, koji po mojem misljenju omogucava vecini programera da proizvode puno kvalitetniji software.
Stvar je u tome da ako se drzis TDD-a kompletno, dakle pises test prije nego pises kod koji ce ga zadovoljiti - ono sto se desava jest da definiras sto klasa/komponenta radi iz perspektive klijenta. Naravno, ista stvar se moze postici i bez unit testova, ali nalazim da se dosta ljudi izgubi u detaljima implementacije, prije nego 'shvate' sto tocno klasa kao cjelina treba odraditi - tu TDD pomaze jer je dobro definiran set pravila, a i automatizirani test nije za odbaciti, naravno ;-)
Jednom prilikom pisao sam driver za serijski uredjaj, dakle modul koji bi uzimao low-level API komande, sastavljao stream od njih i slao ih uredjaju, te konvertirao odgovore iz uredjaja u poruke. TDD je bio totalni spas, jer je - ocekivano - modul bio heavily multithreadan i da nisam forsirao TDD, vjerojatno bi dizajnirali komponente koje bi tesko testirali zasebno. Ovako smo bili sigurni da svaki djelic sistema radi kako spada, pazljivo sinkronizirali resurse dijeljene izmedju threadova i voila - niti jedan jedini bug, otkako je modul lansiran, a to je bilo pred dobrih 8 godina.
E da - jedan od vecih mitova je taj da testovi trose vrijeme... nemoj se obazirati na to, to je totalna neistina. Kad stavis svo potroseno vrijeme na skup, ukljucujuci ono koje si potrosio pisuci test i ono koje si potrosio debugirajuci - TDD pobijedjuje i to ne za malo!
Dali se preporučuje učenje TDD za nekoga tko ne piše "Enterprise code" tj. ne piše velike aplikacije, nego manje stvari za svoju dušu (ni jedan solution mi još nije imao više od 3 projekta)? Meni se ideja čini super, ali ima toliko stvari koje se isplati naučiti u programiranju pa neznam dali bi trebao trošiti vrijeme na to. Također me zanima dali se tako nešto koristi u gamedevu, i dali to onda izgleda drukčije pošto je real-time.
Dali se preporučuje učenje TDD za nekoga tko ne piše "Enterprise code" tj. ne piše velike aplikacije, nego manje stvari za svoju dušu (ni jedan solution mi još nije imao više od 3 projekta)? Meni se ideja čini super, ali ima toliko stvari koje se isplati naučiti u programiranju pa neznam dali bi trebao trošiti vrijeme na to. Također me zanima dali se tako nešto koristi u gamedevu, i dali to onda izgleda drukčije pošto je real-time.
Naravno. Kao sto sam opisao u postu, najveca prednost TDD-a je 'prisilna' inverzija nacina razmisljanja, odnosno, prisiljava te sagledavati stvari iz funkcionalne perspektive. Mogucnost da izolirano, automatski testiras bilo kakav code je uvijek najbolja verzija testiranja, a i pritom ne zaboravi da je uz takve testove moguce i automatski profilirati dijelove koda - iako se to ne preporuca cisto zbog konteksta.
U programiranju, bas nista nije "trosenje vremena", i istina je da ima puno stvari za nauciti ali zato, kao i kod svakog drugog skilla, bitno je pravilne temelje postaviti cim prije, jer je lose temelje kasnije vrlo tesko promjeniti. Cisto usporedbe radi, kad u timu moram zaposliti juniore - za njih je TDD enforcean. Dakle, vjerujem da seniori znaju procjeniti dobar dizajn (inace ih ne zaposljavam) pa nemaju obavezu pisati testove, i ostavljeno im je na gut feeling da to odrade ili ne. Juniori nemaju tu privilegiju, i moraju pisati testove za svaki dio koda koji dotaknu. Cesto se dogodi i da moraju popravljati bugove u kodu, i protokol koji moraju slijediti je:
1. Napisi test
2. Ako ne mozes napisati test, refaktoriraj tako da mozes
3. Ponavljaj 1 i 2 dok ne napises izolirani test
4. Popravi bug
U realtime aplikacijama se nista ne razlikuje, jer testovi nisu sastavni dio glavnog executablea, vec poseban executable. Ovo na prvi pogled zvuci dosta dobro, ali moze biti dvosjekli mac.
A baš šta je sa enterprise aplikacijama? Moje skromno mišljenje je da nema smisla testirati "male" aplikacije tipa knjigovodstva i slično?
TDD i enterprise nejdu u istu rečenicu. Bookmarkano, kad nađem vremena ide objašnjenje. Zapravo TDD je općenito promašen pristup ako se mene pita, al ok...
TDD i enterprise nejdu u istu rečenicu. Bookmarkano, kad nađem vremena ide objašnjenje. Zapravo TDD je općenito promašen pristup ako se mene pita, al ok..
Super, zanima me mišljenje i sa druge strane.
Automatizacija testiranja je genijalna ideja, ne znam kako to nikome prije nije palo napamet nego se tek nedavno počelo masovnije koristiti. Uglavnom, meni kao programeru s ogromnim iskustvom (godina i pol) se čini kao super ideja ali mi je izvedba zasad nakaradna te mi na kraju ispadne više truda pisati testove nego testirati na svoj Dobar Stari Način.
No, predviđam da će se poboljšanjem TDD-a odnosno programčića za izvođenje istog porasti i moja želja za njegovim korištenjem, jer kažem, kao ideja zvuči fenomenalno.
Neću otkriti na kojem sam programskom jeziku stekao ovakvo mišljenje radi očuvanja tajnosti svog identiteta. Na drugim jezicima je to možda bolje rješeno.
Ja kao visegodisnji programer (5 godina) jos ne bih rekao da imam ogromno iskustvo....
Ja kao visegodisnji programer (5 godina) jos ne bih rekao da imam ogromno iskustvo....
Mislim da je u pitanju samo-sarkazam...
Ovako, prvo da objasnim zašto smatram da TDD nema smisla.
Ako developer predvidi neku situaciju u svome kodu, neće ju testirati niti sa odvojenom aplikacijom. Ne znam, primjerice, što se desi sa transakcijom ako netko "isčupa" hard tokom njenog izvođenja ili što se desi sa sesijom ako netko nasilno isčupa smart karticu (autentifikacija). Ako netko predvidi neku situaciju, on može napisati 100 testova, određen scenarij neće biti testiran i samim time će se shippati proizvod koji neće biti adekvatan (sad koliko su kritični propusti je drugi par rukava). Drugim riječima, moraš imati fallback na QA i bussiness modelere i u tom slučaju TDD samo povećava trošak projekta (nema veze što možda zbog testova se i brže napiše neki segment, jer validaciju ionako provodi QA tim, odnosno BI tim).
Kod poslovnih aplikacija, najbitnija ti je baza - kod enterprise ti je ko dobro jutro imati bazu gdje je više-manje sve spucano u jednu tablicu sa 50-tak stupaca i imaš +10k zapisa, a sam ekosustav brat-bratu ima 10 milijuna jedinstvenih itema (najčešće su to office dokumenti). Drugim riječima, najkritičniji dio je plan egzekucije queryja (ajmo reći da bi to bila kao optimizacija DBMSa). E sad, problem leži u tome što imaš recimo, jedan plan koju se izvodi do, bzvz govorim, 10k zapisa, međutim, ako baza pređe taj trashold, s aktualnim planom sve ode, da se lijepo izrazim, u k**** (DBMS, recimo, počne overhead zapisivati na HDD prilikom manipulacije podacima).
Druga stvar koja može biti je da se sam bussiness model promjeni (rekonstruiranje, promjena metodologije, spajanje, puhnulo manageru u glavu) i promjenu poslovnog modela mora, naravno, pratiti i baza (odnosno dolazi do promjene ERa).
U oba slučaja ti bi morao svaki pojedini test nanovo pisati. Kada se baca softver u produkciju, on mora proći provjeru svakog pojedinog elementa (bez obzira jer taj dio bio zahvaćem novom verzijom ili nije). Diranje produkcijskog servera je najkritičniji dio i on se uglavnom dira "van radnog vremena" (bio to vikend ili 3 ujutro, zavisi od klijenta), jer, naravno, sam klijent ima financijski gubitak za vremenski period kada se deploya nova verzija.
Znači softver bi morao proći sve testove (koji bi možda morali biti nanovo napisani za aktualnu verziju), i opet proći odoborenje QA i BI tima, te inžinjera implementacije.
Na ovo sve, postoje dijelovi koji se jednostavno ne mogu "provući" kroz testove, prvenstveno UI -> opet, recimo, da poslovni model je takav da u jednom trenutku za neki input ja trebam dinamički generirati, recimo, do 20 labela. I CSS to može podnijeti. Promjeni se poslovni model i ja moram generirati do 25 labela. CSS puca, ali kod prolazi test (jer tehniči gledano on je napravio što se od njega traži).
Neću tvrditi, ali koliko znam, kvaliteta mreže, mrežna infrastruktura i šum na mreži se ne može testirat TDDom (odnosno kako se aplikacija nosi sa underlying layerima) -> nešto što ćeš itekako susretati u enterpriseu, pogotovo u... Uvijek zaboravim ime... High neki vrag programiranje (burzovne-like aplikacije).
Suma summare - kod enterprise se radi o nekom iterativnom tipu razvoju (posebice nakon inicijalnog deploya) jer se zahtjevi klijenata mogu mjenjati iz sata u sat (i čak se zna i raditi deploy i redeploy tehnikama poput shadow copy - znači da produkcijski server se ne gasi / resetira) i trebao bi omanji odred Kineza da ti pišu / prepravljaju testove.
I samo da napomene, ovo jest pogled kroz .NET enterprise ekosistem, sa iznimkom tog High što već, gdje moraš koristiti linux (i goli C) zbog specifičnosti zahtjeva gdje se od programera traži da radi na tolko niskoj razini da može namirisati metal.
Da li je na Javi što drugačije ne znam, no na Oraclu nije.
Mene isto poprilično fascinira to što su negdje testovi obavezni. Kao što je kolega gore rekao nama se specifikacija svega i svačega promjeni u trenu. Održavam (sam) relativno velik bankarski softver (nas 3-4 ga je razvijalo cca 3 godine, winforms) i uopće ne mogu zamisliti kakvi bi to testovi morali biti da se to testira. Primjerice - jedan objekt ima cca 150 property-ja. Isto tako ima i recimo 40 child objekata (i to tako može ići 4-5 levela u dubinu jer su liste u pitanju). Imamo doslovce hrpetinu koda koja brine o tome da se npr u slučaju promjene property-ja A property B setira na neku vrijednost (ili se obriše jedan item iz neke child liste i sl). A pri tome se u nekim slučajevima treba dići neki event a u nekima ne. Neke od tih stvari trebaju biti popraćene i promjenama na samoj formi (nešto se sakrije, nešto prikaže, nešto promjeni boju, otvori se neki popup i sl). Ovdje pričamo o recimo 100k linija koda (uzevši u obzir parent i child klase) za jednu vrstu dokumenta na kojima useri rade. Da stvar bude gora, ovisno o redoslijedu promjena nekih property-ja stvar se treba ponašati drugačije. Takvih dokumenata ima dosta i logika im se znanto razlikuje. Na nekima čak useri mogu raditi paralelno!
Meni je zato potpuno nezamislivo kako bi trebali izgledati testovi koje bismo mi nakucali i prije deploya nove verzije pokrenuli i da mirne duše možemo reći da je softver ispravan. Koliko bi trajalo pisanje/održavanje tih testova?
Stvar je u tome da pisanje testa + pisanje koda < pisanje koda + popravljanje bugova.
Takodjer - pisanje testa je puno jednostavnije od pisanja koda, i forsira kvalitetan dizajn. Ako code koji si napisao ne moze na testiranje - znaci da prije svega ne postuje law od demeter, nakon toga nije slabo povezan (loose coupling) i ostale OOP dzidze-midze koje postoje da bi olaksale razvoj i upgrade softwarea. A i ne bi se cudio da ljudi ne kuze kompletno kako to sto su napisali funkcionira.
Takodjer - uvrijezeno je misljenje da ljudi trebaju pisati testove za sve, sto je naravno glupost. Accessori i mutatori imaju doslovce jednu liniju koda i compiler (da li bytecode ili JIT) ih iovako ionako inlineira. Sta cemo testirati onda, postavljanje vrijednosti varijable? Testirati treba kako se klasa/komponenta ponasa. Design by contract je metodologija razlicita od TDD-a jer testove sadrzi unutar release builda i smatra da nema nikakvog smisla ukloniti testove. Ja se s time ne slazem, no DBC definitivno dobro/bolje objasnjava od TDD-a sto je, i zasto, potrebno testirati. Treba testirati da li ce, npr. klasa okinuti event pod odredjenom konfiguracijom, a pod svim ostalima ne - ili suprotno. Treba testirati da li klasa obavlja svoju funkciju i sa pogresnim unosom - odnosno, baci exception.
Treba testirati da li su resursi koje klasa otvara - zatvoreni. Ovo je zanimljiv primjer, jer je to tehnicki nemoguce, s obzirom da klasa drzi referencu na resurs koji iovako ionako treba biti privatan. Sto znaci da treba primjeniti malo arhitekture iz C++ i ugurati alokacije sistemskih resursa na jedno mjesto (Cache?) koje ce ih odrzavati i poolati.
Pristup arhitekturi moze biti dvojak, ili stavljas odgovornost koristenja na usera, ili bulletproofas klasu da podnese pogresan usage. Ako ukljucis logiku i razmislis da nitko nece namjerno krivo koristiti klasu, znaci da mozes klasificirati vecinu bugova u nerazumijevanje interfacea klase, dok ostatak otpada na bugove unutar same klase.
TDD rijesava oboje. S jedne strane, forsira jednostavan dizajn klase i pravilnu interoperabilnost s drugim klasama, s druge strane testira da je klasa 'bulletproof' ako se pravilno koristi, bez ostavljanja tih testova u release kodu.
Po mojem iskustvu, najveci otpor TDD-u dolazi od navike na 'ho-ruk' dizajn, koji u nekim segmentima posla i moze biti koristan (video igre) jer nema legacy koda, tj. iovako-ionako sve isprepises nanovo svakih 5-6 godina.
U businnes kodiranju, prepisivanje se uglavnom dogadja kad je legacy code nemoguce odrzavati, a to se dogadja kad legacy code ne mozes refactorirati - a to je direktno posljedica codea koji ne mozes testirati.
Stvar je u tome da pisanje testa + pisanje koda < pisanje koda + popravljanje bugova.
Takodjer - pisanje testa je puno jednostavnije od pisanja koda, i forsira kvalitetan dizajn. Ako code koji si napisao ne moze na testiranje - znaci da prije svega ne postuje law od demeter, nakon toga nije slabo povezan (loose coupling) i ostale OOP dzidze-midze koje postoje da bi olaksale razvoj i upgrade softwarea. A i ne bi se cudio da ljudi ne kuze kompletno kako to sto su napisali funkcionira.
Takodjer - uvrijezeno je misljenje da ljudi trebaju pisati testove za sve, sto je naravno glupost. Accessori i mutatori imaju doslovce jednu liniju koda i compiler (da li bytecode ili JIT) ih iovako ionako inlineira. Sta cemo testirati onda, postavljanje vrijednosti varijable? Testirati treba kako se klasa/komponenta ponasa. Design by contract je metodologija razlicita od TDD-a jer testove sadrzi unutar release builda i smatra da nema nikakvog smisla ukloniti testove. Ja se s time ne slazem, no DBC definitivno dobro/bolje objasnjava od TDD-a sto je, i zasto, potrebno testirati. Treba testirati da li ce, npr. klasa okinuti event pod odredjenom konfiguracijom, a pod svim ostalima ne - ili suprotno. Treba testirati da li klasa obavlja svoju funkciju i sa pogresnim unosom - odnosno, baci exception.
Treba testirati da li su resursi koje klasa otvara - zatvoreni. Ovo je zanimljiv primjer, jer je to tehnicki nemoguce, s obzirom da klasa drzi referencu na resurs koji iovako ionako treba biti privatan. Sto znaci da treba primjeniti malo arhitekture iz C++ i ugurati alokacije sistemskih resursa na jedno mjesto (Cache?) koje ce ih odrzavati i poolati.
Pristup arhitekturi moze biti dvojak, ili stavljas odgovornost koristenja na usera, ili bulletproofas klasu da podnese pogresan usage. Ako ukljucis logiku i razmislis da nitko nece namjerno krivo koristiti klasu, znaci da mozes klasificirati vecinu bugova u nerazumijevanje interfacea klase, dok ostatak otpada na bugove unutar same klase.
TDD rijesava oboje. S jedne strane, forsira jednostavan dizajn klase i pravilnu interoperabilnost s drugim klasama, s druge strane testira da je klasa 'bulletproof' ako se pravilno koristi, bez ostavljanja tih testova u release kodu.
Po mojem iskustvu, najveci otpor TDD-u dolazi od navike na 'ho-ruk' dizajn, koji u nekim segmentima posla i moze biti koristan (video igre) jer nema legacy koda, tj. iovako-ionako sve isprepises nanovo svakih 5-6 godina.
U businnes kodiranju, prepisivanje se uglavnom dogadja kad je legacy code nemoguce odrzavati, a to se dogadja kad legacy code ne mozes refactorirati - a to je direktno posljedica codea koji ne mozes testirati.
Ma nije meni problem održavati to što održavam. Iako je stvarno tona koda u pitanju i svako malo se nešto promjeni. Radi se o tome što ja ne razumijem kako bi pisanje testova + kodiranje bilo prihvatljivije od pisanja koda + ispravljanje bugova. Radi se, konkretno, o kreditnoj proceduri koja se sastoji od gomile dokumenata i usera koji rade na tim dokumentima paralelno u životu jednog "parent" dokumenta.
Kako testirati tisuće mogućih kombinacija života dokumenta koji se šalje vamo-tamo i u svakoj situaciji na njemu vrijedi drugačiji set pravila i shodno tome UI je totalno drugačiji? Npr, jedan dokument može imati 400-500 validacijskih pravila (a ovisno o vrijednosti koje validacijske procedure vrate promjeni se n drugih property-ja u dokumentu i masa toga na UI-u). Teško mi je sada objasniti sve u detalj ali radi se o stvarno dosta toga što funkcionira kao cjelina i nema smisla raditi test neke male cjeline ako njeno ponašanje ovisi o 50 drugih objekata. Lako je testirati snimanje i učitavanje podataka ali kako testu podvrgnuti sve potencijalne brljotine koje user na formi sa 40 tabova može napraviti?
Ne znam, meni je to nezamislivo. Pogotovo uzevši u obzir da se pravila mijenjaju barem 2-3 puta tjedno.
Pa, cuj... kao i sve drugo, TDD je alat. Nema smisla cekicem zabijati vijke, right?
Sasvim je moguce da na tvojem konkretnom primjeru, TDD bi donio vise grinda (birokracijskog kodiranja) nego koristi, dakle, odluka da se ne koristi je ispravna.
Kvalitetan programer ce odabrati alate prema problemu; guranje jedne metodologije ili alata naslijepo je, doslovce, kao da kazes da je cekic idealan alat za svaki posao.
Jedan primjer, 3D engine koji razvijam kao pet-project nema ni jednu jedinu liniju test codea, ali ipak - engine razvijam sam samcat, dakle uklonio sam jedan od glavnih problema modernog developmenta: timski rad.
S druge strane, Cheetah ("Age of Conan" i "The Secret World" rendering engine) ima prilicno kompleksan test suit, baziran na komparaciji slike, koji se pokrece prilikom svakog builda - koji se naravno pokrece prilikom svakog check-in. Avalanche Studios ima performance test suit za svoje shadere, nedavno sam pisao o tome.
Blizzard ima test-suit cak i za questove u WoW-u!
I sve slijedi TDD: sve je automatizirano, sve ce skrsiti build ako ne zadovolji, i kako prosiruju igru dalje - testovi koje moraju proci su napisani prije novog contenta.
Kasno upadam u raspravu, ali evo mojih 5 lipa:
- radim unit testove iako nazalost ne na pravi TDD test first nacin. Iako konceptualno znam kako ide taj test first, u praksi ga jos nisam primjenio
- pisem testove za dio sa nekom poslovnom logikom, slabo ili nikada za "infrastrukturni" dio nekog frameworka, npr dali model binder ispravno binda podatke u nekoj MVC akciji
- puno vaznije je nauciti pisati decouplan kod, da to stvarno bude unit test, a ne integracijski/funkcijski test.
- polako se prebacujem na BDD (nspec, specwatchr)
