NetAcademia

A legjobbakat tanítjuk!

A leggyakoribb érvek a unit tesztek írása - ellen :)

2016. május 31. 08:00 - Plesz Gábor

Egy érdekes írás a unit tesztek írása ellen felmerülő leggyakoribb érvekről, és ezek kritikájáról.
A szerző arról ír, hogy miközben megismerkedett a unit tesztelés világával kénytelen volt felismerni, hogy nagyon egyszerű ellene érvelni. Még akkor is, ha az ember úgy érzi: érti a lényeget. Ennek pedig az a következménye, hogy a legtöbb fejlesztő azt érzi, hogy ingoványos terepen jár: könnyen kritizálható lenne, ha belefogna, tehát talán nincs kellő felhatalmazása arra, hogy unit teszteket írjon.
Ezért az írás arra keresi a választ, hogy mennyi felhatalmazásra van valójában szükség, és hogy ezt hogy lehet megszerezni, valahogy így:

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?

Azért nem írunk unit tesztet, mert nem vagyunk róla meggyőződve, hogy alapvetően szükséges a kapott feladat elvégzéséhez. Panaszkodunk, hogy a főnökünk nem akarja, hogy unit tesztet írjunk. De a probléma az, hogy első lépésként engedélyt kérünk unit tesztek írásához. És mivel kérjük az engedélyt, tulajdonképpen azt kommunikáljuk a főnökünk felé, hogy a unit teszt az opcionálisan választható dolog. Így aztán főnökünknek nemet kell mondania, hiszen ő is úgy gondolja, hogy nem egy feltétlenül szükséges dologról beszélünk.

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.

2 komment

A bejegyzés trackback címe:

https://netacademia.blog.hu/api/trackback/id/tr218757784

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

midnight coder 2016.05.31. 15:55:12

Az unit teszt írása alsó hangon is megduplázza a fejlesztési időt. Ha a menedzser (= főnök) erre nem allokál külön időt, akkor vagy megírod munka után, vagy csúszni fogsz a projekttel. Az most egy másik kérdés, hogy utána a projekt biztonságos fenntartását olcsóbbá teszi, de a fejlesztési időt bizony megdobja, így ha ezt a menedzsment nem tervezi be, akkor bizony nem lesz meg (hacsak nincs _nagyon_ lazán tervezve a fejlesztési idő, ami azért idehaza nem annyira jellemző). Ez nem a fejlesztő döntése, és különösen nem a mezei fejlesztőé aki fölött általában ül egy TTL is, aki eleve tökön rúg ha olyasmit küldesz be a TFS-be ami nincs betervezve a projektbe.

Plesz Gábor · https://www.netacademia.hu/Oktato/PleszGabor 2016.06.09. 14:57:33

@midnight coder: Köszönöm a visszajelzést, ezt a cikket én is inkább megosztónak érzem mint egyesítőnek, ezért is gondoltam érdekesnek:)
Az érdekes kijelentése a cikknek az, hogy a jóval több fejlesztési idő a tanulási görbe elejére ugyan igez, de ahogy a programozó gyakorlottabbá válik, úgy jelent egyre kisebb többletköltséget a unit tesztek írása ráfordított időt tekintve.