ugrás a tartalomhoz

Specifikáció változásnál hogyan szoktátok utánigazítani a kódot?

inf3rno · 2014. Május. 1. (Cs), 15.45
Specifikáció változásnál hogyan szoktátok utánigazítani a kódot?
 
1

Nekem a legnagyobb gondom

inf3rno · 2014. Május. 1. (Cs), 15.48
Nekem a legnagyobb gondom azzal szokott lenni, hogy a régi tesztek közül nem tudom, hogy pontosan melyikeket kell, hogy érintsen egy api változás. Egyelőre az tűnik megoldásnak, hogy az adott kódrészt tdd-vel nulláról újraírom, és kikommentelem a régi teszteket, amik elbuknak, de talán van más módszer is az átmenetre...
2

Behavior driven development

janoszen · 2014. Május. 1. (Cs), 22.45
Asszem pont erre talaltam multkor a "Behavior driven development" kifejezest. Az API elvben nem szabadna hogy ugy valtozzon hogy eltorjon barmit is, tehat itt az integracios tesztek irasa lehet a valasz igazabol. Ha valtozik a funkcionalitas, akkor az integracios tesztet kell utana huzni es annak megfeleloen ugyis latod milyen unit tesztek halnak el.
3

Ez elméletben könnyű, a

inf3rno · 2014. Május. 2. (P), 00.32
Ez elméletben könnyű, a gyakorlatban viszont nem ennyire egyszerű, amikor minden teszt pirosba vált egy jelentéktelennek gondolt változtatástól.

Lehet, hogy mindez csak rossz tervezés eredménye, de én első ránézésre nem látom, hogy melyik tesztek fognak eltörni, ehhez mindegyiket egyesével végig kéne nézni, hogy pontosan mit használnak az api-ból, és a változtatás hatással lesz e rájuk. Persze, ezt meg lehet csinálni, de gondolom van azért rá jobb módszer is. Egyelőre még csak integrációs tesztekről sincs szó, egyetlen osztály mindössze, aminél a tesztek fele nem működik, mert aktívan használ egy hibásan tervezett megvalósítást. Az eltérés pedig csak annyi, hogy a `valid()`-re false-t ad az első ciklus előtt, nem pedig true-t. Valószínűleg végigmegyek minden teszten, aztán egyesével átírom vagy törlöm őket, csak hát idegesítő, hogy újra kell írni a tesztek felét egy ilyen jelentéktelennek tűnő dolognál. Gondoltam hátha vannak best practice-ek, amivel az ilyesmi megakadályozható...
4

Érdekes témakör

szjanihu · 2014. Május. 2. (P), 01.10
Érdekes dolog ez. A napokban/hetekben sokat beszélgettem erről és a kapcsolatos dolgokról az egyik kollégámmal. Már eleve az nem egyértelmű, mi is a unit teszt, mi a unit? :)

Abban a legtöbb programozó egyetért, hogy költséges a tesztek karbantartása, egy kis változtatási igény is rengeteg tesztet érinthet. Ez senkinek se jó. Ennek a legtöbbször a rengeteg mock az oka. Véleményem szerint normális architektúrával elérhető az, hogy viszonylag kevés és viszonylag jól körülhatárolható területet kell, és lehet csak úgy lefedni tesztekkel, hogy mockokat kelljen használni. Ez a videó rávilágít erre, de legalábbis elgondolkodtatja az embert.

Janoszennel egyetértek, behaviourt kell tesztelni, ez viszont nem jelent integrációs tesztelést. Ha csak kényszeresen kimockolsz mindent és a kódod legmélyét teszteled anélkül, hogy a teszted egy valós felhasználási esetet szimulálna, akkor az a teszt nem sok mindenre jó. Ha két hét múlva eltörik, fogalmad sem lesz arról, miért törik, egyáltalán hogy mit is tesztel valójában és ezen a gondosan megválasztott tesztmetódus elnevezés sem segít. Ez oda vezet, hogy ignorálod/kikommentezed, végül törlöd, ez pedig óriási rizikófaktor.

Itt például azt tesztelem, hogy egy feldolgozatlan üzenetet a messabus újra elküld-e egy DeadMessage objektumba csomagolva. A message busnak van néhány függősége, amiket kimockolhatnék és tesztelhetném a belső állapotokat. Valójában amire kíváncsi vagyok, hogy az előbbi viselkedést produkálja-e a bus. Ez azonban nem integrációs teszt. Nem használ külső erőforrást, nem ír/olvas fájlt/hálózati erőforrást/adatbázist, stb.

Azt talán a legtöbb, unit tesztet aktívan használó programozó tudja, hogy a coverage szükséges, de nem elégséges: valódi tesztelés nélkül is meg lehet hajtani a production kódot. Viszont valóban jó teszteket írni egyáltalán nem egyszerű :)
5

Itt például azt tesztelem,

inf3rno · 2014. Május. 2. (P), 03.58
Itt például azt tesztelem, hogy egy feldolgozatlan üzenetet a messabus újra elküld-e egy DeadMessage objektumba csomagolva. A message busnak van néhány függősége, amiket kimockolhatnék és tesztelhetném a belső állapotokat. Valójában amire kíváncsi vagyok, hogy az előbbi viselkedést produkálja-e a bus. Ez azonban nem integrációs teszt. Nem használ külső erőforrást, nem ír/olvas fájlt/hálózati erőforrást/adatbázist, stb.

Azt hiszem ezt hívják funkcionális tesztnek. De ahogy néztem más fórumokban, ezeket az elnevezéseket mindenki keveri, és mindenki mást ért alattuk... Az integrációs tesztet is legalább kétféleképp hallottam már: a.) erőforrás vagy 3rd party keretrendszer adapterére írt teszt b.) minden olyan teszt, aminél nem mockoltuk ki az összes függőségét az osztálynak, tehát osztályok kölcsönhatását teszteljük. Ilyen definíciók terén sajnos sosem tudok igazságot tenni, mindenesetre fura, hogy alapvető dolgok terén képtelenek konszenzusra jutni az emberek, és mindig két-három dolgot értenek egy-egy szó alatt. Csodának tartom, hogy egyáltalán képesek vagyunk kommunikálni egymással... :D

Én is egyetértek azzal, hogy a viselkedést érdemes tesztelni. Annyival kiegészíteném, hogy a fejlesztés iránya is számít. A specifikációtól érdemes alacsonyabb absztrakciós szintek felé haladni, így nincs az, hogy eltér a specifikációtól az, amit éppen csinálunk, és valahogy össze kell tákolni a kettőt. Sokan csinálják pl, hogy adatbázissal kezdik a tervezést, ami egy baromi nagy hiba. Ebből kiindulva, a régi specifikációban, ami megváltozott, azt a részt, illetve az ahhoz kapcsolódó e2e, integrációs, stb.. teszteket egy az egyben ki lehet törölni a hozzá kapcsolódó kóddal együtt, aztán el lehet kezdeni újra lefejleszteni a feature-t az új specifikáció alapján. Ez nagyjából ugyanaz, mint amit írtatok, hogy az integrációs tesztektől kiindulva kell megnézni a dolgokat. Imho fel lehetne rajzolni valamilyen teszt függőségi gráfot, hogy pl az integrációs tesztek milyen unit test-ektől függenek, és úgy már könnyebb lenne pontosan megmondani, hogy egy-egy változtatás mire fog hatni. Azt, hogy egy-egy kódrésztől milyen tesztek függenek már esélytelen automatizáltan megmondani, ott már csak az újraírás marad.