BDD: ano ito, mga senaryo ng pag-uugali at framework

Ano ang BDD?

Behavior-Driven Development — ay isang ebolusyon ng TDD, na iminungkahi ni Dan North noong 2006 bilang tugon sa problema ng pagbuo ng mga test. Sa TDD, ang developer ay nagsusulat ng test, ngunit ang tanong na „ano ang eksaktong susuriin?“ ay nananatiling bukas. Niresolba ng BDD ang problemang ito sa pamamagitan ng paglipat ng focus mula sa pag-test ng code patungo sa paglalarawan ng pag-uugali ng system mula sa pananaw ng user.

Ang pangunahing inobasyon ng BDD — karaniwang wika para sa lahat ng kalahok ng proyekto. Ang mga developer, tester, analyst, at kliyente ay nagtatalakay ng mga senaryo sa isang pinag-isang wika na sabay ding isang executable na test. Inaalis nito ang klasikong problema ng „sirang telepono“, kung saan ang mga kinakailangan ay nawawalan ng kahulugan sa paglipat mula sa analyst patungo sa developer.

Kasaysayan ng BDD

Binumula ni Dan North ang BDD noong 2006 sa artikulong „Introducing BDD“ sa blog na ThinkCode. Napansin niya na ang mga pangalan ng test sa TDD ay kadalasang binubuo sa mga termino ng implementasyon („testAddUser“), hindi sa mga termino ng pag-uugali („user should be able to register with email“). Pinalitan ng BDD ang salitang „test“ ng „should“ at „assert“ ng „expect“, inilipat ang focus sa halaga para sa user.

BDD bilang isang kasanayan sa komunikasyon

Ayon sa pananaliksik ng Cambridge University (2021), ang mga proyektong gumagamit ng BDD senaryo sa komunikasyon sa kliyente ay nagbabawas ng bilang ng mga error sa mga kinakailangan ng 35% kumpara sa tradisyonal na mga specification sa mga text document. Ang mga executable na senaryo ay hindi pumapayag sa mga hindi malinaw na pormulasyon — bawat Given-When-Then ay maaaring isagawa o hindi.

Wikang Gherkin at syntax

Gherkin — ay isang domain-specific na wika, na ginagamit ng mga framework na Cucumber at SpecFlow para sa paglalarawan ng mga senaryo ng pag-uugali. Gumagamit ang Gherkin ng indentation at mga keyword para sa pag-istruktura ng mga senaryo, habang nananatiling nababasa para sa isang tao na walang teknikal na background.

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

Mga keyword ng Gherkin

Tinutukoy ng Gherkin ang ilang pangunahing keyword. Inilalarawan ng Feature ang functionality, Scenario — ang konkretong senaryo, Given — ang mga precondition, When — ang aksyon, Then — ang inaasahang resulta. Dagdag pa, ang And at But ay ginagamit para pagsamahin ang maraming kondisyon.

Istraktura ng .feature file

Ang mga file ng Gherkin ay may extension na .feature at iniimbak sa direktoryong src/test/resources/features/ sa mga proyektong Android. Ang bawat file ay nagsisimula sa paglalarawan ng Feature, na sinusundan ng isa o higit pang Scenario. Para sa parametrization ginagamit ang Scenario Outline na may mga table na Examples — pinapayagan nito na patakbuhin ang parehong senaryo na may iba't ibang data.

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     |

Format na Given-When-Then

Given-When-Then — ay isang structural pattern para sa paglalarawan ng mga senaryo, na hiniram ng BDD mula sa domain-driven design. Ang bawat senaryo ay binubuo ng tatlong bahagi: precondition, aksyon, at inaasahang resulta. Ang format na ito ay natural na tumutugma sa Arrange-Act-Assert mula sa unit testing, ngunit gumagamit ng wikang nauunawaan ng negosyo.

Given: konteksto

Ang bloke na Given ay naglalarawan ng estado ng system bago magsimula ang senaryo: anong data ang umiiral, anong mga component ang aktibo, sa anong mode gumagana ang application. Sa mobile na konteksto, ito ay maaaring „naka-log in ang user“, „hindi walang laman ang cart“ o „offline ang device“.

When: aksyon

Ang bloke na When ay naglalarawan ng kaganapan na pinasimulan ng user o system: pagpindot ng button, pagtanggap ng push notification, tugon ng server. Sa mga mobile application, ito ay kadalasang tumutugma sa pagtawag ng ViewModel method o pag-tap sa UI element.

Then: resulta

Ang bloke na Then ay naglalarawan ng inaasahang pagbabago ng estado: pagbabago ng screen, pagtawag ng API, pag-update ng database. Ang mga pagsusuri sa Then ay dapat na masusukat at hindi malabo — sila ay nagiging mga assertion sa executable na code.

BDD at TDD: paghahambing ng mga approach

Ang BDD at TDD ay madalas na ikinalilito, bagaman ang mga ito ay magkaibang antas ng disiplina. Ang TDD — ay isang technique ng disenyo sa antas ng code: „kung paano isulat ang implementasyon“. Ang BDD — ay isang technique ng specification sa antas ng mga kinakailangan: „ano ang dapat gawin ng system“.

Pagtutulungan sa proyekto

Ang pinakamahuhusay na mobile project ay gumagamit ng TDD sa antas ng indibidwal na klase (domain layer) at BDD sa antas ng senaryo (feature layer). Ito ay nagbibigay ng dobleng coverage: ginagarantiyahan ng TDD ang kawastuhan ng implementasyon, ng BDD — ang kawastuhan ng pag-unawa sa mga kinakailangan. Ginagamit ng Google sa kanyang internal na kasanayan ang kombinasyon ng TDD at BDD para sa mga Android application, gaya ng nakasaad sa dokumentasyon ng Android Testing (2024).

Mga tool sa BDD para sa mobile development

Ang BDD ecosystem ay sumasaklaw sa mga framework para sa lahat ng sikat na platform at wika ng mobile development. Ang pagpili ng tool ay depende sa technology stack at antas ng automation.

Cucumber para sa Android

Cucumber — ang pinakasikat na BDD framework na gumagana sa Gherkin senaryo. Para sa mga proyektong Android ginagamit ang library na io.cucumber:cucumber-android, na integrate sa UI testing tool na Espresso at Compose Test. Sinusuportahan ng Cucumber ang Kotlin at Java, na ginagawa itong isang unibersal na pagpili para sa mga studio na gumagamit ng parehong wika.

SpecFlow para sa Xamarin

SpecFlow — BDD framework para sa .NET ecosystem, ginagamit sa mga proyektong Xamarin.Forms at .NET MAUI. Integrate ang SpecFlow sa NUnit at xUnit, at ang kanyang mga hakbang (step definitions) ay isinusulat sa C#. Para sa mga mobile project, pinapayagan ng SpecFlow ang muling paggamit ng mga senaryo sa pagitan ng Android at iOS na bersyon ng application sa isang shared codebase.

Quick/Nimble para sa iOS

Para sa iOS development sa Swift, may mga BDD framework na Quick at Nimble. Nagbibigay ang Quick ng DSL para sa paglalarawan ng mga senaryo sa istilong describe/it, at ang Nimble — mga matcher na may nababasang syntax. Kahit na ang mga framework na ito ay hindi direktang gumagamit ng Gherkin, ipinapatupad nila ang prinsipyo ng BDD: paglalarawan ng pag-uugali sa wikang nauunawaan ng buong team.

Mga halimbawa ng BDD senaryo at code

Tingnan natin ang isang kumpletong halimbawa ng BDD sa isang Android project: senaryo ng pag-order. Una naming isinusulat ang Gherkin senaryo, pagkatapos — step definitions sa Kotlin.

Prinsipyo ng pagpapatakbo ng BDD: three amigos

Ang BDD methodology ay batay sa pagpupulong ng three amigos — tatlong papel: developer, tester, at analyst. Sila ay magkasamang nagsusulat ng mga senaryo bago magsimula ang development, na nagtatala ng karaniwang pag-unawa sa mga kinakailangan. Kung ang senaryo ay hindi angkop sa alinman sa tatlong kalahok — nangangahulugan ito na ang kinakailangan ay binubuo nang hindi malinaw. Ang kasanayang ito ay inilarawan sa aklat na „Discovery: Explore Behaviour Using Examples“ (Gáspár & North, 2021) at isang mandatoryong bahagi ng proseso ng BDD sa mga mature na team.

Gherkin senaryo ng pag-order

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 sa Kotlin

Step definitions — code na nag-uugnay ng Gherkin senaryo sa test implementation. Ang bawat hakbang ay isang method na may annotation na tumutugma sa keyword ng 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())
    }
}

Integrasyon sa Cucumber Android

Para sa pagpapatakbo ng BDD test sa isang Android project ginagamit ang CucumberAndroidJUnitRunner. Sinusuri nito ang .feature file sa mga resources, hinahanap ang kaukulang step definitions sa pamamagitan ng regular expression, at isinasagawa ang mga senaryo bilang ordinaryong instrumental test. Ang mga resulta ay ina-format sa isang HTML report na nauunawaan ng kliyente.

// 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

Mga hamon sa pagpapatupad ng BDD sa mga mobile project

Ang pagpapatupad ng BDD sa mobile development ay may kasamang ilang praktikal na paghihirap. Ang kamalayan sa mga problemang ito ay tumutulong sa mga team na maiwasan ang pagkabigo at bumuo ng isang sustainable na proseso ng BDD.

Pagpapanatili ng .feature file

Ang pangunahing problema — desynchronization sa pagitan ng Gherkin senaryo at production code. Kung ang mga developer ay nagbabago ng API nang hindi ina-update ang step definitions, ang .feature file ay hindi na tumutugma sa implementasyon. Solusyon — pagpapatakbo ng BDD test sa CI/CD pipeline at paghingi ng berdeng status para sa merge request. Ang kasanayang „BDD as a gating mechanism“ ay inilarawan sa dokumentasyon ng Cucumber (2024) at isang pamantayan sa industriya.

Pagganap ng BDD test

Ang BDD senaryo sa Cucumber ay isinasagawa sa pamamagitan ng instrumental test sa Android device o emulator. Ito ay 10–50 beses na mas mabagal kaysa sa ordinaryong unit test sa JVM. Isang acceptance testing ay maaaring tumagal ng 20–30 minuto para sa malaking Android application. Inirerekomenda na ihiwalay ang BDD test sa isang hiwalay na CI job at patakbuhin ang mga ito sa gabi, at ang unit test — sa bawat push. Ang ganitong estratehiya ay binabalanse ang bilis ng feedback at coverage ng senaryo.

Pagsasanay ng team sa Gherkin

Ang paglipat sa BDD ay nangangailangan ng pagsasanay hindi lamang ng mga developer kundi pati na rin ng mga analyst at tester. Ang Gherkin ay isang simpleng wika, ngunit ang pagsulat ng magagandang senaryo ay nangangailangan ng pagsasanay. Mga karaniwang pagkakamali ng mga baguhan: masyadong mahahabang senaryo (higit sa 10 hakbang), paghahalo ng Given-When-Then, paggamit ng teknikal na termino sa mga business senaryo. Ayon sa BDD Academy (2024), ang mga team ay nangangailangan ng average na 4–6 sprint upang maabot ang kapanahunan sa pagsulat ng BDD senaryo.