BDD فرزند خلف TDD و DDD

تاریخ انتشار نسخه اصلی 6 دسامبر, 2016

وقتی در دوره کارشناسی در مورد روشهای مختلف توسعه نرم افزار مثل DSDM , SSADM و RUP  میخواندیم، یکی از سوالایم همیشه این بود که افراد مختلف در یک شرکت که نقشهای مختلف را برعهده دارند چطوری با همدیگر ارتباط برقرار میکنند؟ آدمهای فنی و غیرفنی که دیدگاه و دایره لغات یکسانی ندارند چطور دچار سوء تفاهم نمیشوند؟ در واقع در روشهای بالا فازهای مختلف پروژه آنقدر از یکدیگر جدا و فاصله دار بودند که بنظر نمیرسید حتی زبانهای مدلینگ مثل UML هم کمک زیادی به ارتباط بهتر بکنند. زمانیکه شروع بکار کردم این قضیه بیشتر برایم روشن شد. احتمالا این تصویر معروف را همه دیده اید. درست است که خیلی تکراری شده و حقیقت دارد.

وقتی در سوئد مشغول بکار شدم و روش Agile را از نزدیک دیدم. احساس کردم که این مشکل ارتباطی تا اندازه ای بهبود پیدا کرده است. علت آن هم کوچک شدن تیم ها، کوتاه شدن چرخه بازخورد (feedback loop) و سرعت بیشتر در تولید محصول است که باعث میشود فرکانس و تناوب ارتباط تیم برنامه نویسی با تست کننده، مدیر نرم افزار بیشتر شده و در نتیجه به زبان مشترک نزدیکتر شوند. اما مسئله ارتباط هنوز هم سر جای خود است و هر چند سال یکبار هم شیوه ای جدید برای بهبود آن معرفی میشود. در میان این شیوه ها آنهایی موفق هستند که ماندگاری بیشتری دارند. شرکتهای زیادی آنها را پیاده سازی میکنند. ابزارهای زیادی ایده و مدلشان را پیاده سازی میکنند و در کل Community قوی حول آنها شکل میگیرد. یکی از این روشها  Behavioral Driven Development  یا توسعه مبتنی بر رفتار است. BDD که در غالب Agile اجرا میشود را میتوان در ادامه TDD و تحت تاثیر DDD دانست. پس بهتر است قبل از رفتن به جزئیات، با این دو روش مفهوم آشنا شویم:

• روش Test Driven Development یا توسعه مبتنی بر تست مفهومی است که در سال 2003 مطرح شد و بر اساس آن ابتدا تست یک واحد نرم افزاری مانند یک متد قبل از خود آن نوشته میشود. کد نویسی در یک چرخه تا زمانی ادامه پیدا میکند که تست آن با موفقیت انجام (اصطلاحاً pass) شود. Unit Test هایی که امروز در اکثر پروژهای نرم افزاری نوشته میشود در واقع این مفهوم را پیاده سازی میکنند. JUnit در جاوا، NUnit در dotNet و unittest در Python نمونه های از این پیاده سازی هستند.
• روش Domain Driven Design یا طراحی مبتنی بر دامنه کسب و کار، مفهومی است که در سال 2004 مطرح شد که یکی از هدف های آن معرفی زبانی فراگیر (ubiquitous language) در یک زمینه تخصصی کسب و کار است تا نقشهای مختلف حاضر در چرخه تولید نرم افزار مانند برنامه نویس، تست کننده، مدیر نرم افزار و کاربر بتوانند بهتر و موثرتر با هم ارتباط برقرار کنند. واژه های استفاده شده در مستندها صریح و خالی از ابهام است و همگی بر سر مفهوم آنها توافق دارند. این واژه ها بر خلاف زبان رایج در میان برنامه نویسان تکنیکی نیستند بلکه مختص به یک حوزه کسب و کار است. مثلا شرکتی که در زمینه نرم افزارهای بورس یا مدیریت منابع انسانی فعالیت میکند واژگان خاصی استفاده میکند که با حوزه های دیگر متفاوت است. در واقع این روش از تیم تینیکی شرکت میخواهد که زبان تخصصی کسب و کار را یاد گرفته و در مستند سازی و ارتباطات روزانه  از آن استفاده کند.

روش BDD که در سال 2006 معرفی شد هدف اش آن است که روش TDD را ادامه دهد ولی برخلاف زبان تکنیکی آن که در نوشتن unit test استفاده میشود زبانی فراگیر را معرفی کند که تمامی افراد سهیم در پروژه (stakeholders)  بتوانند از طریق آن با هم ارتباط برقرار و مستند سازی کنند. امروز برای این روش چهارچوبهای نرم افزاری در زبانهای مختلف برنامه نویسی وجود دارد.  Cucumber در  Ruby و SpecFlow در dotNet نمونه هایی از آن هستند. در پست بعدی در مورد جزئیات این روش بیشتر مینویسم و مثالهایی از SpecFlow میاورم.