Ket dolgot ajanlok figyelmedbe:
http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf
(masodik resz: http://rbcs-us.com/site/assets/files/1191/segue.pdf)
Elsore fejen ut, de minel tobbet agyalok rajta, annal inkabb igazat adok Jim Coplien-nek. Annyira, hogy lassan komoly osszetuzesekbe keveredek a kollegakkal, akik abszolut TDD maniasok, es imadjak a tautologikus unit teszteket.
A mockoknak abban van szerepuk szerintem, hogy uzleti funkciokra levalasztva tudod (funkcio/integracio) tesztelni a modulodat. Vagyis, peldaul tesztelned az authentikaciot, hogy 10 sikertelen belepesi kiserlet utan lockolja az accountot. Tegyuk fel, hogy ez az authorizaciot nem erinti. Igen, de az authentikacio es az authorizacio altalaban egy blokkban van, nehez kulon tesztelni - ezert van a mock, ami az authorizacios reszek helyett fut (peldaul a jogokat egy masik adatbazis tarolja, vagy sok plusz extra informacio kell peldaul a user-group hierarchiarol), az authentikacios tesztek viszont amennyire lehet, a valoshoz hasonlo kornyezetet kapnak, peldaul valos adatbazis helyett in-memory verziot.
Ezt viszont nem ertem: "Viszont vannak tesztjeink, amik bizonyithatoan helyesek."
Mennyivel konnyebb a tesztrol bizonyitani, hogy helyes, mint a kodrol? Adott esetben meg nehezebb is... Tovabb rontja a minoseget, ha a tesztet ugyanaz irja, aki a kodot (ez ugye eleg sokszor elofordul), igy a tesztek - foleg a tautologikus tipusu unit tesztek - altalaban onigazolo jelleguek, tenyleges informaciot nem hordoznak, csak a kodmeretet novelik.