Én az adatbázist és a 3rd party szolgáltatókat szoktam mockolni, leginkább csak az írás részét. De ha tényleg fontos, hogy mi van az adatbázisban, akkor a tesztkörnyezet egy másik beállítást kap, ergó másik adatbázishoz kapcsolódik, és ott állítom elő a teszthez szükséges környezetet.
Amikor egy fuggveny amit mindenhol mockolsz valtozik a kimenete...pl DateTime object helyett timestamppel tersz vissza atalakitas utan. Teszteknel mindenhol mockolod, igy amikor atalakitod mindenhol mockokat is utana kell alakitanod. Ha mockok kozul egyet nem bilentesz at uj mukodesre false positive okat fognak adni a unit testjeid.
Viszont ha vannak integracios tesztjeid is azok talan meg tudjak fogni az ilyet.
Nem azon vagyok hogy ne mockolj semmit, mert adatbazis, halozati kapcsolat, fajlmuveletek stb nem unit tesztekbe valok, de amit nem muszaly mert nem nyul semmilyen lassu dologhoz nem mockolnam csak nagyon csak ha muszaj (idokezeles pl.)
Érdekes, hogy pont az időkezelést említed :) Úgy értem, ugye a mock pont attól függ, hogy a "mérési eredményeidet" függetlenítsd a környezettől. Persze ez nem feltétlenül mindenhol igaz, de több olyan esettel találkoztam már, ahol a tesztek időfüggők voltak: csak bizonyos időszakokban működtek (vagy bizonyosakban nem), avagy az elvárt értéket számolgatni kellett, esetleg rátartással. Mondjuk részrehajlás is van, én a mockoljuk amit csak lehet / érdemes híve vagyok :)
A tesztek nem jok ha ido es idozona fuggok :) Az a legjobb amikor te hatarozod meg az idot es az idozonat, mert akkor nem lesz hogy hol futnak hol nem a tesztek :/
Maskulonben fuggesz a tesztet futtato kornyezettol.
No igen. Ez a kérdés egész messze vezet, megesett pl. hogy bekonfiguráltunk a projektre három különböző statikus kódelemzőt, ami nagyon szép kódot eredményezett (aminek én mondjuk örülök), de annyira szigorú volt, hogy a tíz fejlesztőből kettő haladt értelmes tempóba, a többiek küzdöttek. Nem hiszem, hogy erre van univerzális válasz. Lennék én szivesen elitista, ha egyszer működne :D
Egyetértek, bár én inkább úgy fogalmaznék, hogy jelentősen meg tudja hosszabbítani. Ezért is bajos TDD vel. A red-green-refactor jó, de a mockolás miatt egy nagyságrenddel több időt vesz igénybe mint kéne. Én inkább utólag írom meg a tesztet emiatt.
Én egyébként nem értek egyet a cikkel, a mockok (számomra) igenis hasznosak, mert a unit teszt tényleg egy kis egységet fog tesztelni. node/iojs környezetben dolgozok, a tesztek proxyquire-ral rántják be a tesztelt modult, nagyon kényelmes (és gyors) az egész.
Persze ez csak az egyik fele a dolognak, integrációs tesztek nélkül kb teljesen haszontalanok ezek a unit tesztek (egy normális típusrendszerrel szerintem az ebből fakadó hibák nagyon nagy részét ki lehetne szűrni)
A keveset mockoljunk reszevel
Adatbázis
Tudnál egy példát mutatni
Amikor egy fuggveny amit
Viszont ha vannak integracios tesztjeid is azok talan meg tudjak fogni az ilyet.
Nem azon vagyok hogy ne mockolj semmit, mert adatbazis, halozati kapcsolat, fajlmuveletek stb nem unit tesztekbe valok, de amit nem muszaly mert nem nyul semmilyen lassu dologhoz nem mockolnam csak nagyon csak ha muszaj (idokezeles pl.)
Érdekes, hogy pont az
A tesztek nem jok ha ido es
Maskulonben fuggesz a tesztet futtato kornyezettol.
Ez így van.* És persze erre
* A példák természetesen öröklött kódból vannak :D
Igen, ez a mennyit mockolsz
No igen. Ez a kérdés egész
Egyetértek, bár én inkább úgy
Én egyébként nem értek egyet
proxyquire
-ral rántják be a tesztelt modult, nagyon kényelmes (és gyors) az egész.Persze ez csak az egyik fele a dolognak, integrációs tesztek nélkül kb teljesen haszontalanok ezek a unit tesztek (egy normális típusrendszerrel szerintem az ebből fakadó hibák nagyon nagy részét ki lehetne szűrni)
Én sem értek egyet, eddig nem
Hasonló
DHH éknek volt egy hangoutja hasonló témában, kicsit redundáns, de ha van idő érdemes belenézni.