ugrás a tartalomhoz

Mi a best practice verziózásnál arra, ha az összes tesztet írom meg először?

inf · 2019. Jún. 2. (V), 21.24
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?
 
1

Szerintem a sima skip jobb,

inf · 2019. Jún. 3. (H), 02.49
Szerintem a sima skip jobb, mint a commentezés. Nem sok infot találni róla, ahogy nézem, de ahol írják, ott így csinálják feltéve, hogy a teszt keretrendszer támogatja a skipet. Szerintem én is maradok ennél és inkább skippelem és committálom az olyan teszteket is ezentúl, amihez még nem írtam kódot, ahelyett, hogy külön kigyűjteném valahova, és onnan másolnám be, amikor elkezdem megvalósítani az adott feature-t.

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.
2

Több issue, kevesebb teszt

Pepita · 2019. Jún. 3. (H), 09.32
Szoktam issue-kat is létrehozni ilyesmihez, úgyhogy azokra lehet hivatkozni az ezzel kapcsolatos commit message-ekben.
Szerintem ez tök jó, azzal a különbséggel, hogy szerintem a teljes feature-nek / csomagnak először issue-kban a helye.
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).
3

Igazából már a user story is

inf · 2019. Jún. 6. (Cs), 13.52
Igazából már a user story is mehet issue-ba, aztán onnan lehet tovább dolgozni rajta. Igy nyomon követhető, hogy ki min dolgozott, és könnyebben is folytatható. Nyilván a tesztek előtt kell legalább valami naiv alapelgondolás, hogy mit akarunk, és az nagyjából hogyan megvalósítható, de szerintem érdemes lehet minél előbb betenni néhány tesztet, ha ez már megvan, és utána alakítgatni őket attól függően, hogy hogyan változik a model, derülnek ki újabb részletek, stb. Ha más elgondolás alapján csinálod, akkor is kell legalább valami UML diagram, vagy magának a modelnek a kódja, vagy bármi, ami központi és tömör információ forrás, különben a vége az lesz, hogy újra el kell olvasni az összes issuet, mert egy kicsit is bonyolult projektnél már nehéz fejben tartani a részleteket, főleg ha több mindenen dolgozik az ember. Nekem elég gyakori, hogy pár hónap után visszatérek valamelyik hobbi projekthez, és már azt se tudom eszik vagy isszák.