[degojs]

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