Hirdetés
- Olyan lesz a Térkép, mint a segítőkész haver az anyósülésen
- Alaposan kitolhatod az Steam Deck üzemidejét egy új funkcióval
- Lassú lett a PC? Micsoda meglepetés: egy Windows frissítés lehet a ludas
- PlayStation 5 nélkül kínál PlayStation 5 játékokat a Sony
- Bekrepáltak a régebbi Forzák az NVIDIA új drivereivel
- Melyik a legerősebb Low Profile VGA kártya?
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Milyen RAM-ot vegyek?
- Házimozi belépő szinten
- Alaposan kitolhatod az Steam Deck üzemidejét egy új funkcióval
- Ezek a gaming monitorok az AOC jó ajánlatai közé tartoznak
- Lassú lett a PC? Micsoda meglepetés: egy Windows frissítés lehet a ludas
- Projektor topic
- Gaming notebook topik
- Minőségi ugrást hozhat a One új médiaboxa?
Új hozzászólás Aktív témák
-
Drizzt
nagyúr
válasz
btraven
#11879
üzenetére
[Például]
De egyébként A hello world egy unit tesztelhetőség szempontjából pont eléggé faramuci dolog, mert ott a függvényedet le kellene választani a környezetéről. Ha nem a környezetéről leválasztva tesztelsz valamit, akkor az az én szememben már inkább integration teszt.
Egy olyan függvényt, ami a standard outputra kiírja, hogy Hello world, nem lehet jól unit testelni, mert a standard outputot kell mockolni, ami meg csak ilyen nyakatekert módokon oldható meg.
Ha viszont olyan függvényed lenne, ami visszaadja, hogy: "Hello world" -> remekül unit tesztelhető. Olyan, ami kap egy outputstream-et input-ként és kiírja rá, hogy "Hello world" -> szintén remekül unit testelhető.
"Ritka volt az, amikor nem változott hétről hétre a követelmény, és nagyon kevés része volt a kódnak az, amiben unit tesztre érdemes dolgok történtek."
Ez utóbbi mindig nagyon gyanús. Én is mindig azt hiszem, ogy jó, triviális kódokat írok, aztán amikor elkezdem tesztelni, szinte mindig kijön valami turpisság. Nyilván a tesztelés mehet három módon: kézzel pöcögtetve: valószínűleg jó kódot eredményez, de ha legközelebb aki hozzányúl, nem olyan alapos, mint aki írta és kézzel tesztelte, akkor rögtön veszélyes lesz módosítani a kódot. 2.: vagy azonnal automata tesztet írni, vagy az előző pont kézi eseteit automatizálni. Ez elég jó általában. 3.: előre írni meg a tesztet és csak utána a kódot. Pont az a nagy előnye, ami miatt elsőre nagyon nehéz vele dolgozni: végig kell előre gondolni az elvárt viselkedést és a trükkös eseteket is. Erre gyakran használt kifogás, hogy sokat változik az elvárás, azért nem kezdenek vele. De nem teljesen korrekt érv, hiszen anélkül, hogy tudná mit akar csinálni az ember, el sem tud mit kezdeni programozni.
Én tényleg csak alkalomszerűen TDD-zek, de örülnék, ha valamikor elkezdenénk végignyomni vele teljes projekteket, mert minőségben ég és föld a különbség. Ha előre írsz tesztet, akkor sokkal jobban át tudod gondolni, hogy milyen osztályoknak, milyen interface-eken keresztül kell tudniuk egymással beszélni. Sokkal könnyebb elkerülni a spagetti kódokat.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- BESZÁMÍTÁS! Lenovo Legion Go S 32GB/1TB kézikonzol garanciával hibátlan működéssel
- Apple iPhone 12 Mini 64GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 13 mini 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3060, 100% Akkumulátor
- Xiaomi Smart Band 8, Újszerű, 1 Év Garanciával
- Bomba ár! Lenovo ThinkPad T14s G2 AL - i7-1185G7 I 16GB I 1TSSD I 14" FHD Touch I W11 I Cam I Gari!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest


