Csak egy egyszerű feature-re van szükségünk

…szólt a kérés, de hamar kiderült, hogy valójában jól tovább-bontható az igény, és bár egyszerűen megfogalmazhatóak, a megvalósítás viszont korántsem egyértelmű. Főleg azért, mert egy több éves projeket kellett kiegészíteni, ami egy előző szemléletmód mentén készült.

Fejlesztőként gyakran kell feladat komplexitást, időigényt becsülnöd. Mit számolsz bele? A fejlesztési időt. És persze dokumentációt, tesztelést, javítást. Egyeztetéseket, vakvágányokból gyors iránybaállást, refaktorálást.

Megbecsültük, kitaláltuk hogyan futunk neki, nekifutottunk.
De ha refaktorálsz egy modult, hol húzod meg a határt? Mi az, amihez már semmiképpen nem nyúlsz?
Ha jól van szeletelve az alkalmazás, akkor csak elrontani lehet: kapsz pár contract-ot, amit tisztelsz, tesztelsz, mögötte megbütykölhetsz bármit.

Örültünk, hogy ha tesztek nem is, de egy használható API dokumentáció legalább rendelkezésre állt, amibe tudtunk kapaszkodni, amíg mozgott a kódbázis.
De ha azt látod, hogy a modulok határai elmosódnak, és egy egység megváltoztatása után olyan dolgok borulnak, amire nem számítottál, akkor biztos, hogy a Boy Scout Rule végtelen túrkálással és bugfixeléssel történő félreértelmezése a legrosszabb, amit tehetsz.

Ezekben az esetekben lépj egyet hátra, és nézd meg messzebbről a helyzetet. Régi kódbázisok esetén ha nem cél újrafejleszteni az egész rendszert, akkor elengedhetetlen, hogy stabilizáld a rendszer állapotát, hogy a következő verzió legalább rosszabb ne legyen, mint az előző.
Ezt legjobban a hiányzó tesztek pótlásával tudod megtenni, amit ideiglenesen talán kiválthatsz kézi teszteléssel („arra mindig kell legyen idő”), de egy kis tanulással az e2e tesztek java automatizálható.
És ez olyan, mint a konditerembe járás: senki nem mondta még, hogy megbánta, hogy edzett egy jót. És az is igaz talán mindkét esetben, hogy nem lehet elég korán elkezdeni.

A szóban forgó projekt esetében pont így jártunk, hetekkel később született meg a funkciókat és felületeket 85%-ban lefedő automata teszt, mint célszerű lett volna, és milyen jó lett volna már az elején…
Test frameworkök és toolkitek jönnek-mennek, de ha keresel, lesz miből választanod a te rendszeredhez is.
Mivel nekünk a frontend keveset változott, az API stabilitását a frontendre futtatott cypress.io tesztekkel tudtuk jól és egyszerűen mérni, és végül több napnyi időt spóroltunk még úgy is, hogy későn hoztuk meg a döntést a tesztekről.

Legacy projektek esetében az egyik legjobb időbefektetés már a projekt feltérképezése közben olyan eredményeket gyűjteni, amit később regressziós teszteléshez felhasználhatsz – egyik kedvencem: a karakterizációs tesztek - hogy később ki tudd magad vágni azokból a helyzetekből, amikor felvetődik a kérdés:
„ez korábban sem működött?”