@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...

Основна разлика је што функционални тестови тестирају цео систем, а јунит тестови сасвим мало парче кода (обично један метод у класи) и "мокује" све остало. Моје искуство је да је ђаво у интеграцији: може модул А да ради како треба у изолацији, али кад га укомпонујеш у прави систем често се испостави да то не ради како треба. Зато ја више верујем функционалним тестовима - ту нема "мокова" и ништа није изоловано.

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