BDD और Gherkin

यह क्यों ज़रूरी है

Business features के कई महँगे defects coding की चूक नहीं, बल्कि गलतफ़हमी होते हैं: developer ने "200.00 या ज़्यादा" को "200.00 से ज़्यादा" पढ़ा, या किसी ने तय ही नहीं किया कि expired code के साथ क्या होगा। BDD इस लागत को जड़ से पकड़ता है। Code लिखने से पहले concrete examples पर बातचीत अलग-अलग अर्थ और छूटे हुए rules तब सामने लाती है जब उन्हें ठीक करना सस्ता है, इसलिए यह team के पास static testing के सबसे शुरुआती रूपों में से एक है।

Tester के लिए BDD काम को आगे ले आता है: build के बाद gaps ढूँढने की बजाय आप वे examples गढ़ने में हिस्सा लेते हैं जो feature को परिभाषित करते हैं, और बाद में वही scenarios acceptance tests और regression tests दोनों का काम करते हैं। Reports business की भाषा बोलती हैं, इसलिए fail हुआ scenario बताता है कि कौन-सा rule टूटा। लेकिन इसकी कीमत भी है: step definitions की एक layer जिसे maintain करना पड़ता है। जो teams बातचीत के बिना सिर्फ़ tool अपनाती हैं, वे यह कीमत चुकाती हैं और बदले में कम पाती हैं।

BDD बातचीत से शुरू होता है: three amigos

सबसे जाने-माने BDD tools में से एक, Cucumber, रोज़ के BDD काम को तीन practices के रूप में बताता है जो हर छोटे बदलाव के लिए दोहराई जाती हैं। Discovery: team नए behaviour के concrete examples पर बात करके details पर सहमत होती है। Formulation: तय हुए examples Gherkin scenarios के रूप में लिखे जाते हैं, और जिन लोगों ने उन पर सहमति दी थी वे जाँचते हैं कि wording अब भी वही कहती है जो उनका मतलब था। Automation: scenarios को code से जोड़ा जाता है ताकि वे system पर चलें, बेहतर हो कि feature बनने से पहले ही, ताकि वे development को दिशा दें। संक्षेप में: system क्या कर सकता है, क्या करना चाहिए, और असल में क्या करता है।

Discovery आम तौर पर backlog refinement के दौरान हर story की एक छोटी meeting में होती है, development शुरू होने से पहले। कई teams इसे "three amigos" कहती हैं, क्योंकि इसमें तीन नज़रिए साथ आते हैं: business (product owner या business analyst, जिनके पास problem और rules हैं), development (जो जानते हैं कि इसे कैसे बनाया जा सकता है और technically क्या मुश्किल है) और testing (जो पूछते हैं कि क्या गलत हो सकता है और कौन-से examples यह दिखाएँगे)। मायने तीन नज़रियों के हैं, लोगों की गिनती के नहीं: कोई designer या दूसरा developer भी जुड़ सकता है।

इस meeting को चलाने का एक लोकप्रिय तरीका example mapping है, जिसका वर्णन Cucumber के BDD documentation में है। रंगीन cards से table पर एक map बनता है: story के लिए पीला card, हर rule के लिए नीला card, किसी rule के नीचे उसे समझाने वाले examples के लिए हरे cards, और उन सवालों के लिए लाल cards जिनका जवाब कमरे में कोई नहीं दे सकता। Map एक नज़र में readiness दिखाता है: बहुत से लाल cards का मतलब है कि story अभी बनाने लायक नहीं, और बहुत से नीले cards का मतलब अक्सर यह कि story बहुत बड़ी है और उसे बाँटना चाहिए। Story SHOP-31, "Checkout पर discount code लागू करना", का map यह है।

• Story (पीला): SHOP-31, checkout पर discount code लागू करना।
• Rule 1 (नीला): SAVE10 200.00 SAR या उससे ज़्यादा के subtotal पर 10% छूट देता है। Examples (हरे): 250.00 → 225.00 देने होंगे; 200.00 → 180.00 देने होंगे; 199.99 → code refuse, 199.99 देने होंगे।
• Rule 2 (नीला): expired code refuse होता है। Example (हरा): code 31 March 2027 को ख़त्म हुआ और 1 April 2027 को लागू किया गया, तो message आता है "यह code expire हो चुका है"।
• Rule 3 (नीला): हर order पर एक code। Example (हरा): SAVE10 लागू हुआ, फिर WELCOME5 डाला गया; नतीजा एक लाल card पर अटका है।
• सवाल (लाल): minimum delivery fee से पहले जाँचा जाता है या बाद में? दूसरा code पहले वाले की जगह लेता है या refuse होता है? Code लागू होने के बाद customer items हटा दे और subtotal 200.00 से नीचे चला जाए तो क्या होगा?

आज़माएँ: User Story → टेस्ट सिनेरियो आज़माएँ: बाउंड्री वैल्यू जनरेटर आज़माएँ: डिसीज़न टेबल जनरेटर

Gherkin syntax: feature file के हिस्से

Gherkin वह सादी भाषा वाला format है जिसे BDD tools पढ़ते हैं। Scenarios .feature extension वाली text files में रहते हैं, और हर non-blank line एक keyword से शुरू होती है, free-text descriptions को छोड़कर। Step keywords Given, When, Then, And और But, और Examples table वाला Scenario Outline, आप acceptance criteria वाले lesson से जानते हैं। पूरी feature file इनके चारों ओर structure जोड़ती है।

जब product owner ने पहले लाल card का जवाब दिया (minimum subtotal पर लागू होता है, delivery fee से पहले), तो team ने SHOP-31 के rules 1 और 2 को नीचे वाली file में formulate किया। हर नीला card एक Rule बना और हर हरा card एक Scenario। Gherkin reference हर scenario में तीन से पाँच steps की सलाह देता है; इससे ज़्यादा होने पर example specification की तरह पढ़ा नहीं जाता।

• Feature: हर file में एक। इसका नाम और इसके नीचे का free-text description बताते हैं कि feature किस लिए है; description execute नहीं होता।
• Rule: एक business rule को समझाने वाले scenarios को group करता है, जैसे नीला card अपने हरे cards के साथ।
• Scenario, या उसका synonym Example: एक behaviour का एक concrete example।
• Background: Given steps जो file या rule के हर scenario में साझा हैं। यह हर scenario से पहले चलता है, किसी भी Before hook के बाद (Cucumber के setup hooks, जैसे दूसरे runners में beforeEach)। इसे छोटा रखें और इसमें सिर्फ़ वह context रखें जो scenarios समझने के लिए पाठक को चाहिए।
• Data table: किसी step के नीचे | pipes के बीच rows, जो उस step के code को एक argument के रूप में मिलती हैं। Doc string: दो """ lines के बीच multi-line text, जैसे email body या JSON payload के लिए।
• @smoke या @SHOP-31 जैसे tags किसी feature, rule, scenario या examples table को label करते हैं ताकि आप चुन सकें कि क्या चलाना है। Tags inherit होते हैं: feature पर लगा tag उसके हर scenario पर लागू होता है।
• Comments line की शुरुआत में # से शुरू होते हैं। पहली line पर # language: header keywords को किसी दूसरी बोली जाने वाली भाषा में बदल देता है।

# Story SHOP-31. Rules example-mapping session में तय हुए।
@checkout
Feature: Checkout पर discount codes
  Customer हर order पर एक discount code डाल सकता है।
  छूट subtotal पर लगती है, delivery fee से पहले।

  Background:
    Given ये discount codes मौजूद हैं:
      | code   | percent | min_subtotal | valid_until |
      | SAVE10 | 10      | 200.00       | 2027-03-31  |

  Rule: Code सिर्फ़ अपने minimum subtotal से लागू होता है

    Scenario: Minimum के बराबर subtotal पर छूट मिलती है
      Given Huda के cart का subtotal 200.00 SAR है
      When वह code "SAVE10" लागू करती है
      Then delivery से पहले देय राशि 180.00 SAR है

    Scenario: Minimum से ठीक नीचे वाले subtotal की कीमत वही रहती है
      Given Huda के cart का subtotal 199.99 SAR है
      When वह code "SAVE10" लागू करती है
      Then code refuse होता है और message आता है "इस code के लिए 200.00 SAR ज़रूरी है"
      And delivery से पहले देय राशि 199.99 SAR है

  Rule: Expired code refuse होता है

    @smoke
    Scenario: End date के अगले दिन इस्तेमाल किया गया code
      Given आज 1 April 2027 है
      And Huda के cart का subtotal 250.00 SAR है
      When वह code "SAVE10" लागू करती है
      Then code refuse होता है और message आता है "यह code expire हो चुका है"

भाग 1:1@checkout
भाग 2:2Feature: Discount codes at checkout
भाग 3:3  A customer can enter one discount code per order.

भाग 4:4  Background:
    Given these discount codes exist:
भाग 5:5      | code   | percent | min_subtotal | valid_until |
      | SAVE10 | 10      | 200.00       | 2027-03-31  |

भाग 6:6  Rule: A code applies only from its minimum subtotal

भाग 7:7    Scenario: A subtotal at the minimum gets the discount
भाग 8:8      Given Huda has a cart with a subtotal of 200.00 SAR
भाग 9:9      When she applies the code "SAVE10"
भाग 10:10      Then the amount to pay before delivery is 180.00 SAR

आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर

अच्छे और कमज़ोर scenarios

BDD में सबसे आम चूक ऐसी feature file है जो असल में test script है: हर click, field और URL Given/When/Then में लिखा हुआ। यह imperative style हर redesign के साथ टूटती है और rule को UI details के नीचे दबा देती है। Declarative style business की भाषा में बताती है कि क्या होता है, और कैसे होता है यह automation code पर छोड़ देती है। एक ही example के दो versions की तुलना करें।

पहले version में कुछ नहीं बताता कि 180.00 सही जवाब क्यों है: 200.00 SAR का subtotal, वह अकेला fact जिस पर rule निर्भर है, एक book की कीमत में छिपा है। इसका आख़िरी step एक database table check करता है जिसे कोई stakeholder नहीं देख सकता, और इसके steps कई actions को एक ही step में जोड़ते हैं ("टाइप करके ... click करता हूँ"), इसलिए उन्हें reuse नहीं किया जा सकता। दूसरा version product owner पढ़कर मंज़ूर कर सकता है, और checkout page के redesign के बाद भी यह बिना बदले बना रहता है।

• हर scenario में एक behaviour, और ऐसा title जो उसे बताए: "Minimum से ठीक नीचे वाले subtotal की कीमत वही रहती है", "Discount test 2" नहीं।
• Business शब्दों में declarative steps; clicks की जगह step definitions और page objects में है।
• सिर्फ़ वह data जो result बदलता है। Scenario की हर value rule के लिए मायने रखे, और जिस चीज़ पर rule निर्भर है वह छिपी न हो।
• हर Then में ऐसा outcome जिसे user या stakeholder देख सके, और इतना specific कि fail हो सके: "मुझे 180.00 दिखना चाहिए" यह नहीं बताता कि कहाँ।
• Independent और repeatable scenarios: हर scenario अपना context ख़ुद तैयार करता है और किसी भी क्रम में, किसी भी दिन, अकेले pass या fail होता है। Rule 1 के scenarios में कोई date नहीं है, इसलिए उनके automation को shop की clock एक तय date पर रखनी होगी, जैसे किसी Before hook में; वरना जिस दिन SAVE10 expire होगा, उसी दिन से वे fail होने लगेंगे।
• पूरे project में एक idea के लिए एक phrase, जैसे हर जगह "subtotal", न कि एक file में "cart total" और दूसरी में "basket amount", ताकि steps वही definitions reuse करें।

# Imperative: scenario के कपड़ों में test script
Scenario: Discount test 2
  Given मैं "https://shop.example/login" खोलता हूँ
  And मैं "email" में "huda@example.com" टाइप करके "Sign in" click करता हूँ
  And मैं "Desert Stars" के बगल में "Add to cart" click करता हूँ
  And मैं "Checkout" click करता हूँ
  When मैं "code" में "SAVE10" टाइप करके "Apply" click करता हूँ
  Then मुझे "180.00" दिखना चाहिए
  And discounts table में इस order की row है

# Declarative: business की भाषा में एक behaviour
Scenario: Minimum के बराबर subtotal पर छूट मिलती है
  Given Huda के cart का subtotal 200.00 SAR है
  When वह code "SAVE10" लागू करती है
  Then delivery से पहले देय राशि 180.00 SAR है

Scenarios automation से कैसे जुड़ते हैं

Cucumber जैसा BDD runner feature files पढ़ता है और हर step के लिए एक step definition ढूँढता है: एक function जो ऐसे pattern के साथ register होता है जिससे step text का match होना ज़रूरी है। Pattern आम तौर पर Cucumber Expression होता है, जिसमें {int}, {float}, {word} और {string} जैसे parameters text से values पकड़कर function को arguments के रूप में देते हैं; regular expressions भी काम करते हैं। Keyword match का हिस्सा नहीं है: एक ही text वाले Given और Then step एक ही definition को call करते हैं, इसलिए एक ही text दो जगह दो अलग मतलब नहीं रख सकता।

Step definitions glue code हैं और इन्हें पतला रहना चाहिए। ये business step को उस automation layer की calls में बदलती हैं जिसे आपने page object model और test automation architecture वाले lessons में देखा: API client किसी Given के लिए data तैयार करता है, page object When को user की तरह perform करता है, और Then result पढ़कर वह assertion करता है जो actual outcome को expected से मिलाता है। जो values एक step बाद वाले step के लिए बनाता है, जैसे Given का बनाया cart, वे एक context object में रखी जाती हैं। Cucumber for JavaScript में यह World है, जो step function के अंदर this के रूप में मिलता है (इसलिए steps function से लिखे जाते हैं, arrow functions से नहीं, क्योंकि उनका अपना this नहीं होता) और हर scenario के लिए नया बनता है, जिससे scenarios independent रहते हैं; API client और page objects भी आम तौर पर यहीं बनाए जाते हैं, ताकि हर step उन तक पहुँच सके।

हर step एक status के साथ ख़त्म होता है: passed, failed, skipped (failed, pending या undefined step के बाद वाले steps नहीं चलते), pending (definition अभी अधूरी है), undefined (कोई definition match नहीं करती; Cucumber शुरुआत के लिए code snippet print करता है) या ambiguous (एक से ज़्यादा definitions match करती हैं)। Report scenarios और steps को feature file के शब्दों में दिखाती है, इसलिए fail हुआ Then step उस rule का नाम बताता है जो टूटा। Tags तय करते हैं कि क्या चलेगा, जैसे pipeline में npx cucumber-js --tags "@smoke and not @wip"।

import { Given, When, Then } from "@cucumber/cucumber";
import assert from "node:assert/strict";

// Background step से match करता है; data table आख़िरी argument बनकर आती है
Given("ये discount codes मौजूद हैं:", async function (table) {
  for (const row of table.hashes()) await this.api.createCode(row);
});

// Match करता है: Given Huda के cart का subtotal 200.00 SAR है
Given("{word} के cart का subtotal {float} SAR है",
  async function (customer, subtotal) {
    this.cart = await this.api.createCart(customer, subtotal);
  });

// Match करता है: When वह code "SAVE10" लागू करती है
When("वह code {string} लागू करती है", async function (code) {
  await this.checkout.open(this.cart);
  await this.checkout.applyCode(code);
});

// दोनों को match करता है: Then delivery से पहले देय राशि ... और And ...
Then("delivery से पहले देय राशि {float} SAR है",
  async function (expected) {
    assert.equal(await this.checkout.amountBeforeDelivery(), expected);
  });

Then("code refuse होता है और message आता है {string}",
  async function (message) {
    assert.equal(await this.checkout.codeMessage(), message);
  });

आज़माएँ: Regex टेस्टर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Gherkin Reference — CucumberCucumberexecutable specifications के लिए Gherkin सिंटैक्स: Feature, Rule, Scenario, Given/When/Then steps, Background, Scenario Outline और Examples।
• Behaviour-Driven Development — CucumberCucumberBehaviour-Driven Development तीन अभ्यासों के रूप में — discovery, formulation और automation — जो business और technical लोगों द्वारा तय ठोस उदाहरणों पर आधारित हैं।
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।