A viselkedésvezérelt fejlesztés (behavior-driven development, BDD) egy agilis szoftverfejlesztési folyamat, amely ösztönzi az együttműködést a fejlesztők, a QA és a nem műszaki vagy üzleti résztvevők között egy szoftverkészítő projektben. Arra ösztönzi a csapatokat, hogy beszélgetéssel és konkrét példákkal hivatalossá tegyék az alkalmazás működésének közös megértését. A tesztvezérelt fejlesztésből (TDD) alakult ki. A viselkedésvezérelt fejlesztés ötvözi a TDD általános technikáit és elveit a tartományvezérelt tervezés és objektumorientált elemzés és tervezés ötleteivel, hogy a szoftverfejlesztő és -kezelő csapatok számára megosztott eszközöket és közös folyamatot biztosítson a szoftverfejlesztésben való együttműködéshez.
Bár a BDD elsősorban egy ötlet arról, hogy hogyan kell kezelni a szoftverfejlesztésben mind az üzleti érdekeket, mind a műszaki betekintést, a gyakorlatban a BDD nem vállalja, hogy a speciális szoftvereszközök támogassák a fejlesztési folyamatot. Bár ezeket az eszközöket gyakran kifejezetten a BDD-projektekben való használatra fejlesztették ki, a tesztalapú fejlesztést támogató eszközök speciális formáinak tekinthetők. Az eszközök arra szolgálnak, hogy mindenütt hozzáautomatizálják az aktuális nyelvet, amely központi témája a BDD.
A BDD-t nagyrészt megkönnyíti egy egyszerű tartományspecifikus nyelv (DSL) használata természetes nyelvű konstrukciók (pl. angolszerű mondatok) használatával, amelyek kifejezhetik a viselkedést és a várt eredményeket. Tesztszkriptek már régóta népszerű alkalmazása DSLs különböző fokú kifinomultsága. A BDD tekinthető hatékony technikai gyakorlatnak, különösen, ha a "problématér" az üzleti probléma megoldására összetett.
Előzmények A viselkedésvezérelt fejlesztés a tesztalapú fejlesztés kiterjesztése: fejlesztés, amely egy egyszerű, tartományspecifikus parancsfájlnyelvet használ. Ezek a DSL-ek strukturált természetes nyelvi állításokat konvertálnak végrehajtható tesztekké. Az eredmény egy adott funkció elfogadási feltételeivel és a funkció érvényesítéséhez használt tesztekkel való szorosabb kapcsolat. Mint ilyen, ez általában egy természetes kiterjesztésű TDD-vizsgálat.
A BDD a következőkre összpontosít:
Hol kezdjem a folyamatot Mit kell tesztelni, és mit nem tesztelni Mennyit kell tesztelni egy helyen Mit kell vizsgálni Hogyan értsük meg, miért nem sikerül egy teszt
Középpontjában áll, hogy egy egység tesztelésének és elfogadásának vizsgálatának elkerülése érdekében kérdések merülnek fel. A BDD például azt javasolja, hogy az egységtesztnevek egész mondatok legyenek, amelyek feltételes igével kezdődnek (például angolul kell írni), és az üzleti érték sorrendjében kell írni. Az elfogadási teszteket a felhasználói történet szabványos, agilis keretrendszerének használatával kell megírni: "[szerepként] [funkciót] szeretnék, hogy [előny] legyen". Az elfogadási kritériumokat forgatókönyvekben kell megírni, és osztályokként kell végrehajtani: Tekintettel [kezdeti kontextusra], amikor [esemény bekövetkezik], majd [bizonyos eredmények biztosítása].
Ettől a ponttól kezdve sokan fejlesztettek ki BDD-keretrendszereket az évek során, végül egy kommunikációs és együttműködési keretrendszerként alakítva ki a fejlesztők, a minőségbiztosítási rendszer és a nem műszaki vagy üzleti résztvevők számára egy szoftverprojektben. A 2009 novemberében Londonban az "Agile specifications, BDD and Testing eXchange" során Dan Northa következő leírást adta a BDD-ről:A BDD egy második generációs, külső, pull-alapú, több érdekelt fél, többszintű, nagy automatizálású, agilis módszertan. Leírja a jól meghatározott kimenetekkel való interakciók ciklusát, ami a működő, tesztelt szoftverek szállítását eredményezi.Egy interjú során Dan North a GOTO konferencián 2013-ban, Liz Keogh a következőt állította a BDD-ről:Példákat használ, hogy átbeszéljék, hogyan viselkedik egy alkalmazás... És beszélgetünk ezekről a példákról.Dan North létrehozott egy BDD keretrendszert, a JBehave-t, amit egy story-szintű BDD keretrendszer követett Ruby számára, RBehave néven, amelyet később integráltak az RSpec projektbe. Együtt dolgozott David Chelimskyvel, Aslak Hellesøyvel és másokkal az RSpec fejlesztésén, valamint a "The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends" című könyv megírásában is. Az első történetalapú keret RSpec később helyébe Cucumber, elsősorban Aslak Hellesøy által fejlesztett. Capybara, amely része a Cucumber vizsgálati keret egy ilyen webalapú teszt automatizálási szoftver.
A BDD alapelvei A tesztvezérelt fejlesztés olyan szoftverfejlesztési módszertan, amely lényegében kimondja, hogy a szoftverfejlesztőnek minden egyes szoftveregység esetében:
először határozza meg az egységteszteket csináljanak sikertelen teszteket ezután végrehajtja az egységteszteket; végül ellenőrizze, hogy az egységtesztek végrehajtása sikeressé teszi-e a teszteket.
Ez a meghatározás nem pontos, mert lehetőséget ad a magas szintű szoftverkövetelményekre, az alacsony szintű technikai részletekre, valamint további elemekre vonatkozó tesztek elvégzésére. Egy jó megközelítése a BDD-nek ezek után az, hogy a TDD olyan továbbfejlesztett változata, ami szigorúbb döntéseket hoz, mint maga a TDD.
A viselkedés vezérelt fejlesztés meghatározza, hogy a szoftver bármely egységének tesztjeit az egység kívánt viselkedése szerint kell meghatározni. Az agilis szoftverfejlesztésből a "kívánt viselkedés" ebben az esetben a vállalkozás által meghatározott követelményekből áll, azaz a kívánt viselkedésből, amely üzleti értéket képvisel bármilyen szervezet számára, amely az építés alatt álló szoftveregységet bízta meg. A BDD gyakorlatán belül ezt "külső tevékenységnek" nevezik.
Viselkedési előírások Ezt követően az alapvető választás, a második választás által a BDD-hez kapcsolódik, hogy a kívánt viselkedést meg kell határozni. Ezen a területen BDD úgy dönt, hogy egy félformális formátum viselkedési specifikáció, amely kölcsönzött felhasználói történet előírások területén objektumorientált elemzés és design. Ennek a formátumnak a forgatókönyve a Hoare-logika alkalmazásaként tekinthető, a helyzet domain nyelvét használó szoftveregységek viselkedési specifikációjára.
A BDD azt határozza meg, hogy az üzleti elemzőknek és fejlesztőknek együtt kell működniük ezen a területen, és meg kell határozniuk a felhasználói történetek viselkedését, amelyek mindegyike kifejezetten le van írva egy dedikált dokumentumba. Minden felhasználói történetnek valamilyen módon a következő struktúrát kell követnie:
Cím Egy explicit cím.
Narratíva Rövid bevezető rész a következő szerkezettel: As a (mint): az a személy vagy szerep, aki vagy amely a funkció előnyeit élvezheti; I want (azt akarom): a funkció; so that (úgy, hogy): a funkció előnye vagy értéke.
Elfogadási kritériumok A narratíva minden egyes forgatókönyvének leírása a következő szerkezettel: Given - Adott: a forgatókönyv elején, egy vagy több záradékban szereplő kezdeti környezet; When - Mikor: a forgatókönyvet kiváltó esemény; Then - Ezután: a várt eredmény, egy vagy több záradékban.
A BDD-ben nincsenek hivatalos követelmények, hogy pontosan hogyan kell ezeket a felhasználói történeteket leírni, de ez nem jelenti azt, hogy minden esetben a BDD segítségével el lehet érni egy egyszerű, szabványosított formátumban leírt a felhasználói történetet, amely magában foglalja a fent felsorolt elemeket. Azonban 2007-ben Dan North egy olyan szöveges formátum sablonját javasolta, amely széles körben követi a különböző BDD-szoftvereszközöket. Egy nagyon rövid példa erre a formátumra így nézhet ki: (Title) Cím: A visszaküldések és a cserék a készletbe kerülnek.
(As a) Üzlettulajdonosként (I want) Cikkeket szeretnék visszaadni a készlethez, amikor visszaküldik. (so that) Nyomon tudjam követni a leltárt.
1. forgatókönyv: A visszatérítésre visszaküldött cikkeket hozzá kell adni a készlethez. (Given) Tekintettel arra, hogy egy ügyfél korábban vásárolt egy fekete pulóvert tőlem (And) És van három fekete pulóverem a leltárban, (When) Amikor visszaadják a fekete pulóvert visszatérítésre, (Then) Akkor négy fekete pulcsit kéne leltárba raknom.
2. forgatókönyv: A kicserélt cikkeket vissza kell adni a készletbe. (Given) Tekintettel arra, hogy egy ügyfél korábban vásárolt egy kék ruhát tőlem (And) és van két kék ruha (And) és három fekete ruhadarab a leltárban, (When) amikor a kék ruhát fekete ruhadarabra cserélik, (Then) akkor három kék ruhadarabot kellene leltárba raknom. (And) és két fekete ruhadarab a leltárban. A forgatókönyveket ideális esetben deklaratív módon fogalmazzák meg, nem pedig üzleti nyelven, hivatkozással a felhasználói felület azon elemeire, amelyeken keresztül a kölcsönhatások zajlanak.
Ezt a formátumot a gherkin nyelvnek nevezik, amelynek szintaxisa hasonló a fenti példához. A kifejezés Cucumber, JBehave, Lettuce nevéhez köthető és Behat szoftvereszközöknek nevezik.
Specifikáció mint a mindenütt jelenlévő nyelv Viselkedésvezérelt fejlesztés kölcsönzi a koncepció a mindenütt jelenlévő nyelv, domain alapú design. A mindenütt jelenlévő nyelv egy (félig)formális nyelv, amelyet a szoftverfejlesztő csapat minden tagja megoszt – szoftverfejlesztők és nem műszaki személyzet egyaránt. A szóban forgó nyelvet a csapat minden tagja használja és fejleszti, mint a szóban forgó szoftver domainjének megvitatására. Ily módon a BDD a szoftverprojekt különböző szerepei közötti kommunikáció eszköze lesz.
A szoftverfejlesztés gyakori kockázata a fejlesztők és az üzleti érdekelt felek közötti kommunikációs bontás. A BDD a kívánt viselkedés specifikációját használja a projekt csapattagjai számára mindenütt jelenlévő nyelvként. Ez az oka annak, hogy a BDD ragaszkodik a félhivatalos nyelv viselkedési specifikációjához: néhány formalitás követelmény, hogy a mindenütt ugyanazt a nyelvet használják. Ezen túlmenően, miután egy ilyen mindenütt jelenlévő nyelv létrehoz egy domain modell előírást, amellyel a specifikációkat lehet indokolni hivatalosan. Ez a modell képezi a rendelkezésre álló különböző BDD-támogató szoftvereszközök alapját is.
A fenti példa létrehoz egy felhasználói történetet egy fejlesztés alatt lévő szoftverrendszerhez. Ez a felhasználói történet azonosítja az érdekelt feleket, az üzleti hatást és az üzleti értéket. A forgatókönyv ismerteti az előfeltétel, a kiváltó és várható eredményt. E részek mindegyikét pontosan azonosítja a nyelv formálisabb része (például a Given kifejezés kulcsszónak tekinthető), és ezért valamilyen módon feldolgozható egy olyan eszköz, amely megérti a mindenütt jelenlévő nyelv formális részeit.
A legtöbb BDD-alkalmazás szövegalapú DSL-eket és specifikációs megközelítéseket használ. Az integrációs forgatókönyvek grafikus modellezése azonban a gyakorlatban is sikeresen alkalmazva lett, például tesztelési célokra.
Speciális eszköztámogatás Hasonlóan a tesztalapú tervezési gyakorlathoz, a viselkedésalapú fejlesztés is speciális támogatási eszközök használatát feltételezi a projektben. Annyi, hogy ha BDD van, az sok tekintetben, egy konkrétabb változata a TDD-nek, de több igényt támaszt a fejlesztő, mint az alapvető TDD.
Eszközgyártási alapelvek Elvileg a BDD egy támogatási eszköz, egy tesztelési keretrendszere a szoftvernek, ugyanúgy, mint az eszközök, amelyek támogatják a TDD-t. Azonban, ahol a TDD-eszközök általában meglehetősen szabad formátumúak, amit megengedett a vizsgálatok meghatározása, a BDD eszközök kapcsolódnak a mindenütt jelenlévő nyelvhez.