Igen, viszont innentol kezdve n+1 AuthService implementaciot kell fejlesztened, hiszen fejlesztened kell a "normal" kodos service-ket plusz, a tesztben levot is, raadasul azt is ugyanugy karban kell tartanod. Hatrany: a teszt-ben levo AuthService-t a kutya nem fogja letesztelni semmire, hiszen a mocking ugyebar rossz, vagyis a jo isten se tudja, hogy a tesztben levo "egyszeru" implementacio mit ad vissza, illetve mikor adhat vissza rosszat, a coverage egy budos nulla lesz rajta. A tobbi teszt meg "best wishes" alapon hivkodja a TestAuthService-t, es baromira imadkozik, hogy a nyero kombinaciok jojjenek ki.
Egy stub annyibol jobb ennel, hogy a teszt elejen (anelkul hogy teljes mertekben implementalnod kellene az adott service-t) elore megmondhatod, hogy a teszt szempontjabol miknek kell tortennie.
Az eloado ott hibazott, hogy a stubbingnak egy rossz hasznalatat hozta fel. Ha nekem az authLocalUser-re kell tesztelnem, akkor nyilvan nem hasznalhatom az authUser-re felkeszitett stubokat, de nincs ertelmes ember a foldon, aki igy akarna hasznalni oket. Az, hogy a stubb elcsapja magat egy exceptionnel, hogy o bizony semmit nem tud az authLocalUser-rol, az egy teljesen hasznos failure, hiszen megmutatja azokat a pontokat, ahol a tesztet a valos kodhoz kell igazitani. Olyan, mintha egy NoSuchMethodException vagy egy NPE jonne fel.
A masik nagy hiba, hogy o osszemossa az unit test layert es az integration test layert. Unit testben nem az a lenyeg, hogy egy barmilyen ertelemben vett valos user be tud-e lepni a rendszerbe, ez akkor, ott a vilagon senkit nem erdekel. Az a lenyeg, hogy az az egyseg, amit epp tesztelunk, adott inputra adott outputot ad-e. Az integration teszt viszont mar nem hasznalhat mockokat, oda bizony - amennyire csak lehetseges - fel kell konfiguralni egy teszt rendszert, teszt adatokkal, es az UserService-nek az aktualisan tesztelt AuthService-t kell tesztelnie, nem csak valami zoknibabot.
--
Blog | @hron84
Üzemeltető macik