BDD насоки и най-добри практики
BDD (Behavior Driven Development) е методология за разработване на софтуер чрез непрекъснато базиран на пример комуникация между разработчици, QA и BA. В тази статия обсъждаме някои най-добри практики за BDD, за да извлечем максимална полза.
Повече от всичко друго, основната цел на методологията BDD е да насърчи комуникацията между заинтересованите страни в проекта, така че контекстът на всяка функция да бъде правилно разбран от всички членове на екипа (т.е. споделено разбиране), преди да започне работата по разработката. Това помага при идентифицирането на ключови сценарии за всяка история и също така премахва неяснотите от изискванията.
В BDD примерите се наричат сценарии. Сценариите са структурирани около Контекст-действие-резултат pattern и са написани в специален формат, наречен Корнишон .
Сценариите са начин за обяснение (на обикновен английски) как дадена функция трябва да се държи в различни ситуации или с различни входни параметри.
Тъй като Корнишонът е структурен, той служи както за спецификация, така и за вход в автоматизирани тестове, откъдето идва и името „Изпълними спецификации“.
Какво е файл с функции и какво съдържа той
Файловете с функции са текстови файлове с .особеност разширение, което може да се отвори от всеки текстов редактор, както и да се чете от всеки инструмент, познаващ BDD, като Cucumber, JBehave или Behat.
Файловете с характеристики трябва да започват с контекста на функцията (което по същество е историята), последван от поне един сценарий в следния формат
Особеност: Някакъв кратък, но описателен текст на желаното
За да се реализира посочена бизнес стойност
Като явен системен актьор
Искам да постигна някакъв полезен резултат, който да допринесе за целта
Сценарий: Някаква определима бизнес ситуация
Предвид някаква предпоставка
И някаква друга предпоставка
Когато някакво действие на актьора
И някакво друго действие
И още едно действие
Тогава се постига някакъв проверяем резултат
И нещо друго, което можем да проверим, също се случва
Сценариите във файловете с функции трябва да се фокусират върху „какво“, а не „как“. Сценариите трябва да бъдат кратки и точни, така че читателят да може бързо да разбере намерението на теста, без да се налага да чете много неподходящи стъпки.
Защо трябва да пишем функционални файлове
Както бе споменато по-горе, основната цел на методологията BDD е да насърчи комуникацията между екипа за доставка. Целта на файловете на характеристиките е да документират сценариите, за които се говори, за да се посочи колко работа е свързана с предоставянето на характеристиката. Файловете с функции са и драйверите за автоматизираните тестове. Файловете с функции също служат като дефиниция на готово (DoD), което означава, че когато всички сценарии са внедрени и тествани успешно, можем да маркираме историята като завършена.
Кой трябва да пише файлове с функции
Всъщност няма значение кой всъщност пише / пише файловете на характеристиките, това може да е всеки член на екипа за доставка, но съдържанието (сценариите), които се обсъждат от трио от Dev-QA-BA, са съществената част на характеристиката файлове. Получаването на споделеното общо разбиране за функцията е ключовият елемент.
Кога трябва да се пишат файлове с функции
Файловете с функции трябва да бъдат написани по време на сесиите за подреждане на истории, където се обсъждат подробностите за всяка история. Файловете, съдържащи сценарии, трябва да бъдат написани преди стартирането на разработката, така че разработчиците, както и QA да имат ясно разбиране за намерението на историята. Трябва да има споделено разбиране на историята. Сценариите служат като изисквания към развитието.
Къде трябва да се съхраняват файлове с функции
Трябва да има един източник на истина, който да служи както за спецификация, така и за автоматично изпълнение, следователно трябва да се съхранява някъде, където всеки член на екипа има лесен достъп.
Като се има предвид това, тъй като файловете на характеристиките са двигателите на автоматизираните тестове, те в идеалния случай трябва да се съхраняват в системата за контрол на източника (GitHub), така че всички актуализации на файловете с функции да се отразяват незабавно върху тестовете.
За нетехнически членове, които нямат опит с Git, винаги можем да изпълним сухо пускане на файловете на характеристиките, които след това ще изведат списъка на всички съществуващи сценарии, без действително да упражняват файловете с функции.
Как трябва да пишем функционални файлове
Обикновено има два начина за писане на файлове с функции - императивен и декларативен
Наложително стил на писане на файл с функции, е много подробен, съдържа подробности от ниско ниво и твърде много информация.
Плюсове: човек, който чете файла с характеристиките, може да следва стъпка по стъпка
Минуси: Поради твърде много подробности, читателят може да загуби смисъла на историята и тестовете. Файлът на характеристиките става твърде голям, труден за поддръжка и вероятно ще се провали поради актуализации на потребителския интерфейс.
Декларативна стилът на писане на файл с функции е кратък и точният, съдържа само подходяща информация за историята.
Плюсове: Декларативният стил е по-четим, тъй като съдържа по-малко стъпки в сценария. Читателят може лесно да разбере обхвата на теста и бързо да установи дали липсват ключови елементи.
