Mi a best practice verziózásnál arra, ha az összes tesztet írom meg először?
Már egy ideje van egy olyan problémám, hogyha fejben megtervezek egy libet, előre kitalálom az API-t, írok példákat, hogy lássam tényleg elegáns e, akkor hogyan kellene ezt az egész folyamatot verziókezelnem? Ugye a példák felhasználhatóak magasabb szintű teszteknek, tehát egy az egyben be lehetne küldeni őket a teszt könyvtárba kóddal, ahelyett, hogy mondjuk egy wikibe írnám, ami sokkal hosszadalmasabb és macerásabb átszerkeszteni, ha meggondolnám magam.
Ami nem tetszik, hogyha van egy nagy rakás tesztem, de még nem implementáltam semmit, akkor alapból piros lesz így az egész. Ezzel két gond van. Az egyik, hogy nem lehet úgy BDD-t csinálni, ha nem látom, hogy zöldbe mennek a tesztek arra a feature-re, amit aktuálisan belefejlesztek. A másik, hogyha commit + push-t tolok a kódra, akkor nem túl jó, ha a githubon végig pirosban van a master, vagy igazából bármelyik branch. Legalábbis hallottam egy olyan alapelvről, hogy mindennek zöldnek kéne lennie, amit committálunk, vagy ha ez nem megy, akkor legalább annak, ami a masteren van. Mit ajánlotok erre az esetre? Kapásból nekem az jutott eszembe, hogy skippelni kellene a teszteket, amiket még nem fejlesztettem le, de macerás lehet karbantartani a skip listát. Nem tudom van e bármilyen más egyszerű megoldás rá, amit beilleszthetnék a munkafolyamatba, de érdekelne. Esetleg commentezzem ki őket?
■ Ami nem tetszik, hogyha van egy nagy rakás tesztem, de még nem implementáltam semmit, akkor alapból piros lesz így az egész. Ezzel két gond van. Az egyik, hogy nem lehet úgy BDD-t csinálni, ha nem látom, hogy zöldbe mennek a tesztek arra a feature-re, amit aktuálisan belefejlesztek. A másik, hogyha commit + push-t tolok a kódra, akkor nem túl jó, ha a githubon végig pirosban van a master, vagy igazából bármelyik branch. Legalábbis hallottam egy olyan alapelvről, hogy mindennek zöldnek kéne lennie, amit committálunk, vagy ha ez nem megy, akkor legalább annak, ami a masteren van. Mit ajánlotok erre az esetre? Kapásból nekem az jutott eszembe, hogy skippelni kellene a teszteket, amiket még nem fejlesztettem le, de macerás lehet karbantartani a skip listát. Nem tudom van e bármilyen más egyszerű megoldás rá, amit beilleszthetnék a munkafolyamatba, de érdekelne. Esetleg commentezzem ki őket?
Szerintem a sima skip jobb,
Ami külön jó, hogy be tudom illeszteni ezt az egészet a fejlesztési folyamatba. Tehát amikor még csak átgondolom, hogy mit kéne tudnia a könyvtárnak, amit írok, akkor máris el tudok kezdeni skippelt teszteket írni hozzá, amiken aztán később változtathatok, ahogy alakul az elképzelés. Szoktam issue-kat is létrehozni ilyesmihez, úgyhogy azokra lehet hivatkozni az ezzel kapcsolatos commit message-ekben. Teszek egy próbát vele, kíváncsi vagyok, hogy mire jutok. A mostani módszernél, hogy mindent teleírok, és a végén már meg se találom, hogy miről hol beszéltem, mindenképp jobb lesz ez a megoldás. Annyi hátránya van, hogy egy picivel lassabb, mint csak úgy átgondolni, mert karban kell tartani hozzá a teszteket, nem csak úgy odahányni valami félkész példakódot. Talán ez megfizethető ár, meglátjuk. Érdekes, hogy más a model felől közelíti meg a tervezést UML-el, én meg az API felől.
Több issue, kevesebb teszt
Ezt megelőzheti valamilyen funkcionális specifikáció, ami még inkább user / megrendelő szemmel írja le a feladatot, abból írom meg aránylag részletesen a lebontott issue-kat (értelmes emberi időn belül (~= 1-2 nap) végrehajtható 1-1 issue), ezekre már jobban lehet egyenként nehézséget / megoldási időt saccolni (és pl az alapján árazni).
Amíg ez nincs meg, addig szerintem felesleges tesztet írni (kódot végképp), mert eddig a pontig egész sokat változhat az elképzelés.
Így minden egyes commit kezdődhet egy issueId-val, és rajtad múlik, hogy mennyire akarod különválasztani a tesztet a fejlesztéstől (ha teljesen, akkor külön issue-k a tesztek és a kódok).
Emellett, ha bármilyen fejlesztés közbeni változtatás van, akkor pontosan meg van a helye, hogy melyik issue-ba kell beírni - és ezek az infók később is könnyen elérhetők.
Hab lehet még a tortára, hogy ha egy feature 2 issue-nál "többe kerül", akkor legyen egy EPIC "fölöttük", ami általános képet ad róla (User story, egyéb doksik linkjei), és a pull / merge request-re elég csak az epicet belinkelni (valamit mindenképp, hogy követhető legyen a dokumentáció és a kód fejlődése).
Igazából már a user story is