آموزش نوشتن سناریو Gherkin در BDD با مثال فارسی

یک فایل .feature می‌تواند کاملاً سبز باشد و باز هم نیاز کسب‌وکار را اشتباه توصیف کند. اگر تیم قبل از نوشتن سناریو درباره قانون، مثال مرزی و پرسش‌های باز گفت‌وگو نکرده باشد، Given/When/Then فقط ابهام را در قالبی مرتب پنهان می‌کند. ارزش Gherkin نه در انگلیسی‌بودن کلمات کلیدی و نه در تعداد Scenarioها، بلکه در ساختن مثال‌های دقیق، قابل گفت‌وگو و قابل بررسی است.

در این راهنما یاد می‌گیرید چگونه از یک Rule کسب‌وکار به سناریوی Gherkin برسید، Given/When/Then را بدون جزئیات UI بنویسید، برای مرزها از Scenario Outline استفاده کنید، گرکین فارسی را راه بیندازید و تنها سناریوهایی را خودکار کنید که واقعاً ارزش مستندات اجرایی دارند. مثال اصلی درباره تخفیف و پرداخت ریالی در یک فروشگاه ایرانی است.

خلاصه اجرایی: سناریوی خوب چه شکلی است؟

از یک قانون کسب‌وکار و یک مثال عینی می‌آید، نه از صفحه و دکمه؛
برای یک مخاطب، زمینه و نتیجه قابل مشاهده نوشته می‌شود؛
Given وضعیت مرتبط، When رویداد و Then پیامد قابل مشاهده را بیان می‌کند؛
با تغییر UI یا معماری، تا وقتی رفتار ثابت است نیاز به بازنویسی ندارد؛
مرزها و استثناها را روشن می‌کند، اما جای همه تست‌های فنی را نمی‌گیرد؛
مستقل، قطعی، کوتاه و دارای Oracle روشن است؛
پیش از Automation توسط کسب‌وکار، توسعه و تست بازبینی می‌شود؛
اگر دیگر ارزش یا رفتار فعلی را نمایندگی نمی‌کند، اصلاح یا حذف می‌شود.

BDD، Gherkin و Cucumber یکی نیستند

Behavior-Driven Development شیوه‌ای برای همکاری مستمر حول مثال‌های واقعی است. Gherkin نحو ساختاریافته‌ای است که مثال‌های توافق‌شده را برای انسان و ابزار خوانا می‌کند. Cucumber یکی از ابزارهایی است که سند Gherkin را به Step Definition و کد اجرایی وصل می‌کند. استفاده از Cucumber به‌تنهایی به‌معنای انجام BDD نیست.

مستندات رسمی Cucumber درباره BDD فعالیت روزمره را در سه عمل تکرارشونده صورت‌بندی می‌کند:

Discovery: با مثال‌ها مسئله، Ruleها، مرزها و پرسش‌های باز را کشف کنید؛
Formulation: مثال‌های منتخب را به سند دقیق و قابل خودکارسازی تبدیل کنید؛
Automation: رفتار توافق‌شده را پیاده‌سازی و به‌طور خودکار بررسی کنید.

موضوع این مقاله مرحله Formulation است. برای مسیر کامل نصب، Step Definition، World، Hook و اجرای CI به راهنمای BDD با Cucumber و Gherkin مراجعه کنید؛ برای ساختار کد و Glue نیز مقاله بهترین شیوه‌های Cucumber مکمل این صفحه است.

Gherkin معیار پذیرش را خلق نمی‌کند

تبدیل جمله مبهم «تخفیف درست اعمال شود» به Then تخفیف درست است هیچ ابهامی را حل نمی‌کند. ابتدا باید معلوم شود «درست» یعنی چه: درصد روی کدام مبلغ، پیش یا پس از هزینه ارسال، با چه سقفی، در چه زمانی، با چه گردکردنی و در تعارض با کدام کمپین. Syntax ظرف گفت‌وگو است؛ جای گفت‌وگو را نمی‌گیرد.

قبل از Gherkin با Example Mapping شروع کنید

در Example Mapping رسمی Cucumber، یک Story با چهار نوع کارت بررسی می‌شود:

Story: نتیجه یا قابلیت مورد نظر؛
Rules: محدودیت‌ها و معیارهای پذیرش توافق‌شده؛
Examples: نمونه‌های عینی که Rule را توضیح یا به چالش می‌کشند؛
Questions: ابهام‌ها و فرض‌هایی که هنوز پاسخ ندارند.

جلسه Discovery دادگاه تأیید Story نیست؛ محل پیدا کردن سوءبرداشت است. برای هر Rule دست‌کم یک مثال معمول، یک مرز مهم و یک مثال ردشونده بررسی کنید. اگر پرسش قرمزِ اثرگذار بی‌پاسخ ماند، سناریو را با یک حدس پنهان نهایی نکنید. مالک پاسخ و زمان بازگشت را ثبت کنید.

چه کسانی در جلسه باشند؟

Three Amigos معمولاً سه دیدگاه را نمایندگی می‌کند: محصول/دامنه می‌پرسد چه ارزشی لازم است؛ توسعه محدودیت و مسیرهای فنی را می‌بیند؛ تست مثال مخالف، مرز و مشاهده‌پذیری را به چالش می‌کشد. این نام به سه نفر ثابت محدود نیست. راهنمای نقش‌ها در BDD نیز بر همکاری نقش‌ها و بازبینی فعال نماینده کسب‌وکار تأکید دارد. امنیت، عملیات، حقوقی یا پشتیبانی را هرجا Rule به آن‌ها مربوط است اضافه کنید.

خروجی Discovery باید چه باشد؟

واژه‌نامه کوچک دامنه؛ مثلاً «مبلغ کالا»، «مبلغ قابل پرداخت» و «سقف تخفیف»؛
Ruleهای مستقل و اولویت آن‌ها؛
مثال‌های عینی با عدد، نقش و زمان؛
پرسش‌ها، فرض‌ها و تصمیم‌های خارج از دامنه؛
ریسک‌هایی که به تست دیگری غیر از Gherkin نیاز دارند.

برای شکستن منطق پیچیده چندشرطی، گراف علت و معلول و جدول تصمیم می‌تواند پیش از انتخاب مثال‌ها کمک کند. برای اینکه مثال‌های بیشتر را روی ریسک درست خرج کنید نیز از تست مبتنی بر ریسک استفاده کنید.

ساختار Gherkin از Feature تا Scenario

مرجع رسمی Gherkin کلمات کلیدی اصلی Feature، Rule، Scenario/Example، Given، When، Then، Background، Scenario Outline و Examples را تعریف می‌کند. Data Table، Doc String، Tag و Comment نیز سازه‌های مکمل‌اند.

Feature: قابلیت و ارزش آن

هر فایل یک Feature دارد. عنوان باید توانمندی دامنه را بگوید، نه نام Ticket یا Component. توضیح آزاد زیر Feature می‌تواند هدف، مخاطب و مرز را بیان کند. قالب «برایِ… می‌خواهیم… تا…» اجباری نیست؛ وضوح مهم‌تر از پرکردن Template است.

Rule: قانون کسب‌وکار

Rule از Gherkin ۶ برای گروه‌کردن مثال‌های یک قانون در دسترس است. نام Rule را گزاره‌ای بنویسید که بتوان درباره درستی آن بحث کرد: «تخفیف درصدی از سقف ریالی عبور نمی‌کند». عنوان‌هایی مانند «تست مثبت» و «سناریوهای تخفیف» قانون را آشکار نمی‌کنند.

Scenario یا Example: یک نمونه عینی از Rule

Scenario داستانی کامل از یک رفتار است. عنوان باید نتیجه متمایز را نشان دهد: «سقف تخفیف برای سفارش بزرگ اعمال می‌شود»، نه «تست تخفیف ۱». سناریو یک Test Script قدم‌به‌قدم UI نیست و لازم نیست همه مسیر دستی کاربر را بازگو کند.

Given، When و Then را معنایی بنویسید

Given: فقط زمینه اثرگذار

Given وضعیت پیش از رویداد را می‌سازد: نقش، حالت سفارش یا Rule فعال. اقدام اصلی را در Given پنهان نکنید. جزئیاتی را که بر نتیجه اثر ندارند حذف کنید؛ نام مرورگر، Selector و روش درج رکورد جزو پیاده‌سازی Step Definition است.

When: یک رویداد محرک روشن

When کنش کاربر یا رویداد سیستم است. یک When غالب، علیت را خواناتر می‌کند. اگر سناریو چند زنجیره «وقتی… سپس… وقتی… سپس…» دارد، احتمالاً چند رفتار یا یک Workflow طولانی را در یک Example جمع کرده‌اید.

Then: خروجی قابل مشاهده، نه جزئیات داخل سیستم

Then باید نتیجه‌ای را بیان کند که کاربر یا سامانه بیرونی می‌تواند مشاهده کند: مبلغ قابل پرداخت، وضعیت سفارش، پیام دامنه یا رویداد قراردادی. مرجع Gherkin توصیه می‌کند نتیجه را مستقیماً از دیتابیس بررسی نکنید؛ «ستون discount_amount برابر ۴۰۰۰۰۰ است» به ساختار داخلی می‌چسبد. Step Definition باید Actual را از خروجی معتبر بگیرد و Assertion واقعی اجرا کند.

And و But: خوانایی، نه رفتار تازه پنهان

And و But ادامه معنای آخرین Given/When/Then هستند. زیادشدن And نشانه قطعی خطا نیست، اما از خود بپرسید آیا زمینه اضافه، نتیجه مستقل یا Rule دوم وارد سناریو شده است. کلمات کلیدی در تطبیق Step Definition معنای جداگانه نمی‌سازند؛ متن Step باید به‌اندازه کافی مشخص باشد.

قبل و بعد: از اسکریپت UI به مثال کسب‌وکار

راهنمای رسمی نوشتن Gherkin بهتر یک پرسش مفید پیشنهاد می‌کند: آیا با تغییر پیاده‌سازی، این عبارت هم باید تغییر کند؟ مقایسه زیر تفاوت را نشان می‌دهد.

نسخه شکننده

Scenario: اعمال تخفیف
  Given کاربر در صفحه cart.html است
  When مقدار OFF20 را در input با شناسه coupon وارد می‌کند
  And روی دکمه آبی «اعمال» کلیک می‌کند
  Then متن عنصر discount باید «۴۰۰٬۰۰۰» باشد
  And رکوردی در جدول cart_discounts ساخته شود

این سناریو به HTML، رنگ، Selector و دیتابیس وابسته است، اما معلوم نمی‌کند چرا تخفیف ۴۰۰ هزار ریال است.

نسخه رفتارمحور

Feature: تخفیف درصدی سفارش

  Rule: تخفیف ۲۰ درصدی حداکثر ۴۰۰٬۰۰۰ ریال است

    Scenario: سقف تخفیف برای سفارش بزرگ اعمال می‌شود
      Given مبلغ کالاهای سفارش ۳٬۰۰۰٬۰۰۰ ریال است
      And کد OFF20 معتبر است
      When مشتری کد OFF20 را برای سفارش اعمال می‌کند
      Then تخفیف سفارش ۴۰۰٬۰۰۰ ریال است
      And مبلغ کالاها پس از تخفیف ۲٬۶۰۰٬۰۰۰ ریال است

نسخه دوم Rule، داده و Oracle را آشکار می‌کند. Step Definition می‌تواند آن را از API، Service یا UI اجرا کند؛ انتخاب سطح تست در Feature قفل نشده است.

مثال‌ها را عینی، متمایز و کمینه انتخاب کنید

طبق راهنمای رسمی Examples در BDD، مثال خوب به‌جای عبارت انتزاعی از نام، تاریخ و مبلغ مرتبط استفاده می‌کند و جزئیات فنی را وارد نمی‌کند. «یک سفارش بزرگ» کمتر از «سفارش ۳٬۰۰۰٬۰۰۰ ریالی» درباره Rule سقف تخفیف اطلاعات می‌دهد.

هر Scenario باید چه چیزی را تغییر دهد؟

یک Rule جدید را نشان دهد؛
مرز Rule را مشخص کند؛
استثنا یا تقدم دو Rule را آشکار کند؛
یک سوءبرداشت محتمل را رد کند؛
ریسک مهم برای ذی‌نفع را قابل مشاهده کند.

اگر سناریوی جدید فقط عددی تصادفی را عوض می‌کند و هیچ دانشی اضافه نمی‌کند، احتمالاً جای آن در تست پارامتریِ سطح پایین‌تر است. Gherkin کاتالوگ همه ترکیب‌های داده نیست.

مثال مخالف و مرزی را فراموش نکنید

Rule: کد تا پایان ۳۱ مرداد به وقت تهران معتبر است

  Scenario: کد در آخرین لحظه بازه معتبر پذیرفته می‌شود
    Given زمان جاری ۱۴۰۵/۰۵/۳۱ ساعت ۲۳:۵۹:۵۹ به وقت تهران است
    And کد TABESTAN تا پایان ۳۱ مرداد معتبر است
    When مشتری کد را اعمال می‌کند
    Then تخفیف سفارش محاسبه می‌شود

  Scenario: کد پس از پایان بازه رد می‌شود
    Given زمان جاری ۱۴۰۵/۰۶/۰۱ ساعت ۰۰:۰۰:۰۰ به وقت تهران است
    And کد TABESTAN تا پایان ۳۱ مرداد معتبر است
    When مشتری کد را اعمال می‌کند
    Then کد منقضی اعلام می‌شود
    And مبلغ سفارش تغییر نمی‌کند

زمان را به Clock قابل کنترل تزریق کنید؛ سناریویی که به ساعت واقعی یا «امروز» وابسته است قطعی نمی‌ماند. درباره تقویم جلالی/میلادی، منطقه زمانی، ارقام فارسی/لاتین و واحد ریال/تومان در Discovery تصمیم صریح بگیرید.

Scenario Outline، Data Table و Doc String را درست انتخاب کنید

Scenario Outline: همان رفتار با چند مثال معنادار

هر ردیف Examples یک اجرای مستقل از Template است. ستون‌ها را با واژگان دامنه نام‌گذاری و فقط ردیف‌هایی را نگه دارید که کلاس یا مرز متفاوتی را نمایندگی می‌کنند:

Scenario Outline: تخفیف ۲۰ درصدی با سقف ۴۰۰٬۰۰۰ ریال
  Given مبلغ کالاهای سفارش <مبلغ_کالا> ریال است
  And کد OFF20 معتبر است
  When مشتری کد را اعمال می‌کند
  Then تخفیف سفارش <تخفیف> ریال است
  And مبلغ کالاها پس از تخفیف <قابل_پرداخت> ریال است

  Examples:
    | مبلغ_کالا | تخفیف  | قابل_پرداخت | دلیل نمونه       |
    | ۱٬۰۰۰٬۰۰۰ | ۲۰۰٬۰۰۰ | ۸۰۰٬۰۰۰     | پایین‌تر از سقف  |
    | ۲٬۰۰۰٬۰۰۰ | ۴۰۰٬۰۰۰ | ۱٬۶۰۰٬۰۰۰   | دقیقاً روی سقف   |
    | ۳٬۰۰۰٬۰۰۰ | ۴۰۰٬۰۰۰ | ۲٬۶۰۰٬۰۰۰   | بالاتر از سقف    |

ستون «دلیل نمونه» لازم نیست وارد Step شود؛ برای خواننده توضیح می‌دهد هر ردیف چه دانشی دارد. اگر جدول ده‌ها ردیف دارد، مثال‌های نماینده را در Feature نگه دارید و پوشش داده‌ای گسترده را به تست کدنویسی‌شده منتقل کنید.

Data Table: یک مجموعه داده در یک Step

Data Table ورودی ساختاریافته یک Step است، نه جایگزین Examples. مثلاً برای سبدی با چند قلم که مجموع آن رفتار را تعیین می‌کند:

Given سفارش شامل کالاهای زیر است
  | کالا      | تعداد | مبلغ واحد ریال |
  | کتاب تست | ۲     | ۷۵۰٬۰۰۰        |
  | اشتراک    | ۱     | ۵۰۰٬۰۰۰        |

Doc String: متن چندخطیِ بخشی از رفتار

برای Payload، پیام یا سند چندخطی از Doc String استفاده کنید؛ فقط وقتی خود محتوا برای Rule مهم است. JSON بزرگ و پرجزئیات، Schema فنی یا Fixture کامل را داخل Feature نریزید. آن‌ها خواننده کسب‌وکار را از رفتار اصلی دور و سند را شکننده می‌کنند.

Background، Rule و Tag را به محل انبار تبدیل نکنید

Background کوتاه و قابل یادآوری

Background پیش از هر Scenario اجرا می‌شود و برای زمینه کسب‌وکاری مشترک است. مستندات Gherkin توصیه می‌کند آن را کوتاه نگه دارید؛ اگر بیش از حدود چهار خط است یا با اسکرول از دید خارج می‌شود، جزئیات کم‌اهمیت را در Step سطح بالاتر پنهان یا Feature را تقسیم کنید. Setup فنی مانند راه‌اندازی مرورگر یا پاک‌سازی داده در Hook/Fixture است، نه Background.

Rule به‌جای فایل‌های «positive» و «negative»

سناریوها را بر اساس Rule سازمان دهید، نه نتیجه Pass/Fail یا لایه فنی. مثال پذیرفته و ردشده هر دو یک قانون را توضیح می‌دهند و کنار هم خواناترند.

Tag برای انتخاب اجرا و سازمان‌دهی

Tagها می‌توانند Feature، Rule، Scenario، Outline یا مجموعه Examples را برچسب بزنند و برای انتخاب Suite یا Hook شرطی به کار روند؛ روی Step و Background قرار نمی‌گیرند. از Tagهای پایدار مانند @billing یا @smoke استفاده کنید. جنگل @run-this، @ignore و شناسه‌های بی‌مالک معمولاً ضعف سیاست اجرا را پنهان می‌کند. جزئیات رسمی در Cucumber API، Hooks و Tags آمده است.

نوشتن Gherkin فارسی

Gherkin برای فارسی محلی‌سازی شده است. فهرست رسمی زبان‌های Gherkin برای کد fa کلیدواژه‌هایی مانند «ویژگی/قابلیت»، «قانون»، «سناریو/مثال»، «با فرض»، «هنگامی»، «آنگاه» و «نمونه‌ها» را نشان می‌دهد. هدر زبان باید نخستین خط فایل باشد:

# language: fa
قابلیت: تخفیف سفارش

  قانون: تخفیف از سقف مجاز بیشتر نمی‌شود

    سناریو: سفارش بزرگ به سقف تخفیف می‌رسد
      با فرض مبلغ کالاهای سفارش ۳٬۰۰۰٬۰۰۰ ریال است
      و کد OFF20 معتبر است
      وقتی مشتری کد را اعمال می‌کند
      آنگاه تخفیف سفارش ۴۰۰٬۰۰۰ ریال است

فارسی کامل یا کلیدواژه انگلیسی؟

زبان Domain باید برای متخصصان آن قابل فهم باشد. اگر افزونه IDE، Formatter یا Runner تیم از RTL/Locale به‌خوبی پشتیبانی می‌کند، کلیدواژه فارسی طبیعی است. اگر ابزار زنجیره محدودیت دارد، کلیدواژه انگلیسی با جمله‌های فارسی یک مصالحه عملی است. این انتخاب را در Repository یکدست کنید؛ ترجمه رفت‌وبرگشتی واژه‌های دامنه معمولاً ابهام می‌سازد.

قرارداد Unicode و عدد را روشن کنید

Encoding فایل‌ها UTF-۸ باشد؛
ی/ک فارسی و عربی Normalize شوند، اما تفاوت مورد نیاز محصول پنهان نشود؛
ارقام فارسی و لاتین در Parser و Step Parameter آزموده شوند؛
جداکننده هزارگان جزو متن است یا پیش از تبدیل پاک می‌شود؛
ریال و تومان هرگز با نام عمومی «مبلغ» مبادله نشوند؛
تاریخ جلالی، میلادی و منطقه زمانی صریح باشند؛
فاصله، نیم‌فاصله و جهت متن در Review و Diff قابل مشاهده باشند.

این قرارداد فقط مسئله تست نیست؛ رفتار محصول برای کاربر ایرانی است. مثال‌ها باید تفاوت‌هایی را ثبت کنند که نتیجه کسب‌وکار را عوض می‌کنند، نه هر Variation تایپی ممکن را.

از Scenario تا Automation بدون آلوده‌کردن زبان دامنه

Step Definition آداپتوری میان عبارت دامنه و Driverهای تست است. Cucumber در مرجع Step Definition توضیح می‌دهد که متن پس از کلیدواژه با Expression یا Regular Expression به متد وصل می‌شود. Step باید نازک بماند: پارامتر را تبدیل کند، Driver/Domain Helper را صدا بزند و نتیجه را Assert کند؛ منطق کسب‌وکار را دوباره در تست پیاده نکند.

Stepها را با واژگان دامنه بازاستفاده کنید

دو افراط رایج‌اند: Step اختصاصی برای هر Scenario که Glue را تکثیر می‌کند؛ یا Regex فوق‌عمومی که هر جمله‌ای را می‌بلعد و ابهام تطبیق می‌سازد. عبارت‌هایی مانند «مبلغ کالاهای سفارش {money} ریال است» یک مفهوم دامنه مشخص دارند. پارامتر سفارشی Money می‌تواند جداکننده و ارقام را تبدیل و واحد را حفظ کند.

Scenarioها مستقل و قطعی باشند

ترتیب اجرا نتیجه را عوض نکند؛
State بین Scenarioها به اشتراک گذاشته نشود؛
زمان، شناسه، داده و وابستگی کنترل‌پذیر باشند؛
داده هر اجرا یکتا یا پاک‌سازی آن Idempotent باشد؛
Retry به‌عنوان درمان Flake استفاده نشود؛
خطا نام Rule، Example و شاهد تشخیصی را نشان دهد.

همه Scenarioها را از UI اجرا نکنید

رفتار پذیرش می‌تواند از مرز Service یا API سریع‌تر و پایدارتر بررسی شود. فقط مثال‌هایی را از UI اجرا کنید که خود تعامل، دسترس‌پذیری یا اتصال واقعی لایه‌ها بخشی از ریسک است. راهنمای هرم تست در عمل انتخاب سطح را توضیح می‌دهد. Gherkin نیز جای تست واحد، Contract، Property-based، امنیت، کارایی یا اکتشافی را نمی‌گیرد.

مستندات زنده فقط با انضباط زنده می‌مانند

Feature File صرفاً چون در Repository است «Living Documentation» نیست. این عنوان زمانی معتبر است که:

مثال‌ها از گفت‌وگوی واقعی و Ruleهای فعلی آمده باشند؛
مثال‌های منتخب خودکار و در CI اجرا شوند؛
نتیجه اجرا با Build و زمان مشخص منتشر شود؛
Flake، Undefined و Pending پنهان یا بی‌نهایت Quarantine نشوند؛
تغییر Rule هم‌زمان سند و Automation را تغییر دهد؛
سناریوی منسوخ حذف شود، نه اینکه برای تاریخچه نگه داشته شود؛
نماینده دامنه بتواند متن را بخواند و دوره‌ای بازبینی کند.

در Pipeline، مرحله Parse/Lint را سریع اجرا کنید، سپس Scenarioهای Domain در سطح مناسب و در نهایت تعداد محدودی مسیر End-to-End. راهنمای ساخت CI/CD با تست خودکار الگوی پیاده‌سازی را شرح می‌دهد. گزارش سبز بدون پیوند به Commit، Environment و Dataset شاهد قابل اتکایی نیست.

چه زمانی Gherkin انتخاب بدی است؟

تست یک تابع فنی کوچک که فقط توسعه‌دهنده آن را می‌خواند؛
هزاران ترکیب عددی که Property-based Testing بهتر پوشش می‌دهد؛
آزمون کارایی یا امنیت با مدل و ابزار تخصصی؛
جزئیات پیاده‌سازی، Schema یا الگوریتم داخلی؛
چک‌های موقت مهاجرت که ارزش مستندات بلندمدت ندارند؛
موقعیتی که هیچ گفت‌وگوی دامنه‌ای رخ نمی‌دهد و فقط لایه متن روی تست موجود اضافه می‌شود.

اتوماسیون خوب لزوماً Gherkin نیست. برای تعیین ارزش و هزینه نگهداری، راهنمای شروع تست خودکار را بخوانید.

فرایند بازبینی سناریو قبل از Merge

بازبینی دامنه

Feature مسئله و ارزش را روشن می‌کند؟
هر Rule یک گزاره واقعی و مورد توافق است؟
Exampleها معمول، مرزی و مخالفِ لازم را نشان می‌دهند؟
عدد، تاریخ، واحد و نقش واقعی و بدون ابهام‌اند؟
پرسش باز مهمی به‌اشتباه به فرض تبدیل نشده است؟

بازبینی Formulation

Scenario یک رفتار متمایز دارد؟
Given فقط زمینه مرتبط، When رویداد و Then خروجی قابل مشاهده است؟
با تغییر UI، متن دامنه ثابت می‌ماند؟
Background کوتاه و عنوان‌ها گویا هستند؟
Outline فقط مثال‌های معنادار دارد؟

بازبینی Automation

Step Undefined یا Ambiguous نیست و Expression بیش از حد عمومی ندارد؟
هر Scenario مستقل، قطعی و قابل تکرار است؟
سطح اجرا با ریسک متناسب است یا بی‌دلیل UI انتخاب شده؟
Then Assertion واقعی و پیام خطای تشخیصی دارد؟
هیچ Secret، داده شخصی یا Credential در Feature/Report نیست؟

مالکیت این کیفیت مشترک است. نماینده کسب‌وکار معنای Rule، توسعه قابلیت پیاده‌سازی و تست قدرت مثال/Oracle را بررسی می‌کنند. برای مدل همکاری گسترده‌تر، مقاله کیفیت به‌عنوان مسئولیت مشترک را ببینید.

معیارهای سلامت BDD و Gherkin

تعداد Feature، Scenario یا Step معیار کیفیت نیست. افزایش این اعداد حتی می‌تواند نشانه تورم Suite باشد. یک Pilot چهار تا شش‌هفته‌ای را با خط پایه مقایسه کنید:

پرسش‌های مهمی که پیش از Development کشف و بسته شدند؛
Ruleهایی که Example مخالف باعث اصلاح آن‌ها شد؛
درصد Scenarioهای بازبینی‌شده توسط نماینده دامنه؛
زمان چرخه از Discovery تا Feedback؛
نرخ Flake، Undefined، Pending و Ambiguous Step؛
زمان و هزینه نگهداری پس از تغییر رفتار یا UI؛
نقص‌های پذیرش گریخته و Ruleهای فاقد Example؛
سناریوهای حذف‌شده به‌دلیل تکرار یا ارزش پایین.

برداشت علی محتاطانه باشد: کاهش دوباره‌کاری می‌تواند از تیم باتجربه‌تر، کوچک‌شدن Story یا تغییر محصول آمده باشد. روند را برای همان تیم و نوع کار دنبال کنید و Guardrailهایی مانند مدت جلسه و زمان Suite را کنار نتیجه بسنجید.

برنامه ۳۰روزه بهبود سناریوهای Gherkin

هفته اول: یک Story و یک واژه‌نامه

یک Story با Rule واقعی و ریسک متوسط انتخاب کنید؛
واژه‌های مبهم، واحدها و زمان را تعریف کنید؛
یک Example Mapping کوتاه با نقش‌های لازم برگزار کنید.

هفته دوم: Formulation و Review

برای هر Rule مثال معمول، مرزی یا مخالف منتخب بنویسید؛
UI و دیتابیس را از متن Feature حذف کنید؛
نماینده کسب‌وکار متن را بدون دیدن کد بازخوانی کند.

هفته سوم: Automation در سطح درست

Stepهای نازک و Driverهای دامنه بسازید؛
زمان و داده را کنترل و اجرای ترتیبی/تصادفی را مقایسه کنید؛
تا حد ممکن Service/API و فقط برای ریسک لازم UI را به‌کار ببرید.

هفته چهارم: CI و Retrospective

Parse/Lint و Suite سریع را در Pull Request اجرا کنید؛
گزارش را به Commit، Build و Environment وصل کنید؛
یک Scenario کم‌ارزش را حذف و یک پرسش زودکشف‌شده را ثبت کنید.

ضدالگوهای رایج سناریوهای Gherkin

نوشتن Feature پس از پایان کدنویسی فقط برای «پوشش»؛
تبدیل تست دستی کلیک‌محور به Given/When/Then؛
Ruleهای مبهم با عنوان Positive/Negative؛
Thenهایی مانند «نتیجه درست است» بدون Oracle؛
بررسی مستقیم دیتابیس برای پیامدی که باید بیرونی باشد؛
Background طولانی و Hooks پنهانیِ اثرگذار بر معنا؛
Outline با ده‌ها ردیف بدون دلیل نمونه؛
یک Scenario با چند When و چند رفتار مستقل؛
Stepهای بسیار جزئی یا Regexهای بیش از حد عمومی؛
اجرای همه چیز از مرورگر و Retry کردن Flake؛
وابستگی سناریوها به ترتیب، ساعت واقعی یا داده مشترک؛
قرار دادن رمز، کد ملی یا داده تولید در Feature و Report؛
برابرگرفتن سبزی Cucumber با درستی نیاز؛
نگهداری سناریوی منسوخ به نام مستندات زنده.

چک‌لیست نهایی سناریوی Gherkin

Rule پیش از Scenario در گفت‌وگو کشف شده است.
مثال با نقش، عدد، زمان و واحد لازم عینی است.
عنوان نتیجه متمایز را می‌گوید.
Given وضعیت، When رویداد و Then خروجی قابل مشاهده است.
متن از UI، Selector، جدول و نام کلاس مستقل است.
مثال جدید دانشی فراتر از مثال‌های موجود اضافه می‌کند.
مرز، استثنا و تقدم Ruleها به‌اندازه ریسک پوشش دارند.
Background کوتاه و Scenario مستقل و قطعی است.
ریال/تومان، تاریخ، منطقه زمانی و Unicode مبهم نیستند.
Step Definition نازک، یکتا و دارای Assertion است.
سطح Automation با ریسک و هزینه نگهداری متناسب است.
مالک دامنه متن و نتیجه را بازبینی کرده است.

پرسش‌های متداول درباره Gherkin و BDD

آیا BDD بدون Cucumber و Gherkin ممکن است؟

بله. هسته BDD همکاری، Discovery با مثال، Formulation روشن و Feedback است. می‌توانید مثال‌ها را در قالب دیگری ثبت و با ابزار دیگری خودکار کنید. Cucumber و Gherkin ابزارهای رایج این چرخه‌اند، نه تعریف کامل آن.

هر Scenario چند Given، When و Then داشته باشد؟

عدد اجباری وجود ندارد. یک When اصلی معمولاً علت را شفاف می‌کند و چند Given/Then مرتبط طبیعی‌اند. معیار بهتر این است که Scenario فقط یک رفتار متمایز را توضیح دهد، کوتاه بماند و بدون اسکرول یا حافظه زیاد فهمیده شود.

تفاوت Scenario Outline و Data Table چیست؟

Scenario Outline برای هر ردیف Examples یک Scenario مستقل می‌سازد. Data Table یک آرگومان ساختاریافته برای یک Step در همان Scenario است. اولی چند نمونه از یک رفتار، دومی یک مجموعه داده متعلق به یک نمونه را بیان می‌کند.

آیا سناریوی Gherkin باید حتماً خودکار شود؟

مثال موقت Discovery می‌تواند پیش از Automation ارزش داشته باشد. اما اگر سند را «اجرایی» یا «زنده» می‌نامید، مثال منتخب باید به رفتار سیستم وصل و مرتب اجرا شود. سناریوی دائمیِ دستی یا Pending باید هدف، مالک و تاریخ بازبینی داشته باشد.

گرکین فارسی بهتر است یا انگلیسی؟

زبانی بهتر است که متخصص دامنه و تیم آن را طبیعی می‌فهمند و Toolchain درست پشتیبانی می‌کند. Gherkin کلیدواژه فارسی رسمی دارد؛ در برخی تیم‌ها کلیدواژه انگلیسی با جمله‌های فارسی سازگاری ابزار بهتری می‌دهد. مهم، تصمیم یکدست و حفظ واژگان دامنه است.

جمع‌بندی

سناریوی Gherkin خوب ترجمه Test Case به زبان طبیعی نیست؛ محصول یک گفت‌وگوی دقیق درباره Rule و مثال است. ابتدا با Example Mapping ابهام و مرز را کشف کنید، سپس یک مثال عینی را با زمینه اثرگذار، رویداد روشن و خروجی قابل مشاهده صورت‌بندی کنید. UI و معماری را پشت Step Definition نگه دارید، Automation را در پایین‌ترین سطح معنادار اجرا کنید و فقط سندی را «زنده» بنامید که با رفتار فعلی به‌طور قابل اعتماد بررسی می‌شود.

برای تیم ایرانی، واحد پول، تقویم، منطقه زمانی، ارقام و Unicode بخشی از رفتار دامنه‌اند. آن‌ها را صریح کنید، اما Feature را به انبار همه داده‌ها تبدیل نکنید. هدف نهایی تعداد بیشتر Scenario نیست؛ پرسش‌های زودتر، Ruleهای روشن‌تر، Feedback سریع‌تر و نمونه‌هایی است که کسب‌وکار و فنی واقعاً بر سر معنای آن‌ها توافق دارند.

تست نرم افزار, سطوح تست