Testovani – testovani modelu a jednotlive typy testu

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Felix
Nette Core | 1183
+
0
-

Ahoj,

rad bych znal vas nazor na rozdeleni testu modelu aplikace. Prosim, pristupujte k tomu jako k diskuzi, kde kazdy muze mit jiny nazor. Nerad bych z toho vytvoril flame-hate-full vlakno.

Predstavme si aplikaci, ktera vypisuje clanky a ma jednoduchou administraci.


Unit testy

  • chapu jako testy jednotlivych casti, resp. trid
  • napriklad trida na parsovani clanku z xml, trida na konvertovani, filtrovani atd, zkratka deterministicke tridy

Integracni testy

  • chapu jako testy, ktere vyzaduji nejakou jinou cast / logiku, napriklad pripojeni do DB
  • tzn, otestuju jestli aplikace dokaze ulozit clanek, vylistovat a nacist ho

Celou dobu jsem zil v domneni, ze integracni testy jsou prave ty co vyzaduji databazi, cizi api, zkratka nejakou sluzbu, kterou ja nemuzu otestovat.

Setkal jsem se s tim, ze nekdo povazuje za integracni testy treba testy fasad. Fasada, naparsuje data z formulare, ulozi do clanek do databaze a posle email administratorovi.

Mne se to ale jevi porad jako unit test. Jenom obtiznejsi pro otestovani, protoze musim spoustu veci namockovat.


Jak to chapete vy? Rad bych v tom mel jasno. Jake dalsi typy testu jste v PHP pouzili?

Dik za nazory.

Svaťa Šimara
Člen | 98
+
0
-

Inu unit test je od slova jednotka. Testuju co nejmenší část kódu a mám plně pod kontrolou všechny závislosti (pomocí mocků) i vstupy a kontroluju výstupy (případně chování).
Unit test můžu mít i na rozhraní, za kterým se schovává kdoví co – klidně více objektů, které si daná implementace obhospodařuje sama. Řekl bych, že unit testy chápeme stejně.

Integrační test od slova spojování. Spojím více objektů systémů dohromady a testuju. V Tvojem případě napojím konkrétní implementaci parseru, konverteru a filteru (pravděpodobně do zastřešujícího importéru), předhazuju XMLka a dívám se, co mi z toho importéru leze. V integračním testu nepoužívám databázi – to už je další systém, ve kterém se děje kdoví co. Místo databáza mám mock (konkrétně využívám repozitáře, a místo nich mám mock).

Poslední krok, který používám, je takzvaný systémový test – celý systém propojený dohromady (s databází), který testuju přes rozhraní systému. Mám velkou výhodu, že dělám API, takže mám rozhraní systému jasně definované, testovat přes formuláře může být dost fuška.
Nic mi ale nebrání udělat systémový test na určitou podčást – např. pokud mám vstvy UI → Application → Domain → Infrastructure (DB), tak udělám systémový test na Aplikační vrstvu. Aplikační vrstvu beru jako rozhraní, a testuju proti ní. Jednou metodou aplikační služby nasypu XML, druhou metodou získám zapsané entity a kontroluju, jestli vše odpovídá očekávání. Mezi těmito dvěma kroky ještě mažu cache (u mě konkrétně doktríňácký entity manager, aby si druhá metoda opravdu musela do databáze šáhnout).