A gyors visszajelzés tényleg annyira megéri, amennyire az iparban hirdetik?

Sziasztok! Junior vagyok, szóval teljesen elfogadom, ha az én megfigyeléseim rosszak, mert lehetséges, hogy nem látom a teljes képet, vagy nem találkoztam még azokkal a problémákkal, amit a teszt piramis és a gyors visszajelzések CI/CD hatékonyan kiküszöböl.

Szerintem nagyon fontos unit teszteket írni. Egyrészt mert rákényszerít kódolási elvekre (SOLID, Clean Code) és általa jobban megértheted a kódodat. A későbbi refaktoráláskor garanciát ad, hogy nem változtatod meg az osztályod viselkedését.

Nagyon fontos integrációs és UI tesztet írni. Azért, mert az unit tesztek nem képesek lefedni az egész szoftvert és a user kezében az egész rendszer interakcióban fog működni, így fontosak ezek az átfogó tesztek, amit a unit és komponens tesztek nem kapnak el, azokat képesek detektálni.

A munkahelyemen egyre fontosabbnak tartják a "fast feedback" témát. Egy pipeline minden egyes változtatás után lefuttat unit és komponens teszteket és elkapja a build és a teszt hibákat egyaránt. A full build éjszaka megy és másnap reggel elérhetőek az integrált és UI tesztek eredményei is.

Számomra a pipeline csak egy dolog miatt hasznos, mert elkapja a build hibát. Az alap, hogy magamnál lefuttatom a unit és komponens teszteket mielőtt beteszem a kódomat, így még soha nem volt, hogy a pipeline bejelezzen nekem teszthiba miatt. De kétségtelen, hogy egyes kollégáknak ez gondot jelent.

Na és akkor itt jönne a kérdésem: tényleg megéri az, hogy ennyi energiát fordítunk arra, hogy azonnali visszajelzést kapjunk? Mi van akkor, ha másnap reggel látom a teszt eredményeket, 12-24 óra ekkora kiesést generál? A tapasztalataim szerint eddig nem sok értékkel bírt, hogy nem aznap kaptam eredményt. Ugye ezzel párhuzamosan erősödödik a kultúra, hogy szorítsuk le a tesztjeinket unit és komponens szintre, merthogy "olcsó" és pár másodperc alatt jelez, és a pipeline futtaja. De másik oldalon a leghosszabb időt nálunk a komponens tesztek írása veszi el. Még az atyaúristent is ki kell mokkoljam, mert nem csak két osztály interakciójáról beszélek itt, hanem mikor bereerőltetünk egy nagyobb workflowot komponens szintre (amit én csípőből integrált szintre ítélnék) és másokkal, ne adj' isten legacy osztályokkal is meg kell verekedjek, mire összehozom az Arrange részt. Egyáltalán felfogni, hogy mások által írt osztály hogyan működik az már eszi az időt.

Integrációs szintén viszont van egy frameworkunk amivel gyönyörű, letisztult, olvasható teszteket lehet írni. Nem kell belenézzek mások osztályaiba, csak az API-t használom. Ha kell valami új, akkor könnyen tudok fejleszteni a frameworkbe, de az évek alatt ez már kiforrott és erre csak párszor került sor. A komponens teszt ezzel szemben sokkal olvashatatlabb, bármennyire is próbálom betartani a Clean Code elveket (a sok mokkolás miatt).

Arról nem is beszélve, hogy a komponens tesztek feltételeznek bizonyos dolgokat, mondjuk hogy az X osztály Y interfacű fieldje mögött Z implementació van, de mi van ha egyszer azt valaki kicseréli a valós kódban? Akkor azt a tesztben is ki kell cserélni, de valakinek eszébe fog jutni, hogy ott is karban kell tartani? Mert az interface el fogja nyelni a cserét.

A tapasztalataim szerint az integrációs tesztek fognak meg igazán dolgokat. Ha én lennék egy szoftver tulajdonosa, én nem bíznék egy olyan minőségbiztosítási stratégiában, ahol erőszakosan tolnak le integrációs szintű dolgokat a teszt piramis alacsonyabb részeire, csak mert délután kell visszajelzést kapni másnap reggel helyett.

Én ezek alapján azt látom, hogy az olcsóbbik és biztonságosabb megoldás hosszútávon mégis egy olyan állapot, ahol lassú lefutású, átfogó tesztek is vannak a legtöbb scenariora.

Mit gondoltok? Minden szakmai véleményt szívesen fogadok, lehet, hogy én látom rosszul a dolgokat.