Új hozzászólás Aktív témák

• kress aktív tag

  #7

  #6 inf3rno

  2024-03-30 10:52:58

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  kress

  aktív tag

  #6 inf3rno

  #6 inf3rno

  Unit testingről már leszoktam. Ha nagy mozgások vannak a kódbázisban, akkor tarthatatlan, hogy állandóan újra kell írni a teszteket, egyébként is 2-3x annyi munka, mint simán lekódolni, aztán debuggolni. Nekem leginkább a BDD jött be és integrációs teszteket írok. Az is lefedi a nagyját, vagy legalább a gyakori eseteket. Most mondjuk Wordpress plugin készítést gyakorlok, ennél a gyakorlásnál csak manuálisan tesztelek, debuggolok, és így is jó. Régen még azt mondtam, hogy minden projekthez kellenek automatizált tesztek, most már nem vagyok annyira meggyőződve róla. Kis projekteknél szinte mindegy, ha az embernek van kellő tapasztalata, közepeseknél kezd kijönni a hátránya a tesztek hiányának, nagyokhoz látom értelmét. A közepeseknél is inkább úgy csinálom, hogy bizonyos részeket tesztelek, amik kritikusak pl. biztonság, vagy a domain modelt igen, de a prezentációt nem. Amivel még régebben szórakoztam azok az e2e tesztek. Azok se rosszak annyira, de jóval több idő és kényelmetlenebb írni és futtatni őket. Teszteléshez én ezt szerettem: [link], de már nagyon régen olvastam, és hát van vagy ezer jó könyv a témában. DI-ről nem olvastam még külön könyvet, azt esetleg megnézem, köszi!

  én nem webes területen mozgok és főként backenden, tesztelni én csak azt látom értelmét ahol a logika van, annak nem igen kéne sűrűn változnia, de amikor változik akkor jó hogy ha van teszt a régi elvárt működésre és látszik ha azon volt valami változás valahol, aminek nem kellett volna

  hogy aztán valaki tdd-ben írja-e az engem sosem mozgatott, az arra jobb hogy nem drótozol össze mindent midennel, mert akkor tényleg lehetetlen lesz külön tesztelni a lényegi részt és kitéped az összes hajad

  mostanában ilyen beolvas, mókol, kiir feladataim voltak, ahhoz e2e a legegyszerűbb, csak összehasonlítgatja a kimenetet különböző típusú bemenetkhez

  egy két parsolásos dolog volt amihez a unit teszt volt célszerűbb, mert ott látszott közelebbről mi hasal el bizonyos értékek esetén, ahhoz az e2e annyit mondott volna csak hogy baj van tesó pl.

  amit írtam tdd könyv nem csak tesztekről szól, az a jó benne, használható példák vannak benne a functional corera, a repository patternre stb., nem az a vért fröcsögő tdd könyv mint a többi

Új hozzászólás Aktív témák