![Dekoráljuk ki a [DynamicData] attribútumot!](https://csharptutorial.hu/wp-content/uploads/2026/03/decoating_testing.webp "Dekoráljuk ki a [DynamicData] attribútumot!")
Az MSTest az egyetlen .NET-alapú tesztkeretrendszer, amely natív támogatást nyújt a dinamikus adattesztek egyedi tesztneveinek előállításához a DynamicDataAttribute segítségével. Bár ez a lehetőség hasznos, a megvalósítása korántsem felhasználóbarát: kódismétlést eredményez, és felesleges vizuális zajt visz a tesztosztályokba.
A .NET teszt-keretrendszerei sok mindenben hasonlítanak, de a kivételtesztelés terén gyakran egészen mást értenek ugyanazon Assert-metódus alatt. Ami az egyik futtatóban „példány-ellenőrzés”, az a másikban „pontos típus-egyezés”. Van, ahol könnyű kivételt rögzíteni, máshol hiányzik a megfelelő API…
Boldog új évet mindenkinek! A C# Tutorial története a 2025-ös évben folytatódik, méghozzá egy új C könyvvel. Igen jól olvastad, C könyvvel. Természetesen felmerül a kérdés, hogy miért?
Az MSTest mostanában nem menő, pedig a Microsoft aktívan fejleszti. Ennek ellenére ne gondoljuk azt, hogy nincsenek jól átgondolt, speciális hátrányai. Ami hiányzik belól, azt pótoljuk magunknak és persze logoljuk…
Paraméteres metódusok unit-teszteléséhez a legtöbb esetben egynél több teszt-metódust kell készíteni. Alapesetben írunk minden teszt-esethez egy-egy teszt-metódust. De vajon van-e lehetőség egyszerűsítésre, és ha igen, az mennyire bonyolult? Na és főleg: Megéri-e egyáltalán? (Spoiler: meg.)
Az előző cikkben eljutottunk oda, hogy megkreáltuk a chain of responsibility implementációhoz az ősosztályunkat. Ezek után már „csak” az egyes lépések lekódolása maradt hátra.
Az előző részben a preset betöltésnél és validálásnál hagytuk abba a program készítését. Ebben a részben az alap architektúra kialakításával folytatjuk, de előtte a preset témánál maradva komponenseket készítünk a felhasználói bemenet validálására és konvertálására.
Az előző részben beállítottuk a GIT tárolónkat és a CI/CD pipeline környezetet. Ebben a cikkben belevágunk a problémakör megoldásának megvalósításába, a preset modellezésbe.
Az előző részben megismerkedtünk a problémakörrel. Ebben a cikkben specifikáljuk a programot, írunk egy kis kódot és beállítjuk a CI/CD környezetünket.
Az FFmpeg egy remek, igen nagy tudású program, de finoman fogalmazva is megválogatja a barátait, ha a felhasználói élményről van szó. Ezért gondoltam, készítek hozzá egy n+1. frontend implementációt.
Az előző cikkben a BookGen keletkezésének körülményeit és az architektúráját ismertettem nagy vonalakban. A mai cikkben viszont a felhasználói oldalról közelíteném meg.
A könyv történetéhez hozzátartozik az eszköz is, amivel létrehoztuk. Korábban nem beszéltem róla, de a könyv és az oldal tartalmának szerkesztéséhez írtam egy saját eszközt, ami a BookGen nevet kapta. Ebben a cikkben erről szeretnék mesélni.
Papíron bármilyen hanganyag lejátszása egyszerű: be kell tölteni a fájlt és meg kell szólaltatni a hangkártyán. Azonban az ördög itt is a részletekben rejlik…
Ahogy a cikksorozat bevezetőjében említettem, az alkalmazásunk WPF-et fog használni. Meghazudtolnám magam, ha nem másznék egy kicsit is bele, hogy mi is ez a WPF? A cikkből remélhetőleg kiderül 🙂
Az elkészülő zenelejátszó programért nem szeretnék pénzt kérni, valamint azt szeretném, hogy szabadon használható és módosítható legyen. Ez a definíció hétköznapi nyelven érthető, de a jog sajna nem ennyire egyszerű. Éppen ezért, mielőtt belevágunk a fejlesztésbe, egy picit foglalkoznunk kell szoftverjogi kérdésekkel.
Az „Alkalmazásfejlesztés élesben” rovat létrehozásakor az volt a célom, hogy olyan kódrészletek, alkalmazások készüljenek el szemléltetve a C# nyelv képességeit, amik nem állatorvosi lovak és valami hasznosat is végeznek. Azonban itt az idő, hogy szintet lépjünk és egy komplexebb alkalmazást készítsünk.
A programunk működését jelen szoftver esetén egység- és rendszer szinten fogjuk tesztelni. Integrációs tesztszintnek jelen program esetén önmagában nincs értelme a komponensek egyszer használtsága és kis száma miatt. A rendszerszintű tesztelés manuális tesztelést fog jelenteni. Unit teszt futtatásra a Visual Studio tartalmaz egy teszt futtató környezetet, de teszt íráshoz nem tartalmaz ilyet. Ennek oka az, […]
Az előző részben elkészült a programunk, így már „csak” tesztelni kell és a felmerülő hibákat javítani. De előtte teszünk egy kis kitérőt.
Az előző részben elkészítettük a konfiguráció betöltéséért és validációért felelős komponensünket, ideje befejeznünk a programot.
Az előző részben átbeszéltük a program követelményeit, így a sorozat mai részében elkészítjük a konfigurációs fájl beolvasó részt és a program vázát.