Valóban szükség van felhatalmazásra?
- Valóban szükség van felhatalmazásra?
- Ahhoz is kérsz felhatalmazást, ha a fordítod és buildet készítsz a kódodból?
- Kérsz felhatalmazást minden sorhoz, amit leírsz?
- Szükséged van felhatalmazásra ahhoz, hogy időről időre futtasd a kódodat, hogy ellenőrizd a végeredményt?
- Szoktál rendszeresen olyan részeked hozzáadni a kódodhoz, amitől jobban érzed magad, de nem feltétlenül illeszkedik pontosan abba a feladatba, amit éppen el kell végezni? (Kis segítség: nem hiszem, hogy ismerek olyan fejlesztőt, aki ilyet nem tesz.)
- Tehát: tényleg úgy érzed, hogy a unit tesztek írásához szükséged van felhatalmazásra?
Meg vagy róla győződve, hogy szükséged van a tesztekre?
Ezt nem a főnököd dolga eldönteni
Nem az ő dolga megérteni, hogy nem tesztelni valamit műszaki adóssághoz (erről majd még lesz post, addig is itt, itt és itt lehet magyarul utánaolvasni) vezet. Valószínüleg az sem érdekli különösebben, hogy mi is az a műszaki adósság. Minden amire neki figyelnie kell az a következő: Mikor lesz kész ez a projekt? Ha pedig azt mondod elkészültél, pontosan úgy fog működni, ahogy el lett képzelve, vagy pedig lesz egy csomó hiba még benne, amit ki kell javítani?
A legtöbb főnök, akivel én a múltban dolgoztam elfogadott bármilyen számot, miután megértette, hogyha én átadok egy programot, akkor az utána működni fog. Tulajdonképpen azért kaptam a feladatokat én, mert az én kódom sokkal inkább hajlamos volt működni, mint bárki másé, aki még el tudta volna végezni az adott munkát.
Elfogadom, vannak olyan helyek, ahol egyértelműen megmondják, hogy ne írj unit tesztet. De nyugodtan ki merem jelenteni, hogy ez azért van, mert valaki korábban engedélyt próbát kérni.
Miért?
Most pedig értsük meg, miért gondoljuk azt, hogy a unit teszt opcionálisan választható? Valószínűleg azért, mert már régóta dolgozunk így, és úgy tűnik működik. És ha megpróbáljuk bevezetni a unit tesztek írását, akkor a folyamatok úgy tűnik, hogy lelassulnak. És ez így is van. Kezdetben, amikor unit tesztek írunk az lassabb folyamat, pontosan úgy, mint amikor valamit egy számunkra új nyelven írunk, vagy egy új keretrendszert használunk, vagy bármi más, mivel új, az lassabb, mint amit már ismerünk. De az állításom az, hogy a unit tesztek által a végeredménybe beépített hatékonyság bizonyítottan többet ér, mint a tanulási folyamatba fektetett energia.
Persze van más elfogadható érv a unit tesztek írása ellen, például, ha egyszerűen nem tudunk unit tesztet írni. Ez szinte már olyan fontos indíték, mint azt hinni, hogy nem érdemes unit tesztet írni. De én úgy látom, hogy ha elfogadjuk, hogy a tesztelés értelmes dolog, akkor egyszerűen kezdjünk el teszteket írni, és nézzük meg, hogy ez hova vezet.
Ne gondold azt, hogy az elég jó a tökéletes ellentéte. Az első tesztjeid valószínüleg szemétbe mennek majd. Ha visszatekintünk a pályafutásunkra, én azt tippelem, hogy van egy csomó dolog, amire nem godoltunk a kezdetek kezdetén. Tényként kezelhetjük, hogy a legtöbben munka közben tanulunk. Alapvető ismeretekkel elkezdünk dolgozni, és a fejlesztések közben amikben részt veszünk, napról napra továbbfejlesztjük ezeket az ismereteket. Ahogy bírkózol majd a tesztekkel, csodálkozni fogsz, mit is gondoltál, amikor az első tesztjeidet írtad. De ez ne riasszon el. Ugyanez történt, amikor először elkezdtél kódolni. Talán még a mai napig megtörténik. Ne aggodj, ezt teszi a gyakorlat, ahogy egyre jobb teszteket, és egyre jobban tesztelhető kódot írsz.
És persze van még egy ok, amiért nem írunk tesztet. Egyszerűen azért, mert a kód, amit most írunk nem tesztelhető. De ez már egy másik írás címe.
