Кіраўніцтва і лепшыя практыкі BDD

BDD (Behaviour Driven Development) - гэта метадалогія распрацоўкі праграмнага забеспячэння на аснове бесперапыннай працы на прыкладзе сувязь паміж распрацоўшчыкамі, службамі забеспячэння і BA. У гэтым артыкуле мы разгледзім некалькі лепшых практык BDD, каб атрымаць максімальную карысць.

Больш за ўсё астатняе, галоўнай мэтай метадалогіі BDD з'яўляецца стымуляванне камунікацыі паміж зацікаўленымі бакамі праекта, каб кантэкст кожнай асаблівасці быў правільна зразуметы ўсімі членамі каманды (г. зн. Агульнае разуменне), перш чым пачаць працу па распрацоўцы. Гэта дапамагае вызначыць ключавыя сцэнарыі для кожнай гісторыі, а таксама выкараніць неадназначнасці з патрабаванняў.

У BDD прыклады называюцца сцэнарыямі. Сцэнарыі пабудаваны вакол Кантэкст-Дзеянне-Вынік шаблон і пішуцца ў спецыяльным фармаце, які называецца Карнішоны .


Сцэнарыі - гэта спосаб растлумачыць (на простай англійскай мове), як павінна паводзіць сябе дадзеная функцыя ў розных сітуацыях альбо з рознымі параметрамі ўводу.

Паколькі Карнішон з'яўляецца структурнай структурай, ён служыць і спецыфікацыяй, і ўводам у аўтаматызаваныя тэсты, адсюль і назва 'Выкананыя спецыфікацыі'.


Што такое файл функцый і што ён утрымлівае

Файлы функцый - гэта тэкставыя файлы з .асаблівасць пашырэнне, якое можна адкрыць любым тэкставым рэдактарам, а таксама прачытаць любым інструментам, які ведае BDD, напрыклад, Cucumber, JBehave або Behat.



Файлы функцый павінны пачынацца з кантэксту функцыі (а гэта, па сутнасці, гісторыя), пасля чаго прынамсі адзін сцэнар у наступным фармаце

Асаблівасць: Нейкі сціслы, але апісальны тэкст жаданага

Для таго, каб рэалізаваць названую каштоўнасць бізнесу
Як відавочны акцёр сістэмы
Я хачу атрымаць нейкі карысны вынік, які прасоўвае мэту


Сцэнар: Некаторая вызначальная дзелавая сітуацыя

Даецца нейкая перадумова
І яшчэ нейкая перадумова
Калі нейкае дзеянне акцёра
І яшчэ нейкая акцыя
І яшчэ адна акцыя
Тады дасягаецца нейкі праверальны вынік
І адбываецца яшчэ нешта, што мы можам праверыць

Сцэнарыі ў файлах функцый павінны быць сканцэнтраваны на 'што', а не на 'як'. Сцэнарыі павінны быць кароткімі і дакладнымі, каб чытач мог хутка зразумець намер тэсту, не чытаючы шмат неактуальных крокаў.

Чаму мы павінны пісаць файлы функцый

Як ужо згадвалася раней, галоўнай мэтай метадалогіі BDD з'яўляецца стымуляванне зносін паміж камандай дастаўкі. Мэтай файлаў функцый з'яўляецца дакументаванне абмеркаваных сцэнарыяў, каб паказаць, наколькі шмат працы патрабуецца для дастаўкі функцыі. Файлы функцый таксама з'яўляюцца драйверамі для аўтаматызаваных тэстаў. Файлы функцый таксама служаць вызначэннем выкананага (DoD), што азначае, што калі ўсе сцэнарыі будуць паспяхова рэалізаваны і пратэставаны, мы можам адзначыць гісторыю як зробленую.


Хто павінен пісаць файлы функцый

На самой справе не мае значэння, хто на самой справе піша / набірае файлы функцый, гэта можа быць любы член групы дастаўкі, аднак змест (сцэнарыі), якія абмяркоўвае трыо Dev-QA-BA, з'яўляецца важнай часткай функцыі файлы. Атрыманне агульнага агульнага разумення функцыі з'яўляецца ключавым элементам.

Калі трэба пісаць файлы функцый

Файлы функцый павінны быць напісаны падчас сеансаў грумінгу, дзе абмяркоўваюцца дэталі кожнай гісторыі. Файлы функцый, якія змяшчаюць сцэнарыі, павінны быць напісаны перад пачаткам распрацоўкі, каб распрацоўшчыкі, а таксама QA мелі дакладнае разуменне намераў гісторыі. Павінна быць агульнае разуменне гісторыі. Сцэнарыі служаць патрабаваннямі да распрацоўкі.

Дзе трэба захоўваць файлы функцый

Павінна быць адна крыніца ісціны, якая служыць і спецыфікацыяй, і аўтаматызаваным выкананнем, таму яе трэба захоўваць дзесьці, дзе кожны член каманды мае лёгкі доступ.

Сказаўшы гэта, паколькі файлы функцый з'яўляюцца драйверамі аўтаматызаваных тэстаў, яны ў ідэале павінны захоўвацца ў сістэме кіравання зыходным кодам (GitHub), каб любыя абнаўленні файлаў функцый адразу адлюстроўваліся на тэстах.


Для нетэхнічных членаў, якія не маюць досведу працы з Git, мы заўсёды можам выканаць сухі запуск файлаў функцый, пасля чаго выведзе спіс усіх існуючых сцэнарыяў, не выкарыстоўваючы файлы функцый.

Як нам пісаць файлы функцый

Звычайна існуе два спосабы напісання файлаў функцый - абавязковы і дэкларатыўны

Імператыў стыль напісання файла функцый вельмі шматслоўны, змяшчае падрабязнасці нізкага ўзроўню і занадта шмат інфармацыі.

Плюсы: чалавек, які чытае файл функцый, можа выконваць пакрокавыя інструкцыі


Мінусы: з-за занадта вялікай колькасці дэталяў чытач можа страціць сэнс гісторыі і тэстаў. Файл функцый становіцца занадта вялікім, яго складана падтрымліваць і, магчыма, выйдзе з ладу з-за абнаўленняў карыстацкага інтэрфейсу.

Дэкларатыўны стыль напісання файла функцый кароткі і дакладны, утрымлівае толькі адпаведную інфармацыю пра гісторыю.

Плюсы: дэкларатыўны стыль больш зручны для чытання, бо змяшчае менш этапаў сцэнарыя. Чытач можа лёгка зразумець аб'ём тэсту і хутка вызначыць, ці адсутнічаюць якія-небудзь ключавыя элементы.