- Milyen okostelefont vegyek?
- Samsung Galaxy A54 - türelemjáték
- Ilyen lesz a Fairphone 6
- 45 wattos vezeték nélküli töltés jön az új iPhone-ba
- Motorola Edge 40 - jó bőr
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Magyarországon is kapható a Moto G85 5G
- Karaktere biztos lesz az első Nothing fejhallgatónak
- Netfone
- Motorola Edge 50 Neo - az egyensúly gyengesége
Új hozzászólás Aktív témák
-
kress
aktív tag
é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
-
inf3rno
nagyúr
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!
-
kress
aktív tag
kisebb projekteknél inkább csak jól elbonyolítani lehet vele a dolgokat szerintem
amit írsz az inkább a karbantarhatóság felé hajaz, loose coupling, dependency injectionddd blogban nekem ez tetszett [link], van egy unit tesztes könyvve is, hasonló alapokon
dependency injectionhoz meg ez könyv hasznos szerintem [link] -
inf3rno
nagyúr
Én próbálgatom már egy ideje, és bár sokan mondják, hogy kis projekteknél és egyedül nincs értelme, én eddig totálisan az ellenkezőjéről győződtem meg. A kiindulási naív állapothoz képest egy csomót szokott fejlődni a modellem miközben agyalok rajta még a külsőre legegyszerűbbnek tűnő projekteknél is. Aztán persze az is igaz, hogy messze nem vagyok profi benne, és elsőre nem sikerül a legjobbat alkotni... Ami szintén tetszik, hogy mivel lazán csatolt a kód a megjelenítéshez, ezért nem okoz gondot később mondjuk egy mobil alkalmazást betenni a weblap mellé. De még gondolom van ezer dolog, ami tetszik benne, ezért ragadtam le valami DDD-re emlékeztető dolognál. Azt aláírom, hogy nem nagybetűs DDD, amit csinálok, inkább csak ddd.
Esetleg mesélhetnél arról, hogy te mikor és hogyan alkalmazod, már ha van kedved!
-
inf3rno
nagyúr
Egyelőre erősen küzdök az aggregatek helyes megválasztásával.
Ezek a guideline-ok:
1.) keep aggregate simple -> contain only members which are bound together by common business rules
2.) address aggregate through aggregate root -> ensure that all business rules are met
3.) never nest aggregates -> only id for reference reasonsEz mind szép és jó, csak a mostani projektemben elég kevés az adat manipuláció. Inkább csak arról szól, hogy felviszek egy rakás adatot, aztán utána PDF fájlt generálók belőlük.
-
inf3rno
nagyúr
Sziasztok!
Azért nyitottam ezt a topikot, hogy a DDD-ről társalogjunk. Magyar nyelven nagyon kevés info érhető el erről a módszertanról.
Új hozzászólás Aktív témák
Hirdetés
- Xbox Series X|S
- Mr. Y: Motoros sztorik #06
- Milyen okostelefont vegyek?
- Okos Otthon / Smart Home
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- EA Sports WRC '23
- Milyen processzort vegyek?
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Argos: Szeretem az ecetfát
- Debrecen és környéke adok-veszek-beszélgetek
- További aktív témák...
- Asus VivoBook S15 S513 OLED (S513EA-L12917) Fekete - Garancia 2026.06.22.
- DDR5 GAMER PC: Új RYZEN 7 8700F/9700X/9800X3D +RTX 4060/5060/4070/5070 +16-64GB DDR5! GAR/SZÁMLA!
- Dell Latitude 7410 Strapabíró Ütésálló Profi Ultrabook 14" -80% i7-10610U 16/512 FHD
- Szép! HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 32/512 Iris Xe FHD Magyar
- HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 8/512 Iris Xe FHD Magyar
- Beszámítás! Apple Mac Studio M2 MAX 2023 32GB 512GB SSD számítógép garanciával, hibátlan működéssel
- Bomba ár! Toshiba Satellite Pro R50-C - i3-6G I 4GB I 128GB SSD I 15,6" I HDMI I Cam I W10 I Gari!
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! ASUS B450 R7 2700X 16GB DDR4 512GB SSD RTX 2060 Super 8GB Zalman i3 FSP 600W
- Wacom Cintiq DTK-2260 - Digitális rajztábla
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest