Milyen tippeket tudtok adni Unit Testtel kapcsolatban?

Szia, uram.

Semmit.

Nem sokat. Nekem az istenért sem állt rá erre soha az agyam, főleg nem annyi idő alatt, ami rendelkezésre állt (pedig másfél évig dolgoztam tesztmérnökként, csakhogy az kicsit más volt) szerencsére mikor kellett egyetemen ilyesmi a számonkérésen, lehetett nélküle is elég pontot szerezni.

Nem vagyok egy klasszikus értelemben vett fejlesztő alkat, sosem szerettem ennek a módszertanával foglalkozni, sem a unit tesztekkel, sem a rétegzett alkalmazásokkal, sem hasonló szarokkal, főleg nem azzal, mikor mindent a nulláról kell felhúzni. Nagyon életszerű, ja nem. Lehet, hogy neked sincs hozzá affinitásod. Azzal meg nemigazán lehet mit kezdeni, túl kell élni és szevasz. Attól még programozhatsz később.

"TDD" inkább egy elv, semmint gyakorlat orientált dolog, mint a "Design Patterns". Az utóbbit is feladat határozza meg a hogyanját.

De lényegében, a TDD nem más, mint egy terv egy függvényre/metódusra/végpontra. Tehát, ha ez az input akkor ezt az output-tot kell produkálnia, se többet se kevesebbet. Ennyi. Tehát, ha kivételt kell dobnia (Exception, Error, ...) akkor azt. Ha null-t kell visszaadnia, akkor azt.

Nyelvfüggetlenül, ami JS-nek látszik:

#1 teszt eset:

ha metódus 0-nál kisebb int számot kap, adjon vissza nullát.

Implementáció:

function (param) { return param < 0 ? null : null }

Megjegyzés: Persze most a A?B:C miatt kellet else is, de arra nincs teszt eset, így az most egy mellékhatás, ha kötelező int-el visszatérni (van olyan nyelv, ahol nem kötelező).

#2 teszt eset:

ha metódus 0-nál nagyobb értéket kap, akkor szorozza meg 2-vel

Implementáció módosul erre:

function (param) { return param < 0 ? null : param * 2}

Megjegyzés: Igaz, itt a TDD esetén 0-ra nincs definíció, hogy mit csináljon, így az most egy mellékhatás. Nem tudjuk, hogy a 0-ra 0-át vagy null-t, netán Exception kell-e adni.

#3 teszt eset:

Ha metódus 0-át kap, akkor null-t adjon

Implementáció módosul erre:

function (param) { return param <= 0 ? null : param * 2 }

#6 voltam:

Ha úgy indítjuk a teszt leírást, hogy minden nem feldolgozható értékre adjon null-t, akkor más lesz a implementáció: Pl.:

#1 teszt eset:

ha metódus 0-nál kisebb int számot kap, adjon vissza nullát, és null-t minden más esetre.

Implementáció: leírás miatt, minden állapot null, ezért felesleges az if is.

function (param) { return null; }

#2 teszt eset:

ha metódus 0-nál nagyobb int számot kap, adjon vissza a kétszeresét, és null-t minden más esetre.

Implementáció:

function (param) {

... if (0 < param) return param * 2;

... return null;

}

#3.1 példa teszt eset

ha metódus 0 int számot kap, adjon vissza 0-át, és null-t minden más esetre.

Implementáció: 0-val való szorzás miatt úgy is 0 lesz

function (param) {

... if (0 <= param) return param * 2;

... return null;

}

Implementáció: de ez is megfelelő a teszt teljesüléséhez

function (param) {

... if (0 == param) return 0;

... if (0 < param) return param * 2;

... return null;

}

#3.2 példa teszt eset:

ha metódus 0 int számot kap, adjon vissza null-t, és null-t minden más esetre.

Implementáció: ez teljesül is a #1 és a #2 esetében, mert minden másra (tehát 0-ra) null-t ad.

function (param) {

... if (0 < param) return param * 2;

... return null;

}

6-7 voltam.

A leírásom olyan szempontból hibás, hogy a #1 #2 és a #3 teszteknek mind teljesülniük kell. Így a "és null-t minden más esetre" a nem tesztelt módokat értem.

Az egész azon múlik, hogy előre kitaláld, hogyan bontod külön komponensekre a feladatot és melyik komponens milyen funkciókért felel. Ha ez megvan, akkor onnan egyszerű, csak előbb írod a tesztet, mint a kódot.

Ha nem gondolod át előre, akkor csapongani fogsz, hogy ezt nem ide kellene tenni, hanem amoda, vagy nem ilyen paraméterlistája lesz, hanem más, akkor nagyon szívás lesz a teszteket is hozzáilleszteni / átírni és ki fogsz csúszni az időből. Bár a TDD cycle része a refactor, az nem egyenlő a redesignnal.