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.

A Spring Boot 3.3 verzióban tovább egyszerűsítették az OAuth 2.0 integrációt. Az előző verziók esetén, amennyiben a JWT tokenben a felhasználónév nem a sub claim alatt szerepelt, saját magunk kellett ezt kiolvasni, pl. egy saját JwtDecoder bean megadásával. Amennyiben a JWT token tartalmazta a szerepköröket is, saját JwtAuthenticationConverter beant kellett felvennünk, mely képes volt a szerepkörök kiolvasására.

Erre a Spring Boot 3.3 verziótól kezdve nincs szükség, hiszen beállíthatjuk ezt az application.properties állományban, és a Spring Boot automatikusan konfigurál egy JwtAuthenticationConverter (vagy reaktív esetben egy ReactiveJwtAuthenticationConverter beant).

Ezt is említettem a XV. Pécs IT Meetupon. A meghívást ezennel is köszönöm a Kovács Bálintnak, a meetup egyik szervezőjének, aki többedmagával a Webstar céget is képviselte.