BDD: шта је то, сценарији понашања и фрејмворци

Шта је BDD?

Behavior-Driven Development — еволуција TDD-а коју је предложио Dan North 2006. године као одговор на проблем формулисања тестова. У TDD-у програмер пише тест, али питање „шта тачно тестирати?“ остаје отворено. BDD решава овај проблем померајући фокус са тестирања кода на опис понашања система са становишта корисника.

Кључна иновација BDD-а — заједнички језик за све учеснике пројекта. Програмери, тестери, аналитичари и клијенти разговарају о сценаријима на јединственом језику који је истовремено и извршни тест. Ово уклања класични проблем „поквареног телефона“, када захтеви губе смисао при преношењу од аналитичара до програмера.

Историја настанка BDD-а

Dan North је формулисао BDD 2006. године у чланку „Introducing BDD“ на блогу ThinkCode. Приметио је да се називи тестова у TDD-у често формулишу у терминима имплементације („testAddUser“), а не у терминима понашања („user should be able to register with email“). BDD је заменио реч „test“ са „should“ и „assert“ са „expect“, померајући фокус на вредност за корисника.

BDD као комуникациона пракса

Према истраживању Cambridge University (2021), пројекти који користе BDD сценарије у комуникацији са клијентом смањују број грешака у захтевима за 35% у поређењу са традиционалним спецификацијама у текстуалним документима. Извршни сценарији не дозвољавају двосмислене формулације — свако Given-When-Then или се извршава или не.

Језик Gherkin и синтакса

Gherkin — доменски језик који користе фрејмворци Cucumber и SpecFlow за описивање сценарија понашања. Gherkin користи увлачења и кључне речи за структурирање сценарија, остајући притом читљив особи без техничког знања.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Кључне речи Gherkin-а

Gherkin дефинише неколико основних кључних речи. Feature описује функционалност, Scenario — конкретан сценариј, Given — предуслове, When — радњу, Then — очекивани резултат. Додатно, And и But се користе за обједињавање више услова.

Структура .feature датотеке

Gherkin датотеке имају екстензију .feature и чувају се у директоријуму src/test/resources/features/ у Android пројектима. Свака датотека почиње описом Feature, након чега следи један или више Scenario. За параметризацију се користи Scenario Outline са табелама Examples — ово омогућава покретање истог сценарија са различитим подацима.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Формат Given-When-Then

Given-When-Then — структурални образац за описивање сценарија, преузет од BDD-а из domain-driven design-а. Сваки сценариј се састоји из три дела: предуслова, радње и очекиваног резултата. Овај формат природно одговара Arrange-Act-Assert из unit тестирања, али користи пословно разумљив језик.

Given: контекст

Блок Given описује стање система пре почетка сценарија: који подаци постоје, које компоненте су активне, у ком режиму ради апликација. У мобилном контексту то може бити „корисник је пријављен“, „корпа није празна“ или „уређај је у офлајн режиму“.

When: радња

Блок When описује догађај који покреће корисник или систем: притисак на дугме, примање push обавештења, одговор сервера. У мобилним апликацијама ово често одговара позиву ViewModel методе или додиру UI елемента.

Then: резултат

Блок Then описује очекивану промену стања: промену екрана, позив API-ја, ажурирање базе података. Провере у Then морају бити мерљиве и недвосмислене — one постају асерције у извршном коду.

BDD и TDD: поређење приступа

BDD и TDD се често мешају, иако су различити нивои дисциплине. TDD — техника пројектовања на нивоу кода: „како написати имплементацију“. BDD — техника спецификације на нивоу захтева: „шта систем треба да ради“.

Узајамно допуњавање у пројекту

Најбољи мобилни пројекти користе TDD на нивоу појединачних класа (domain слој) и BDD на нивоу сценарија (feature слој). Ово даје дупло покриће: TDD гарантује исправност имплементације, BDD — исправност разумевања захтева. Google у својој интерној пракси користи комбинацију TDD-а и BDD-а за Android апликације, како је наведено у документацији Android Testing (2024).

BDD алати за мобилни развој

Екосистем BDD-а укључује фрејмворке за све популарне платформе и језике мобилног развоја. Избор алата зависи од технолошког стека и нивоа аутоматизације.

Cucumber за Android

Cucumber — најпопуларнији BDD фрејмворк који ради са Gherkin сценаријима. За Android пројекте користи се библиотека io.cucumber:cucumber-android, која се интегрише са алатима за UI тестирање Espresso и Compose Test. Cucumber подржава Kotlin и Java, што га чини универзалним избором за студије које користе оба језика.

SpecFlow за Xamarin

SpecFlow — BDD фрејмворк за .NET екосистем, који се користи у Xamarin.Forms и .NET MAUI пројектима. SpecFlow се интегрише са NUnit и xUnit, а његови кораци (step definitions) се пишу у C#-у. За мобилне пројекте SpecFlow омогућава поновну употребу сценарија између Android и iOS верзија апликације на заједничкој бази кода.

Quick/Nimble за iOS

За iOS развој у Swift-у постоје BDD фрејмворци Quick и Nimble. Quick пружа DSL за описивање сценарија у стилу describe/it, а Nimble — matcher-е са читљивом синтаксом. Иако ови фрејмворци не користе Gherkin директно, они имплементирају принцип BDD-а: описивање понашања језиком разумљивим целом тиму.

Примери BDD сценарија и кода

Размотримо комплетан пример BDD-а у Android пројекту: сценариј наручивања. Прво пишемо Gherkin сценариј, затим — step definitions у Kotlin-у.

Принцип рада BDD-а: three amigos

Методологија BDD-а се заснива на састанку three amigos — три улоге: програмер, тестер и аналитичар. Они заједно пишу сценарије пре почетка развоја, фиксирајући заједничко разумевање захтева. Ако сценариј није одговарајући ни за једног од три учесника — значи да је захтев формулисан нејасно. Ова пракса је описана у књизи „Discovery: Explore Behaviour Using Examples“ (Gáspár & North, 2021) и обавезан је део BDD процеса у зрелим тимовима.

Gherkin сценариј наручивања

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step definitions у Kotlin-у

Step definitions — код који повезује Gherkin сценариј са тест имплементацијом. Сваки корак је метода са анотацијом која одговара кључној речи Gherkin-а.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Интеграција са Cucumber Android

За покретање BDD тестова у Android пројекту користи се CucumberAndroidJUnitRunner. Он скенира .feature датотеке у ресурсима, проналази одговарајуће step definitions по регуларним изразима и извршава сценарије као обичне инструменталне тестове. Резултати се форматирају у HTML извештај разумљив клијенту.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

Тешкоће увођења BDD-а у мобилне пројекте

Увођење BDD-а у мобилни развој праћено је низом практичних потешкоћа. Свест о овим проблемима помаже тимовима да избегну разочарање и изграде одржив BDD процес.

Одржавање .feature датотека

Основни проблем — десинхронизација између Gherkin сценарија и продукционог кода. Ако програмери мењају API без ажурирања step definitions, .feature датотеке престају да одговарају имплементацији. Решење — покретање BDD тестова у CI/CD пајплајну и захтевање зеленог статуса за merge request. Пракса „BDD as a gating mechanism“ описана је у документацији Cucumber (2024) и стандард је у индустрији.

Перформансе BDD тестова

BDD сценарији на Cucumber-у се извршавају кроз инструменталне тестове на Android уређају или емулатору. Ово је 10–50 пута спорије од обичних unit тестова на JVM-у. Једно пријемно тестирање може трајати 20–30 минута за велику Android апликацију. Препоручује се издвајање BDD тестова у посебан CI задатак и покретање ноћу, а unit тестова — на сваки push. Оваква стратегија балансира брзину повратне информације и покривеност сценарија.

Обука тима за Gherkin

Прелазак на BDD захтева обуку не само програмера, већ и аналитичара и тестера. Gherkin је једноставан језик, али писање добрих сценарија захтева праксу. Типичне грешке почетника: предуги сценарији (више од 10 корака), мешање Given-When-Then, коришћење техничких термина у пословним сценаријима. Према BDD Academy (2024), тимовима је потребно у просеку 4–6 спринтова да достигну зрелост у писању BDD сценарија.