Koszi szepen mindenkinek, mostmar tenyleg raszanom magamat egy belsos eloadasra, mert mar elegem van belole, hogy mindenki a unit teszteket nyomatja, az en allaspontomat meg nem ertik meg, mert a komplex temat kis adagokban nem lehet atadni. Szoval most azt hiszik, hogy azert utalom a mockokat, mert nem ertek a teszteleshez, a csapatom meg elkuldott TDD eloadasra is, hatha meggyoznek :)
Irtam is nekik Slack-en, hogy tok jo, hogy elkuldtetek, eddig semmiben nem mondtak nekem ellent... meg azt se gyoztem hangsulyozni, hogy nem a unit tesztek, meg a TDD, hanem a mockok ellen vagyok.
Ugyan nem olvastam meg vegig az osszeset, de azert megnyugtato, hogy masok is ezen a velemenyen vannak, illetve jo forras lesz az eloadashoz, nem kell mindent fejbol leirkalnom :) Mondjuk valoszinuleg lesz egy-ket dolog, amit mashogy kepzelek majd el a tobbiekhez kepest, na meg arrol se art szot ejteni, hogy egy hogy jon ossze clean code-dal, hogy erdemes felepiteni egy projectet, hogy jol tesztelheto legyen, hogy az IO-t kell mockolni (en meg a Date-et is ide sorolnam, az is egy syscall az OS fele altalaban), mast nem,
Hogy az IO mockolas segitsegevel hogy tudjuk megvalositani a 100%-os verifikaciot. Minden almom az, hogy a kod belso szerkezetet is BDD szeruen (a lenyeget tekintve, termeszetesen nem akarok Gherkinnel szorakozni, API tesztelesre amugyis szornyu volt) lehessen tesztelni, ahol az szamit, hogy mit csinal a fuggveny, nem az, hogy hogyan csinalja.
Ezzel baromi konnyen meg lehet valositani olyan teszteket, hogy "ez a kiindulo feltetel, ezt csinaljuk, ennek ez az eredmenye, ekozben ilyen interakciokat varok a kulvilaggal...".
Erdekel az, hogy egy Service-t hivott meg a fuggveny, vagy egy Facade-t? Nem. Erdekel, hogy az adatokon milyen konverziot vegez? Nem.
Mi erdekel? Az, hogy mi lett a vegeredmeny, es kozben milyen hatasok tortentek a kulvilagra. A belso folyamatok tok nem lenyegesek. Black/white box teszt az igazi :)