BDD: এটি কী, আচরণের পরিস্থিতি এবং ফ্রেমওয়ার্ক

BDD কী?

Behavior-Driven Development হল TDD-এর একটি বিবর্তন যা Dan North 2006 সালে টেস্ট প্রণয়নের সমস্যার উত্তর হিসাবে প্রস্তাব করেছিলেন। TDD-তে, ডেভেলপার একটি টেস্ট লেখে, কিন্তু “ঠিক কী টেস্ট করবেন?” প্রশ্নটি উন্মুক্ত থাকে। BDD এই সমস্যার সমাধান করে কোড টেস্টিং থেকে ফোকাস সরিয়ে সিস্টেমের আচরণ বর্ণনা করার দিকে ব্যবহারকারীর দৃষ্টিকোণ থেকে।

BDD-র মূল উদ্ভাবন হল সমস্ত প্রকল্প অংশগ্রহণকারীদের জন্য একটি সাধারণ ভাষা। ডেভেলপার, টেস্টার, বিশ্লেষক এবং গ্রাহকরা একটি একীভূত ভাষায় পরিস্থিতি নিয়ে আলোচনা করেন যা একই সাথে একটি এক্সিকিউটেবল টেস্ট হিসাবে কাজ করে। এটি ক্লাসিক “ভাঙা টেলিফোন” সমস্যা দূর করে যেখানে বিশ্লেষক থেকে ডেভেলপারের কাছে পৌঁছানোর সময় প্রয়োজনীয়তাগুলি অর্থ হারিয়ে ফেলে।

BDD-র উদ্ভবের ইতিহাস

Dan North 2006 সালে ThinkCode ব্লগে তার “Introducing BDD” নিবন্ধে BDD প্রণয়ন করেছিলেন। তিনি লক্ষ্য করেছিলেন যে TDD-তে টেস্টের নামগুলি প্রায়শই বাস্তবায়নের পরিভাষায় (“testAddUser”) তৈরি করা হয় আচরণের পরিভাষায় নয় (“ব্যবহারকারী ইমেল দিয়ে নিবন্ধন করতে সক্ষম হওয়া উচিত”)। BDD “test” শব্দটিকে “should” এবং “assert”-কে “expect” দিয়ে প্রতিস্থাপন করেছে, ফোকাস ব্যবহারকারীর মূল্যে স্থানান্তরিত করেছে।

যোগাযোগ অনুশীলন হিসাবে BDD

কেমব্রিজ বিশ্ববিদ্যালয়ের গবেষণা (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 এবং Android প্রকল্পগুলিতে src/test/resources/features/ ডিরেক্টরিতে সংরক্ষিত হয়। প্রতিটি ফাইল Feature বর্ণনা দিয়ে শুরু হয়, তার পরে এক বা একাধিক Scenario থাকে। প্যারামিটারাইজেশনের জন্য Examples টেবিল সহ Scenario Outline ব্যবহার করা হয় — এটি বিভিন্ন ডেটার সাথে একই পরিস্থিতি চালানোর অনুমতি দেয়।

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 ডোমেন-ড্রিভেন ডিজাইন থেকে গ্রহণ করেছে। প্রতিটি পরিস্থিতি তিনটি অংশ নিয়ে গঠিত: পূর্বশর্ত, ক্রিয়া এবং প্রত্যাশিত ফলাফল। এই ফরম্যাটটি স্বাভাবিকভাবেই ইউনিট টেস্টিং-এর Arrange-Act-Assert-এর সাথে মিলে যায় কিন্তু ব্যবসা-বান্ধব ভাষা ব্যবহার করে।

Given: প্রসঙ্গ

Given ব্লক পরিস্থিতি শুরুর আগে সিস্টেমের অবস্থা বর্ণনা করে: কী ডেটা বিদ্যমান, কোন উপাদানগুলি সক্রিয়, অ্যাপ্লিকেশন কোন মোডে আছে। মোবাইল প্রসঙ্গে, এটি “ব্যবহারকারী লগইন করেছেন”, “কার্ট খালি নয়” বা “ডিভাইস অফলাইন মোডে আছে” হতে পারে।

When: ক্রিয়া

When ব্লক ব্যবহারকারী বা সিস্টেম দ্বারা ট্রিগার করা একটি ঘটনা বর্ণনা করে: বোতাম টিপুন, push বিজ্ঞপ্তি পাওয়া, সার্ভার প্রতিক্রিয়া। মোবাইল অ্যাপ্লিকেশনে, এটি প্রায়শই ViewModel পদ্ধতি কল করা বা UI উপাদানে ক্লিক করার সাথে মিলে যায়।

Then: ফলাফল

Then ব্লক প্রত্যাশিত অবস্থা পরিবর্তন বর্ণনা করে: স্ক্রিন পরিবর্তন, API কল, ডেটাবেস আপডেট। Then-এ পরীক্ষাগুলি পরিমাপযোগ্য এবং দ্ব্যর্থহীন হতে হবে — সেগুলি এক্সিকিউটেবল কোডে assertions হয়ে ওঠে।

BDD এবং TDD: পদ্ধতির তুলনা

BDD এবং TDD প্রায়শই বিভ্রান্ত হয়, যদিও এগুলি শৃঙ্খলার বিভিন্ন স্তর। TDD কোড স্তরে একটি ডিজাইন কৌশল: “কীভাবে বাস্তবায়ন লিখবেন”। BDD প্রয়োজনীয়তা স্তরে একটি স্পেসিফিকেশন কৌশল: “সিস্টেমের কী করা উচিত”।

প্রকল্পে পরিপূরকতা

সেরা মোবাইল প্রকল্পগুলি পৃথক ক্লাস স্তরে (ডোমেন লেয়ার) TDD এবং পরিস্থিতি স্তরে (ফিচার লেয়ার) BDD ব্যবহার করে। এটি দ্বৈত কভারেজ প্রদান করে: TDD বাস্তবায়নের সঠিকতা নিশ্চিত করে, BDD প্রয়োজনীয়তা বোঝার সঠিকতা নিশ্চিত করে। Google তার অভ্যন্তরীণ অনুশীলনে Android অ্যাপ্লিকেশনের জন্য TDD এবং BDD-এর সংমিশ্রণ ব্যবহার করে, যেমন Android Testing ডকুমেন্টেশন (2024) এ বলা হয়েছে।

মোবাইল ডেভেলপমেন্টের জন্য BDD টুলস

BDD ইকোসিস্টেমে সমস্ত জনপ্রিয় মোবাইল ডেভেলপমেন্ট প্ল্যাটফর্ম এবং ভাষার জন্য ফ্রেমওয়ার্ক অন্তর্ভুক্ত রয়েছে। টুলের পছন্দ প্রযুক্তি স্ট্যাক এবং অটোমেশন স্তরের উপর নির্ভর করে।

Android-এর জন্য Cucumber

Cucumber সবচেয়ে জনপ্রিয় BDD ফ্রেমওয়ার্ক, যা Gherkin পরিস্থিতি নিয়ে কাজ করে। Android প্রকল্পগুলির জন্য, io.cucumber:cucumber-android লাইব্রেরি ব্যবহার করা হয়, যা Espresso এবং Compose Test UI টেস্টিং টুলের সাথে একীভূত হয়। Cucumber Kotlin এবং Java সমর্থন করে, যা এটি উভয় ভাষা ব্যবহার করে এমন স্টুডিওর জন্য একটি সার্বজনীন পছন্দ করে তোলে।

Xamarin-এর জন্য SpecFlow

SpecFlow .NET ইকোসিস্টেমের জন্য একটি BDD ফ্রেমওয়ার্ক, যা Xamarin.Forms এবং .NET MAUI প্রকল্পগুলিতে ব্যবহৃত হয়। SpecFlow NUnit এবং xUnit-এর সাথে একীভূত হয়, এবং এর step definitions C#-এ লেখা হয়। মোবাইল প্রকল্পগুলির জন্য, SpecFlow একটি শেয়ার্ড কোডবেসে অ্যাপ্লিকেশনের Android এবং iOS সংস্করণের মধ্যে পরিস্থিতি পুনরায় ব্যবহার করার অনুমতি দেয়।

iOS-এর জন্য Quick/Nimble

Swift-এ iOS ডেভেলপমেন্টের জন্য, BDD ফ্রেমওয়ার্ক Quick এবং Nimble বিদ্যমান। Quick describe/it শৈলীতে পরিস্থিতি বর্ণনা করার জন্য DSL প্রদান করে, এবং Nimble পাঠযোগ্য সিনট্যাক্স সহ matchers প্রদান করে। যদিও এই ফ্রেমওয়ার্কগুলি সরাসরি Gherkin ব্যবহার করে না, তারা BDD নীতি বাস্তবায়ন করে: পুরো দলের জন্য বোধগম্য ভাষায় আচরণ বর্ণনা করা।

BDD পরিস্থিতি এবং কোড উদাহরণ

আসুন একটি Android প্রকল্পে BDD-র একটি সম্পূর্ণ উদাহরণ দেখি: একটি অর্ডার চেকআউট পরিস্থিতি। প্রথমে আমরা একটি Gherkin পরিস্থিতি লিখি, তারপর Kotlin-এ step definitions।

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

Kotlin-এ Step Definitions

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-এর সাথে একীকরণ

Android প্রকল্পে BDD টেস্ট চালানোর জন্য, CucumberAndroidJUnitRunner ব্যবহার করা হয়। এটি রিসোর্সে .feature ফাইলগুলি স্ক্যান করে, রেগুলার এক্সপ্রেশন দ্বারা সংশ্লিষ্ট step definitions খুঁজে পায় এবং পরিস্থিতিগুলিকে সাধারণ ইন্সট্রুমেন্টেড টেস্ট হিসাবে executes করে। ফলাফলগুলি গ্রাহকের জন্য বোধগম্য 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 পরিস্থিতি এবং প্রোডাকশন কোডের মধ্যে ডিসিঙ্ক্রোনাইজেশন। যদি ডেভেলপাররা step definitions আপডেট না করে APIs পরিবর্তন করে, তাহলে .feature ফাইলগুলি বাস্তবায়নের সাথে মেলে না। সমাধান হল CI/CD পাইপলাইনে BDD টেস্ট চালানো এবং মার্জ অনুরোধের জন্য সবুজ অবস্থা প্রয়োজন। “BDD as a gating mechanism” অনুশীলনটি Cucumber ডকুমেন্টেশন (2024) এ বর্ণিত হয়েছে এবং শিল্পে একটি মান।

BDD টেস্ট কর্মক্ষমতা

Cucumber-এ BDD পরিস্থিতিগুলি Android ডিভাইস বা এমুলেটরে ইন্সট্রুমেন্টেড টেস্ট হিসাবে চলে। এটি JVM-এ সাধারণ ইউনিট টেস্টের থেকে 10–50 গুণ ধীর। একটি বড় Android অ্যাপ্লিকেশনের জন্য একটি একক গ্রহণযোগ্যতা টেস্ট 20–30 মিনিট সময় নিতে পারে। BDD টেস্টগুলি রাতে একটি পৃথক CI জবে চালানোর সুপারিশ করা হয়, যখন ইউনিট টেস্টগুলি প্রতিটি push-এ চলে। এই কৌশলটি প্রতিক্রিয়া গতি এবং পরিস্থিতি কভারেজের মধ্যে ভারসাম্য রাখে।

Gherkin-এ দল প্রশিক্ষণ

BDD-তে রূপান্তরের জন্য শুধু ডেভেলপার নয়, বিশ্লেষক এবং টেস্টারদেরও প্রশিক্ষণ প্রয়োজন। Gherkin একটি সহজ ভাষা, কিন্তু ভাল পরিস্থিতি লেখার জন্য অনুশীলন প্রয়োজন। শিক্ষানবিশদের সাধারণ ভুল: অত্যধিক দীর্ঘ পরিস্থিতি (10টির বেশি ধাপ), Given-When-Then মিশ্রিত করা, ব্যবসায়িক পরিস্থিতিতে প্রযুক্তিগত শব্দ ব্যবহার করা। BDD Academy (2024) অনুসারে, BDD পরিস্থিতি লেখায় পরিপক্কতা অর্জনের জন্য দলগুলির গড়ে 4–6 স্প্রিন্ট প্রয়োজন।