توسعه رفتار محور

توسعه رفتار محور

توسعه رفتار محور (Behavior Driven Development) مجموعه‌ای از شیوه‌های مهندسی نرم‌افزار است که برای کمک به تیم‌ها در ساخت و ارائه سریع‌تر نرم‌افزارهایی ارزشمندتر و با کیفیت بالاتر طراحی شده‌اند.

این رویکرد از شیوه های چابک و ناب از جمله توسعه آزمون محور (TDD) و طراحی دامنه محور (DDD) استفاده می کند. اما مهمتر از همه، BDD یک زبان مشترک مبتنی بر جملات ساده و ساختار یافته به زبان انگلیسی (یا به زبان مادری ذینفعان) ارائه می دهد که ارتباط بین اعضای تیم پروژه و ذینفعان کسب و کار را تسهیل می کند. برای درک بهتر انگیزه ها و فلسفه ای که از BDD پشتیبانی می کنند، بهتر است در ابتدا بفهمیم BDD چگونه شکل گرفته است.

BDD در ابتدا به عنوان یک نسخه بهبود یافته از TDD طراحی شد

BDD در ابتدا توسط Dan North دراوایل تا اواسط دهه 2000 به عنوان روشی ساده برای آموزش و تمرین توسعه آزمون محور (TDD)  ابداع شد. توسعه آزمون محور که توسط کنت بک در روزهای اولیه نهضت چابک ارائه شده بود، یک تکنیک بسیار موثر است که از تست های واحد (Unit Tests) برای تعیین نیازمندی ها، طراحی و تایید کد برنامه استفاده می کند.

هنگامی که متخصصان TDD نیاز به پیاده سازی یک کارکرد دارند، ابتدا یک تست رد شده (Failed) می نویسند که آن کارکرد را توصیف و تبیین می کند. در مرحله بعد، آنها به اندازه کافی کد می نویسند تا آزمون پذیرش شود (Passed). این تکنیک ساده اما قدرتمند توسعه دهندگان را تشویق به نوشتن کدهایی تمیزتر، با طراحی بهتر، نگهداری آسان تر و تعداد عیوب به میزان قابل توجهی کمتر می کنند.

با وجود مزایای آن، بسیاری از تیم ها هنوز در پذیرش و استفاده موثر از TDD با مشکل مواجه هستند. توسعه دهندگان اغلب در درک اینکه از کجا شروع کنند یا چه تست هایی را باید بنویسند، مشکل دارند. گاهی اوقات TDD می تواند توسعه دهندگان را به سمت تمرکز بیش از حد بر جزئیات سوق دهد و تصویر گسترده تری از اهداف کسب و کار را که قرار است اجرا کنند از دست بدهند. برخی از تیم‌ها همچنین متوجه می‌شوند که با افزایش اندازه پروژه، نگهداری تعداد زیادی از آزمون‌های واحد ممکن است سخت شود.

در واقع، بسیاری از تست‌های واحد سنتی، که نوشته شده‌اند به جای تمرکز بر نیازمندی ها یا انتظارات کسب و کار تنها بر جنبه های فنی کد تمرکز نموده اند. از این رو برای بهبود آزمون های واحد باید رویکردی اتخاذ شود که بر نیازمندی های کسب و کار متمرکز شود.

کاربرد BDD برای تجزیه و تحلیل نیازمندی های کسب و کار

توصیف رفتار یک سیستم همان کاری است که تحلیلگران کسب و کار هر روز انجام می دهند. نورث با همکار تحلیلگر کسب و کار خود، کریس متس، تلاش کرد تا آنچه را که آموخته بود در فضای تحلیل نیازمندی ها به کار گیرد. در همین زمان، اریک ایوانز ایده طراحی Domain-Driven را معرفی کرد که استفاده از زبانی فراگیر (Ubiquitous Language) و قابل درک برای افراد کسب و کار ترویج می کند. چشم انداز نورث و متز ایجاد زبانی فراگیر بود که تحلیلگران کسب و کار بتوانند از آن برای تعریف نیازمندی ها به طور واضح استفاده کنند و همچنین بتوانند به راحتی به آزمون های پذیرش خودکار تبدیل شود. برای پیاده سازی این چشم انداز، آنها شروع به بیان معیارهای پذیرش (Acceptance Criteria) داستان های کاربر (User Stories) در قالب نمونه هایی شناخته شده کردند.

به عنوان مثال سناریوی زیر را برای انتقال وجه از حساب مشتری در نظر بگیرید:

در نظر بگیرید، مشتری دارای یک حساب جاری است.

زمانی که مشتری وجوهی را از این حساب به یک حساب دیگر منتقل می کند.

سپس وجوه باید به حساب دیگر واریز شود.

و کارمزد معامله باید از حساب جاری کسر شود.

 

Given a customer has a current account

When the customer transfers funds from this account to an overseas account

Then the funds should be deposited in the overseas account

And the transaction fee should be deducted from the current account

در این زبان از یک سری کلمات رزرو شده از جمله Given، When و Then استفاده می شود.

نماد رفتاری توسعه رفتار محور

یک متخصص کسب و کار می تواند به راحتی سناریویی را که به این شکل نوشته شده است درک کند. این ساختار اهداف روشن و عینی را برای هر User Story از نظر اینکه چه چیزی باید توسعه یابد و چه چیزی باید آزمون شود، ارائه می دهد.

این نماد در نهایت به شکلی متداول تبدیل شد که اغلب به آن Gherkin گفته می شود. با ابزارهای مناسب، سناریوهای نوشته شده در این فرم را می توان به معیارهای پذیرش خودکار تبدیل کرد که هر زمان که لازم باشد به صورت خودکار اجرا می شوند.

دننورث اولین کتابخانه اختصاصی اتوماسیون تست  BDD ، JBehave را در اواسط دهه 2000 نوشت و از آن زمان بسیاری دیگر برای زبان‌های مختلف، هم در سطح آزمون واحد (Unit Test) و هم در سطح آزمون پذیرش (Acceptance Test)، پدیدار شدند.

توسعه مبتنی بر آزمون پذیرش

بسیاری از ایده ها در مورد BDD جدید نیستند. و برای سال ها تحت نام های مختلف ارائه شده اند. برخی از اصطلاحات رایج‌تر مورد استفاده برای این شیوه‌ها عبارتند از توسعه مبتنی بر آزمون پذیرش (Acceptance-Test-Driven Development)، برنامه‌ریزی مبتنی بر آزمون پذیرش، و توصیف نیازمندی ها براساس مثال (Specification By Example).

Specification by Example مجموعه اقداماتی را توصیف می کند. که با استفاده از مثال ها و گفتگو برای کشف و توصیف نیازمندی ها ارائه شده اند. استفاده از مکالمه و مثال‌ها برای مشخص کردن اینکه انتظار دارید یک سیستم چگونه رفتار کند، بخش اصلی BDD است.

Specification by Example

توسعه مبتنی بر آزمون پذیرش (ATDD) اکنون یک مترادف پرکاربرد برای Specification by Example است. این روش حداقل از اواخر دهه 1990 به اشکال مختلف وجود داشته است. کنت بک و مارتین فاولر در سال 2000 به این مفهوم اشاره کردند.

اگرچه مشاهده کردند که اجرای معیارهای پذیرش در قالب آزمون های واحد مرسوم در شروع یک پروژه دشوار است. اما آزمون‌های واحد تنها راه برای نوشتن آزمون‌های پذیرش خودکار نیستند. حداقل از اوایل دهه ۲۰۰۰، تیم‌های نوآور از کاربران خواسته‌اند تا در آزمون‌های پذیرش اجرایی (Executable Acceptance Tests) مشارکت کنند و از مزایای آن بهره‌مند شوند.

برنامه‌ریزی مبتنی بر آزمون پذیرش این ایده است که تعریف معیارهای پذیرش برای یک کارکرد منجر به تخمین‌های بهتری نسبت به انجام تفکیک کار می‌شود.

روش سه مرحله ای برای توسعه BDD

اساساً، فعالیت روزانه BDD یک فرآیند سه مرحله ای و تکرارپذیر است:

1. ابتدا، یک نیازمندی یا کارکرد کوچک را در سیستم در قالب یک User Story در نظر بگیرید. در مورد جزییات سناریو و معیارهای پذیرش با ذینفعان کسب و کار صحبت کنید. و آنها را در قالب یک روایت همانند نمونه فوق با استفاده از عبارات (Given, When and Then) مستند کنید.
2. در مرحله باید سناریو را با رویکرد (Specification By Example) و در قالب زبان Gherkin مستند کنید.
3. سپس تست های نوشته شده، با زبان Gherkin را در یک محیط از جمله SpecFlow پیاده سازی کنید.
4. پس از اینکه کد توسط توسعه دهندگان پیاده سازی شد ست. کافی Binding مراحل تست ها (Step) به کد را انجام دهید و آزمون های خودکار را اجرا کنید.

در پست های آتی در مورد مراحل توسعه آزمون ها به روز توسعه رفتار محور (BDD) بیشتر صحبت خواهیم کرد.