BDD: τι είναι, σενάρια συμπεριφοράς και frameworks

Τι είναι το 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 — είναι μια γλώσσα ειδικού τομέα, που χρησιμοποιείται από τα frameworks 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 από τις δοκιμές μονάδας, αλλά χρησιμοποιεί γλώσσα κατανοητή για την επιχείρηση.

Given: πλαίσιο

Το μπλοκ Given περιγράφει την κατάσταση του συστήματος πριν από την έναρξη του σεναρίου: ποια δεδομένα υπάρχουν, ποια στοιχεία είναι ενεργά, σε ποια λειτουργία λειτουργεί η εφαρμογή. Σε κινητό πλαίσιο, αυτό μπορεί να είναι „ο χρήστης έχει συνδεθεί“, „το καλάθι δεν είναι άδειο“ ή „η συσκευή είναι σε λειτουργία εκτός σύνδεσης“.

When: ενέργεια

Το μπλοκ When περιγράφει το συμβάν που ξεκινά από τον χρήστη ή το σύστημα: πάτημα κουμπιού, λήψη ειδοποίησης push, απόκριση διακομιστή. Σε κινητές εφαρμογές, αυτό συχνά αντιστοιχεί σε κλήση μεθόδου ViewModel ή άγγιγμα στοιχείου UI.

Then: αποτέλεσμα

Το μπλοκ Then περιγράφει την αναμενόμενη αλλαγή κατάστασης: αλλαγή οθόνης, κλήση API, ενημέρωση βάσης δεδομένων. Οι έλεγχοι στο Then πρέπει να είναι μετρήσιμοι και μονοσήμαντοι — γίνονται assertions στον εκτελέσιμο κώδικα.

BDD και TDD: σύγκριση προσεγγίσεων

Το BDD και το TDD συχνά συγχέονται, αν και είναι διαφορετικά επίπεδα πειθαρχίας. Το TDD — τεχνική σχεδιασμού σε επίπεδο κώδικα: „πώς να γράψουμε υλοποίηση“. Το BDD — τεχνική προδιαγραφής σε επίπεδο απαιτήσεων: „τι πρέπει να κάνει το σύστημα“.

Αμοιβαία συμπλήρωση στο έργο

Τα καλύτερα κινητά έργα χρησιμοποιούν TDD σε επίπεδο μεμονωμένων κλάσεων (επίπεδο domain) και BDD σε επίπεδο σεναρίων (επίπεδο feature). Αυτό παρέχει διπλή κάλυψη: το TDD εγγυάται την ορθότητα υλοποίησης, το BDD — την ορθότητα κατανόησης των απαιτήσεων. Η Google στην εσωτερική της πρακτική χρησιμοποιεί συνδυασμό TDD και BDD για εφαρμογές Android, όπως αναφέρεται στην τεκμηρίωση Android Testing (2024).

Εργαλεία BDD για κινητή ανάπτυξη

Το οικοσύστημα BDD περιλαμβάνει frameworks για όλες τις δημοφιλείς πλατφόρμες και γλώσσες κινητής ανάπτυξης. Η επιλογή εργαλείου εξαρτάται από τη στοίβα τεχνολογίας και το επίπεδο αυτοματισμού.

Cucumber για Android

Cucumber — το πιο δημοφιλές framework BDD, που λειτουργεί με σενάρια Gherkin. Για έργα Android χρησιμοποιείται η βιβλιοθήκη io.cucumber:cucumber-android, η οποία ενσωματώνεται με εργαλεία δοκιμής UI Espresso και Compose Test. Το Cucumber υποστηρίζει Kotlin και Java, καθιστώντας το καθολική επιλογή για στούντιο που χρησιμοποιούν και τις δύο γλώσσες.

SpecFlow για Xamarin

SpecFlow — framework BDD για το οικοσύστημα .NET, που χρησιμοποιείται σε έργα Xamarin.Forms και .NET MAUI. Το SpecFlow ενσωματώνεται με NUnit και xUnit, και τα βήματά του (step definitions) γράφονται σε C#. Για κινητά έργα, το SpecFlow επιτρέπει την επαναχρησιμοποίηση σεναρίων μεταξύ εκδόσεων Android και iOS της εφαρμογής σε κοινή βάση κώδικα.

Quick/Nimble για iOS

Για ανάπτυξη iOS σε Swift υπάρχουν τα frameworks BDD Quick και Nimble. Το Quick παρέχει DSL για περιγραφή σεναρίων σε στυλ describe/it, και το Nimble — matchers με αναγνώσιμη σύνταξη. Αν και αυτά τα frameworks δεν χρησιμοποιούν άμεσα το 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 στο pipeline CI/CD και απαίτηση πράσινης κατάστασης για το merge request. Η πρακτική „BDD as a gating mechanism“ περιγράφεται στην τεκμηρίωση Cucumber (2024) και αποτελεί πρότυπο στη βιομηχανία.

Απόδοση δοκιμών BDD

Τα σενάρια BDD στο Cucumber εκτελούνται μέσω ενόργανων δοκιμών σε συσκευή Android ή εξομοιωτή. Αυτό είναι 10–50 φορές πιο αργό από τις συνηθισμένες δοκιμές μονάδας στο JVM. Μία μόνο δοκιμή αποδοχής μπορεί να διαρκέσει 20–30 λεπτά για μια μεγάλη εφαρμογή Android. Συνιστάται ο διαχωρισμός των δοκιμών BDD σε ξεχωριστή εργασία CI και η εκτέλεσή τους τη νύχτα, ενώ οι δοκιμές μονάδας — σε κάθε push. Μια τέτοια στρατηγική εξισορροπεί την ταχύτητα ανάδρασης και την κάλυψη σεναρίων.

Εκπαίδευση ομάδας στο Gherkin

Η μετάβαση στο BDD απαιτεί εκπαίδευση όχι μόνο προγραμματιστών, αλλά και αναλυτών και ελεγκτών. Το Gherkin είναι μια απλή γλώσσα, αλλά η σύνταξη καλών σεναρίων απαιτεί εξάσκηση. Τυπικά λάθη αρχαρίων: πολύ μεγάλα σενάρια (πάνω από 10 βήματα), ανάμειξη Given-When-Then, χρήση τεχνικών όρων σε επιχειρηματικά σενάρια. Σύμφωνα με το BDD Academy (2024), οι ομάδες χρειάζονται κατά μέσο όρο 4–6 sprint για να επιτύχουν ωριμότητα στη σύνταξη σεναρίων BDD.