Tegnap felhoztam a temat a kollegaknak. Gondoltam kuldok nekik linket is, mert emlekeztem a topicra, ugyhogy most jol fel is tamasztom a szalat :)
> Ha te nem szigeteled el a tesztelt egyseg fuggosegeit, akkor elveszted a unit tesztek nagy elonyet, a "defect localization"-t
Erre a problemara nem csak egy megoldas letezik, es szerintem a masik eletkepesebb lehetne. Mar csak meg kell valositani :)
Mindent unitteszteljunk es szorjuk tele az egeszet mockokkal, amik miatt majd vagy nem tudunk refaktoralni, vagy a tesztjeink semmit se ernek, mert bele kell nyulni, mert a mock implementaciohoz kototte a tesztet helyett pl. defect localization-t ugy lehetne megoldani integration tesztek eseteben, hogy fel kell epiteni egy dependency fat (ahogy barmelyik IoC/DI framework is teszi), majd az integracios teszteket a levelektol elkezdve kell futtatni visszafele.
Mivel a levelek jo esellyel vagy pure functionok lesznek (ld alabb az idezetet*), ezert azokat trivialis unit tesztelni, vagy pedig I/O muveletet vegeznek, azokat meg ugyis mockolni/stubolni/test doubleni kell, mig az integracios tesztek futhatnak szintenkent visszafele.
Ezzel tobb legyet is utunk egy csapasra. Pure function-t unit tesztelni trivialis. Valami bemegy, mas meg kijon, ellenorizzuk es orulunk (igazi black-box teszt). Masreszt az integracios tesztek eseteben egyertelmu lenne az, hogy hol van a problema, mi az ami megdontotte a kartyavarat, es mar az alsobb szinteken akar fail fast modon, akar a reportingban kiemelve lehet latni azt a komponenst, amelyik eloszor volt erintve a hibaban. Onnan meg mar egyszeru a fix, nem kell orakig debugolni.
Mar csak annyi a problema, hogy implementalni kellene...
*: I'd take a slightly different take:
- Structure your code so it is mostly leaves.
- Unit test the leaves.
- Integration test the rest if needed.
I like this approach in part because making lots of leaves also adds to the "literate"-ness of the code. With lots of opportunities to name your primitives, the code is much closer to being self documenting.