Honnan is kezdjem? Talán onnan, amivel sokszor egy lapon említik: viszonylag ismert fogalom a TDD, magyarul talán tesztek által vezérelt fejlesztési megközelítésnek mondanám. Azt jelenti, hogy egy új funkció -vagy felmerülő hiba kijavítása- esetén először megírjuk a teszteket. Ezek lesznek a teljesítendő követelmények. Majd a tesztek alapján következik az “igazi” fejlesztőmunka: addig igazítjuk a kódunkat, amíg a tesztek hiba nélkül lefutnak.

Előnyök? A fejlesztésünk eredménye pontosan teljesíti a követelményeket. A későbbiekben pedig már “nem tudjuk” észrevétlenül elrontani, ugyanis, ha baj van, és a teszteket futtatjuk, azonnal kiderül. Így bátrabban mehet a módosítás vagy a refactoring, és a végeredmény is garantáltabban ad jobb minőséget.

A kihívás ebben a jó tesztek meghatározása és megírása, tesztelhető megoldás készítése valamint a változásokkal párhuzamosan a tesztek naprakészen tartása.

Ez konyhanyelven a TDD leírása.

A BDD megközelítésről már kevesebben hallottunk.

Fontos megjegyezni, hogy bár a BDD és a TDD kifejezések eléggé hasonlatosnak tűnnek (mindegyiknek a vége DD, azaz driven development) nem ikertestvérek, sőt. Legalább annyi különbség van a kettő között, mint amennyire hasonló a két fogalom.

A BDD -szintén konyhanyelven- arról szól, hogy az elkészítendő feladat viselkedési mintáit rögzítjük, mint teljesítendő követelményeket. Majd a TDD-hez hasonlóan (ezért * driven development ugye) ezekből a mintákból valahogy megoldást fejlesztünk, amiknek ezeket a rögzített viselkedési mintákat ellenőrizhető módon teljesítenie kell.

A csavar ott van a dologban, hogy a viselkedési mintákat jellemzőkbe (feature) csoportosítjuk, majd ezekhez a jellemzőkhöz forgatókönyveket (scenario) írunk. Végül ezekből a forgatókönyvekből aztán tesztek lesznek, amit már hagyományos fejlesztői eszközökkel írunk meg.

De. És ez a legnagyobb de. Nem valamilyen programnyelven írjuk a forgatókönyveket és a jellemzőket, hanem ezek egy üzleti felhasználó által is megérthető (un. Business Readable Domain Specific Language - BR.DSL) nyelven készülnek.

Vagyis duplagondol-duplacsavar-duplafenék, és így leírva elég macerásnak is tűnik, viszont ez nem feltétlenül igaz. Ha jó eszközünk van, akkor kézbentartható a feladat, és ölünkbe hullik tengernyi előny.

Ezért is írtam ezt a pár sort.

De leginkább azért, mert szerintem nem kap elég figyelmet, hogy magyar fejlesztőé a BDD egyik autentikus és a világban széles körben elterjedt C#/dotnet/dotnetcore alapú megoldása, a SpecFlow. Nyílt forráskódú, sokféle tesztelési környezetet támogat, a bdd fejlesztők legelterjedtebb eszközének (cucumber) a (gherkin) BR.DSL nyelvét használja. Vagyis mondhatni, a világban már kialakult és kiválóan használható művészetet terjeszti ki a dotnet fejlesztők számára is elérhetővé.

És azért tiszta forrásból, mert február 21-én a szerző ingyenes webinar-t tart a BDD-ről, érdemes részt venni rajta.