A NETAcademia (, mely mögött a Training360 áll) NETA.live néven egy új, ingyenes előadássorozattal jelentkezik.

Az első online webináron 2025. október 29-én 18:00-kor a Spring AI-ról fogok előadást tartani. Nem a hype-ot akarom tovább duzzasztani, hanem élő kódolás közben bemutatni a Spring AI lehetőségeit, azaz hogyan lehet LLM-hez kapcsolódni, RAG technikát alkalmazni, vagy egy MCP szervert fejleszteni, amit aztán agentek tudnak felhasználni.

Az esemény alapvetően olyan Java fejlesztőknek szól, akik szeretnének megismerkedni a Spring AI képességeivel.

Regisztrálj az esemény oldalán, és kapcsolódj be te is a YouTube élő közvetítésbe, ahol kérdéseket is feltehetsz! Ha nem érsz rá, de regisztrálsz, akkor később is visszanézheted a felvételt.

Bevezetés

A Behavior-Driven Development (röviden BDD) már egy 2000-es évek elejétől létező módszer. Még a mai napig is sokan használják, sőt vezetik be létező vagy új projekteken.

Sajnos azonban azt vettem észre, hogy sokan félreértik és hibásan használják. Az Interneten is rengeteg rossz példa terjed, sőt a különböző nagy nyelvi modellek is hibás megoldásokat hoznak (nyilván az előbbi példák alapján), ezekből is fogok többet is mutatni. Ezzel azonban nem segíti, hanem inkább hátráltatja a projekt előrehaladását.

Ebben a posztomban megpróbálom összegyűjteni, hogy hol lehet elrontani a BDD használatát, valamint milyen rossz gyakorlatokat látok a mai napig. Saját tapasztalatokat és erősen szubjektív elemeket is tartalmaz. Ez a korábbi Fejlesztőként mivel akadályozom a tesztelők munkáját? írásom folytatásaként is felfogható.

Röviden a BDD-ről

Nem célom a BDD részletes kifejtése, csak amennyi feltétlenül szükséges a megértéshez. Hivatalos definíció hiányában a kialakulásának céljait érdemes megérteni. Ez olyan módszer, megközelítés, melynek célja hogy a szoftver elvárt viselkedését példákon keresztül mindenki számára érthető, természetes nyelvi formában fogalmazza meg. Gyakran emlegetik a Three Amigos (magyarul: Három Barát) kulcsszereplőket is, ami arra utal, hogy az üzleti szereplők, fejlesztők és tesztelők közösen dolgoznak annak érdekében, hogy mindenki ugyanazt értse “kész alatt”. (Utalva itt az elfogadási kritériumokra - angolul: acceptance criteria.) Általánosan elterjedt még a Given-When-Then használata, mely szavak segítségével struktúrálni tudjuk az üzleti követelmények leírását. Elterjed eszköz a polyglott, azaz több programozási nyelven is használható Cucumber eszköz, valamint a nagyon egyszerű Gherkin nyelv.

Cucumber esetén a követelményeket ún. feature fájlban lehet leírni, mely forgatókönyveket, példákat (scenario) tartalmaz. Ezek lépésekből (step) állnak, az előbb említett Given-When-Then struktúrában. A természetes nyelven megfogalmazott lépést implementálni kell valamilyen programozási nyelven, ez az ún. step definition.

Bevezetés

A JPA, új nevén Jakarta Persistence egy szabvány, mely relációs adatbázisok elérését teszi lehetővő, object-relational mapping (ORM) használatával. Ennek különböző implementációi vannak, talán a legelterjedtebb a Hibernate. A Jakarta Persistence-re épül a Spring Data JPA, ami a repository mintát valósítja meg, valamint újabb lehetőségeket is az a JPA-hoz.

A JPA azonban nem fejlődik olyan dinamikusan, valamint több megszorítás, illetve kényelmetlenség is van benne.

Kényelmetlen a Criteria API használata, valamint korlátozott a DTO-k kezelése. Valamint nem támogat olyan hatékony SQL megoldásokat, mint a Window Functions vagy a Common Table Expression (CTE).

Ezeken egyrészt próbál segíteni a konkrét implementáció, mint pl. a Hibernate. (Ekkor persze elszakadunk a szabványtól.) Valamint a Spring Data JPA-val is több problémát próbál orvosolni. Vagy választhatjuk a mindkét előbbi technológiához jól illeszkedő Blaze-Persistence-t is kiegészítésül, mely további lehetőségeket rejt.

A példa alkalmazás forráskódja megtalálható a GitHubon.

Következő videóm témája, hogy egy modularizált alkalmazás felépítésekor az eseménykezelés segít nekünk abban, hogy a modulok lazán kapcsolódjanak egymáshoz. A Spring Modulith ezt kiegészíti, biztosabbá teszi a hiba- és tranzakciókezelést, valamint képes ezeket az eseményeket más service-ek felé is elküldeni valamilyen message brokeren keresztül.

Lesz szó modularizált alkalmazásról, eseménykezelésről, Spring Modulithról, tranzakciókezelésről, Testcontainersről, Kafkáról.

A példa alkalmazás forráskódja megtalálható a GitHubon.

A Spring Modulit modulkezeléséről írtam korábban egy posztot Modularizált alkalmazás fejlesztése a Spring Modulith-tal címmel.

A poszt végén a videóhoz képest extra tartalom is van.

Megjelent az első videóm, melynek témája, hogy hogyan lehet használni a Testcontainers-t Spring Boot alkalmazásban.

A videóhoz a forráskód is elérhető a GitHubon.

Ha valaki mégis a szöveges tartalomhoz ragaszkodik, olvasson tovább.