"A tesztelendő függvény egy fekete doboz"
Az az integracios teszt, kedves.
"jó esetben előbb készül a teszt és utána az implementáció,"
Ez igaz, ez a TDD, csakhogy unit teszt eseteben a konkret tesztelt osztalybol nem is szabad kistubolni semmit, legfeljebb mockkal lehet megmondani, hogy milyen hivasoknak kell megtortennie.
"Stub-nál és mock-nál pontosan tudod miket hív meg, nézed az implementációt és aszerint írod a tesztet."
Mert olyat stubolok ki, amit _mindenkeppen_ meg kell hivnia az implementacionak is. Segitek peldaval: az AuthService tesztjenek esetben ki fogom stubolni a UserService.getUser("userID")-t meg az AuthService kodjanak leirasa elott, hiszen tudom (le van irva a ruhes dokumentacioban!), hogy az usereket kizarolag az UserService.getUser() fuggvennyel lehet eloszedni, sehogyan mashogyan. Ha kezenallva gepelem be a kodot, akkor is igy kell tortennie. Vagyis en nem az implementaciot nezem, hanem a nyuves dokumentaciot, ahol le van irva, hogy minek kell tortennie.
Ezert mas az integration teszt mint a unit teszt. Ugyanis az unit test eseteben engem mocskosrohadtmodon nem erdekel akar az sem, hogy a UserService egy olyan interfesz, amit semmi nem implemental, hiszen nekem az AuthService tesztjeben abbol semmire nincs szuksegem, csak arra, hogy ha az AuthService meghivja a UserService.getUser-t, akkor ne NPE-t, ne null-t es ne NotImplementedException-t kapjon, hanem egy tetves User objektumot. Meg a User objektum tartalma is irrelevans! Az User objektum tartalma akkor lesz relevans, ha a ket service kozotti interoperabilitast tesztelem, ami az integration tesztnek a resze. Nem az unit teszte!
A faszikam peldai meg eroltetettek egytol-egyig. Olyan mockolos peldakat mutat, amiknel szetszervezes nelkul sincs szukseg a mockolasra, mert nincs relevans kulso fuggoseguk. Ami a VendingMachine-os peldat illeti, attol, mert lesz egy olyan service-d, ami nem fugg az adatbazistol, meg nem fogod lefedni azokat az eseteket, amikor a hiba van az adatbazislayerben, es a te service-d nem tudja elkezelni ezeket a problemakat, hiszen a teszt service baromira nem fog adatbazis exceptionoket dobalni. Ha osszemosod a unit es integration teszteket, akkor ezeket a dolgokat nem tudod ertelmesen letesztelni, hiszen valojaban te nem a kerdeses service-t hivogatod, hanem valami legbolkapott cuccot, aminek a jo mukodese a kutyat nem izgatja.
Az ilyen metodologiabol jonnek azok a problemak, hogy "de hat a tesztek alapjan ennek mukodni kell, a production-be miert nem megy?".
Eleg peldat adott, hogy megertsem a lenyeget: 1) legalabb harom dolog mosodik ossze a fejeben, 2) nem latott meg normalis mocking/stubbing real world example-t, es 3) csak olyan emberekkel kommunikalt eddig, akik nem ertettek meg a mocking/stubbing lenyeget.
--
Blog | @hron84
Üzemeltető macik