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.
válasza:Mikor eljöttem a korábbi cégemtől viccből kiszámoltam nekik, hogy amiért sz.rrágók voltak, és gyengébb laptopot vettek, mint amit igényeltem, évi 1500 eurót buktak csak azzal, hogy én néztem a képernyőt és vártam, hogy a gép kész legyen. Szóval igen, az idő elég drága.
Az mondjuk megint jó téma, hogy te mint dev mit keresel komponens tesztek körül, kérdezve: ki fogja ezeket karbantartani? Normál esetben vannak egy cégnél tesztelők erre, ami nálatol megy nagyon nem normális ezek szerint.
válasza:"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."
Írok egy tesztet egy kódra, elvárom a kódtól, hogy adja vissza ezt és ezt, hívja meg ezt és ezt. Jön 2 hét múlva egy igény, átírom miatta a kódot, majd utána írom a teszteket. Teljesen komolyan kérdezem amit most kérdezni fogok: kérlek érvekkel magyarázd el azt, hogy ennek mi a fasz értelme van, azon kívül, hogy jót tesz a szemnek a sok zöld sor. Ha valahol nem megfelelő típusú a visszatérési érték, ha valami nem megfelelően jön vissza, vagy történik, az már fejlesztés közben kieesik. Ha mindenki betartaná a játékszabályokat, nem használnának any-t és mindennek lenne egy alakja akkor - szerintem - teljesen felesleges a sok hülye tesztet megírni, hiszen több időt vesz igénybe mint maga a fejlesztés.. később meg konkrétan kitörlöd, és átírod, hogy a pirosból zöld legyen. És nem, soha nem volt még olyan, hogy megírtam valamit valahol, és teljesen máshol tönkretett volna valamit. Nem történt ilyen, mivel átgondoltam, hogy mit csinálok.
válasza:Az igaz, hogy a unit tesztek írása rengeteg időt elszív és a karbantartásuk is erőforrás igényes, de én akkor szeretem őket használni, mikor:
1: refaktorálok, ekkor egyből jelez, ha valamit kihagyok
2: nagyon sok féle inputom van, amit UI-on nagyon hosszú vagy körülményes lenne végigkattingatnom
3: nagyon sok inputom van és vannak olyanok, amikről fogalmam sincs hogyan tudnám előidézni UI-on
4: viszonylag gyakrabban előfordul, hogy egyes ellentmondásokra/nem optimális megoldásokra unit teszt íráskor jövök rá
válasza:Nem olvastam el az HSZ-eket, csak a kérdést.
Valóban a tesztek sok időt elszívnak. Bár azért nem haszontalan. Egyrészt a triviális metódusokra valóban nem sok értelme van, ami 1+1 matematikai triviális dolgot csinál.
De most képzeld el, hogy vagy egy 200 fős fejlesztő cégnél, és BÁRKI belenyúlhat a kódba, mert valamely random ügyfél olyan fejlesztést kér, mert szerinte bug (nem az). Majd neki áll belefejleszteni a kolléga, és ha nincs alapvetően teszt, akkor ugye nincs mi eltörjőn. Tehát kimegy és az ügyfél boldog, majd jön az előző, hogy tegnapig jó volt. Mi változott? Aztán a 3. fejlesztő is ránéz, és megint a másiknak tesz keresztbe.
Ha van teszt, akkor ha valami mást is végre hajt, arra plusz teszt kell arra az esetre és kvázi bővítésnek szabad történnie. Így win-win mind a két ügyfél részéről.
Az egy teljesen másik kérdés, ha komplett feature kerül újra tervezésre. Így nyilván újra kell húzni az összes tesztet.
válasza: válasza:5
1 - nem arra jelez, ha valamit kihagysz. Arra jelez, ha valamire nem ugyan azokat a visszatérési értékeket dobja, nem olyan sorrendben, és nem pontosan annyi hívást csinál, amennyi a tesztben le van írva. Ha a teszt jól van megírva akkor ok (ez a ritkább)
2 - ez két külön dolog. Fejlesztés közben tisztán, egyértelműen kell lennie egy helynek, ahol az egész validáció érthetően, szépen átláthatóan megjelenik, és a szabályok egymás alatt össze vannak foglalva
3 - ezek miért nem férnek el az edge case tömbben a validálásnál?
4 - ez jogos. De ezáltal elismered, hogy kevés időt fordítottál a tervezésre, és ne megfelelően csináltál meg valamit, mivel a unit tesztelésnél visszafelé vagy kénytelen gondolkodni. Tehát nem a teszt hasznos, hanem a gondolkodásmód amit kivált.
válasza:"Majd neki áll belefejleszteni a kolléga, és ha nincs alapvetően teszt, akkor ugye nincs mi eltörjőn"
Elmondom ez hogy működik: megjön a vad igény, Béla leül, lefejleszti, eltörik 25 teszt, majd a 25 tesztet szépen a kódja után írja, hiszen "teszteket kell írni". Minden zöld újra. Ennek mi értelme? Revertelni lehet tesztírás nélkül is.
Fontosnak tartom megjegyezni, hogy a frontendes js unittesztekre gondolok jelenleg.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!