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

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

تمرکز اصلی توسعه رفتار محور بر موارد زیر است:

• از کجای روال شروع کنیم
• چه چیزی باید مورد آزمون قرار بگیرد و چه چیزی نه.
• در هر بار چه مقدار مورد آزمایش قرار دهیم.
• نحوه نام گذاری آزمون‌ها.
• چگونه بفهمیم که چرا آزمونی با شکست مواجه شده‌است.
  

در قلب توسعه رفتار محور یک بازخوانی دربارهٔ رویکرد واحد تست و آزمون پذیرش وجود دارد که به‌طور طبیعی با این مسائل همراه هستند. به عنوان مثال، ت.ر. م پیشنهاد می‌کند که عناوین تست واحد، جمله‌های کاملی باشند که با یک عبارت شرطی آغاز می‌شوند (به عنوان مثال "باید" به زبان فارسی) و باید به ترتیب ارزش کسب و کار نوشته شود. آزمون پذیرش باید با استفاده از چارچوب استاندارد یک داستان کاربر تهیه گردد: "به عنوان یک [نقش] من خواستار [ویژگی] هستم به‌طوری‌که [بهره]". معیارهای پذیرش باید به در قالب سناریو نوشته شده و به صورت کلاس پیاده‌سازی شوند: با توجه به [وضعیت اولیه] زمانی که [رویداد رخ می‌دهد] باید [اطمینان از برخی از نتایج].

با شروع از این نقطه، بسیاری از افراد در طول سالیان چهار چوب‌هایی برای ت.ر. م طراحی کرده‌اند که در نهایت آن را به عنوان یک چارچوب ارتباطی و همکاری برای توسعه دهندگان، تضمین کنندگان کیفیت و شرکای غیر فنی یا ذینفعان کسب و کار در یک پروژه نرم‌افزاری شکل داده‌اند. در کنفرانس یک روزه "Agile Specifications, BDD and Testing eXchange" در نوامبر ۲۰۰۹ در لندن شمالی تعریف زیر برای ت.ر. م ارائه شد:

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

دن نورس چهارچوب مبتنی بر توسعه رفتار محور JBehave، را ایجاد کرد که توسط یک چهارچوب ت.ر. م در سطح داستان برای Ruby دنبال شده که RBehave نام دارد که بعدها به پروژه RSpec پیوست. او همچنین با David Chelimsky, Aslak Hellesøy و دیگران برای توسعه RSpec و همچنین نوشتن کتابی با عنوان "Behaviour Driven Development with RSpec, Cucumber, and Friends" همکاری کرد.Tاولین چارچوب مبتنی بر داستان در RSpec بعدها جایگزین Cucumber شد که توسط Aslak Hellesøy توسعه داده شد. Capybara، که بخشی از چارچوب آزمون Cucumber است، یکی از نرم‌افزارهای تحت وب اتوماسیون آزمون است.

توسعه مبتنی بر تست یک روش توسعه نرم‌افزاری است که اساساً بیان می‌کند برای هر واحد نرم‌افزاری یک توسعه دهنده نرم‌افزار باید:

• نخست یک مجموعه آزمون برای واحد تعریف کند.
• شرایط شکست آزمون‌ها را مشخص کند.
• سپس واحدهای کاری را پیاده‌سازی کند.
• سرانجام بررسی کند که واحدهای پیاده‌سازی شده از تست‌ها موفق بیرون می‌آیند یا نه.

این تعریف از آنجا که تست‌ها را از لحاظ الزامات نرم‌افزاری سطح بالا، جزئیات فنی ریز یا هر چیز دیگر در بین آن‌ها تبیین می‌کند نسبتاً غیر اختصاصی است؛ بنابراین، از این نقطه نظر می‌توان به ت.ر. م نگاه کرد که که ت.ر. م ادامه توسعه TDD است که انتخابهای ویژه تری نسبت به TDD دارد.

توسعه رفتار محور مشخص می‌کند که آزمایش‌های هر واحد نرم‌افزاری باید با توجه به رفتار مورد نظر آن واحد باشد. الهام گرفتن از توسعه نرم‌افزاری چابک برای «رفتار مورد نظر» در این مورد شامل الزاماتی است که توسط کسب و کار تعیین می‌شود — یعنی رفتار مورد نظر که ارزش کسب و کار را برای هر نهاد که واحد نرم‌افزاری را در دست ساخت دارد، به کار گرفته‌است. این مورد در طی فعالیت ت.ر. م تحت عنوان برون‌گرا بودن ت.ر. م یاد می‌شود.

مشخصه‌های رفتاری

به دنبال این انتخاب اساسی، انتخاب دوم ساخته شده توسط BDD در ارتباط با چگونگی مشخص کردن نحوه «رفتار مورد نظر» می‌باشد. در این زمینه، BDD تصمیم به استفاده از قالب نیمه رسمی برای خصوصیات رفتاری می‌کند که از مشخصات داستان کاربری در حوزه تحلیل و طراحی شی گرا گرفته شده‌است. جنبه‌های سناریو این قالب ممکن است به عنوان اعمال منطق هوآر به مشخصه رفتاری واحدهای نرم‌افزاری با استفاده از زبان دامنه در نظر گرفته شود.

ت.ر. م مشخص می‌کند که تحلیلگران کسب و کار و توسعه دهندگان باید در این زمینه همکاری داشته باشند و رفتارها را در قالب عبارت‌های داستان‌های کاربریی مشخص کنند، که هر کدام صریحاً در یک سند اختصاصی نوشته می‌شوند. هر داستان کاربر به نحوی باید از ساختار زیر پیروی کند:

عنوان: داستان باید یک عنوان روشن و صریح داشته باشد.

روایت

یک بخش مقدماتی کوتاه که مشخص‌کننده موارد زیر است

• چه کسی: (کدام تجارت یا نقش پروژه) پیش برنده یا ذی‌نفع اصلی داستان است (بازیگرانی که از داستان سود می‌برند)
• چه: اثری که ذینفعان می‌خواهند داستان داشته باشد.
• چرا: ارزش تجاری که ذینفعان از این اثر عایدشان خواهد شد.

معیارهای پذیرش یا سناریوها

سناریو شرح هر یک از موارد خاص روایت است. چنین سناریویی دارای ساختار زیر است:

• با مشخص کردن شرایط اولیه که در آغاز سناریو درست در نظر گرفته شده‌اند شروع می‌شود. این مورد ممکن است از یک یا چندین جزء جمله متشکل شده باشد.
• پس از آن رویدادی را که باعث آغاز سناریو می‌شود مشخص می‌کند.
• نهایتاً، نتیجهٔ مورد انتظار را در یک یا چند جمله بیان می‌کند.

توسعه رفتار محور هیچ الزام رسمی برای اینکه دقیقاً چگونه این داستان‌های کاربر باید نوشته شود ندارد، اما اصرار دارد که هر تیم استفاده‌کننده از آن یک فرمت ساده و استاندارد برای نوشتن داستان‌های کاربر که شامل عناصر ذکر شده در بالا است، طراحی کند. با این حال، در سال ۲۰۰۷، دن نورت یک قالب را برای فرمت متنی پیشنهاد کرد که در ابزارهای مختلف نرم‌افزار ت.ر. م دنبال شده‌است. مثال بسیار کوتاهی از این فرمت ممکن است مانند این باشد:

 داستان: مرجوعی کالا

به عنوان یک صاحب فروشگاه
به منظور پیگیری موجودی کالا
من می‌خواهم کالاهای بازگشتی را به موجودی کالا، اضافه کنم.

سناریو ۱: موارد مسترد باید به موجودی کالا افزوده شود
داریم: یک مشتری قبلاً یک ژاکت سیاه از من خریداری کرده‌است
و من سه ژاکت سیاه در انبار دارم.
وقتی که او ژاکت سیاه را برای بازپرداخت بازمی‌گرداند.
آنگاه من باید چهار ژاکت سیاه در انبار داشته باشم.

سناریو ۲: موارد جایگزین باید به انبار بازگردانده شوند.
داریم: مشتری قبلاً یک لباس آبی از من خریداری کرده‌است
و من دو لباس آبی در انبار موجود دارم
و من سه لباس سیاه در انبار موجود دارم.
وقتی که او لباس آبی را برای جایگزینی با رنگ مشکی بازمی‌گرداند
آنگاه من باید سه لباس آبی در موجودی کالا داشته باشم.
و دو لباس مشکی در موجودی کالا داشته باشم.

سناریوها به صورت الزامی بدون اشاره به عناصر رابط کاربری (UI) که از طریق آن تعاملات صورت می‌گیرد، به صورت قانع‌کننده‌ای به زبان تجاری بیان می‌شوند،

این نوع فرمت تحت عنوان زبان Gherkin یاد می‌شود؛ که دارای نحو مشابه مثال فوق می‌باشد، اما اصطلاح Gherkin به ابزارهای نرم‌افزار Cucumber و JBehave و Behat اختصاص دارد.

خصوصیات به عنوان زبان فراگیر

توسعه رفتار محور مفهوم زبان فراگیر را از طراحی دامنه محور وام می‌گیرد. زبان فراگیر یک زبان نیمه رسمی است که توسط همه اعضای یک تیم توسعه نرم‌افزاری به اشتراک گذاشته شده‌است - هم توسعه دهندگان نرم‌افزار و هم پرسنل غیر فنی. زبان مورد نظر، به عنوان یک ابزار رایج برای بحث در رابطه با دامنه نرم‌افزار، توسط همه اعضای تیم مورد استفاده و توسعه قرار می‌گیرد. به این ترتیب، ت.ر. م وسیله‌ای برای ارتباط بین همه نقش‌های مختلف در یک پروژه نرم‌افزاری می‌شود.

یک مخاطره متداول در توسعه نرم‌افزار شامل تفکیک ارتباطات بین توسعه دهندگان و ذینفعان کسب و کار است. ت.ر. م از مشخصات رفتار مورد نظر به عنوان یک زبان عمومی برای اعضای تیم پروژه استفاده می‌کند. به همین علت است که ت.ر. م بر روی یک زبان نیمه رسمی برای خصوصیات رفتاری اصرار می‌ورزد: برخی از تشریفات برای داشتن یک زبان فراگیر الزامی هستند. علاوه بر این، داشتن چنین زبان فراگیری، یک مدل دامنه مشخصات را طوری ایجاد می‌کند که از رسمی بودن نتیجه شده باشند. این مدل همچنین اساس کاری ابزارهای نرم‌افزاری در دسترسی که از ت.ر. م پشتیبانی می‌کنند می‌باشد.

مثال فوق یک داستان کاربر را برای یک سیستم نرم‌افزاری تحت توسعه ایجاد می‌کند. این داستان کاربر یک ذی‌نفع، یک تأثیر تجاری و یک ارزش تجاری را شناسایی می‌کند. همچنین چندین سناریو، هر کدام با پیش شرط، اجراکننده و نتیجه مورد انتظار را شرح می‌دهد. هر یک از این قسمت‌ها دقیقاً با بخش رسمی زبان شناخته می‌شود (بع نوان مثال ممکن است اصطلاح داریم (Given) ممکن است به عنوان یک کلمه کلیدی در نظر گرفته شود) و در نتیجه ممکن است به طریقی توسط یک ابزاری که قسمت‌های فرمال زبان فراگیر را درک می‌کند، مورد استفاده قرار گیرد.

بیشتر برنامه‌های کاربردی ت.ر. م از DSLهای مبتنی بر متن و روش‌های مبتنی بر ویژگی استفاده می‌کنند. با این حال، مدلسازی گرافیکی سناریوهای ادغام نیز در عمل به‌طور موفقیت‌آمیز برای مثال برای اهداف تست استفاده شده‌است.

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

قالب اصول

در اصل یک ابزار پشتیبانی ت.ر. م یک چارچوب آزمایشی برای نرم‌افزار است، کاملاً شبیه ابزارهایی که TDD را پشتیبانی می‌کنند. با این حال، در جایی که ابزارهای TDD در آنچه که برای تعیین تست مجاز است تمایل به فرمت کاملاً آزاد دارد، ابزار ت.ر. م با تعریف زبان عمومی که پیشتر بحث شده‌است، مرتبط است.

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

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

دن نورس تعدادی از چارچوب‌هایی را پشتیبانی می‌کند که از ت.ر. م پشتیبانی می‌کنند (از جمله JBehave و RBehave) عملیات آن بر اساس الگویی است که او برای ضبط داستان‌های کاربر پیشنهاد می‌کند. این ابزارها از توضیحات متنی برای موارد استفاده و چندین ابزار دیگر (مانند CBehave) استفاده می‌کنند. با این حال، این فرمت لازم نیست و چنان‌که ابزارهای دیگری وجود دارد که از فرمت‌های دیگر نیز استفاده می‌کنند. به عنوان مثال Fitnesse (که بر حول جدول تصمیم ساخته شده‌است) نیز برای تدوین ت.ر. م مورد استفاده قرار گرفته‌است.

مثال برای ابزارها

نمونه‌های متعددی از ابزارهای نرم‌افزاری BDD که در پروژه‌ها امروزی، برای زبانها و سیستم‌های عمل مختلف مورد استفاده هستند وجود دارد.

احتمالاً شناخته شده‌ترین آن‌ها JBehave است که توسط Dan North توسعه داده شده‌است. مثال زیر از این پروژه گرفته شده‌است:

پیاده‌سازی بازی زندگی را در نظر بگیرید. یک متخصص دامنه (یا تحلیلگر کسب و کار) ممکن است بخواهد مشخص کند که وقتی کسی تنظیمات پیکربندی اولیه خانه‌های بازی را تنظیم کند چه باید رخ دهد. برای انجام این کار، ممکن است بخواهید نمونه‌ای از تعدادی از اقداماتی که توسط فردی که خانه‌ها را سویچ می‌کند مشخص کند. با رفتن به بخش روایت، او می‌تواند این کار را با نوشتن سناریو زیر به یک سند متن ساده (که نوعی سند ورودی است که JBehave قادر به خواندن آن است):

داریم: یک بازی ۵ در ۵
وقتی که من وضعیت خانه (۳, ۲)را تغییر می‌دهم
آنگاه جدول بازی باید وضعیت زیر را داشته باشند
.....
.....
.....
..X..
.....
وقتی که من وضعیت خانه (۳, ۱) را تغییر می‌دهم
آنگاه جدول بازی باید وضعیت زیر را داشته باشند
.....
.....
.....
..X..
..X..
وقتی که من وضعیت خانه (۳, ۲)را تغییر می‌دهم
آنگاه جدول بازی باید وضعیت زیر را داشته باشند
.....
.....
.....
.....
..X..

متن‌های با فونت پررنگ بخشی از ورودی نیست؛ بلکه در اینجا آمده‌است تا نشان دهد که کدام کلمات به عنوان زبان رسمی شناخته شده‌اند. JBehave کلمات داریم (Given) (به عنوان پیش شرطی که شروع یک سناریوی را مشخص می‌کند)، وقتی که (When) (به عنوان یک راه انداز رویداد) و آنگاه (Then) (به عنوان یک نتیجه شرط که باید به عنوان نتیجه عمل که به دنبال ماژول تأیید می‌شود، شناسایی شود). بر این اساس JBehave قادر به خواندن فایل متنی حاوی سناریو و تجزیه آن به مقادیر (یک بند تنظیم و سپس سه رویداد با شرایط قابل تأیید) می‌باشد. سپس JBehave این مقررات را می‌گیرد و آن‌ها را به کدی که قادر به تنظیم یک آزمون و پاسخ به فراخوانندگان رویداد و تأیید نتیجه است ارسال می‌کند. این کد باید توسط تیم توسعه دهندگان پروژه نوشته شود (در زبان جاوا به دلیل اینکه پلت فرم JBehave بر اساس زبان جاوا می‌باشد). در این مورد، کد مورد نظر ممکن است مشابه کد زیر باشد:

کد برای هر نوع عبارتی در یک سناریو یک روش دارد. JBehaveJBehave مشخص می‌کند که کدام روش با کدام عبارت، از چه کاربردی از حاشیه نویسی استفاده کند و هر متد را در هنگام اجرا از طریق سناریو فراخوانی کند .انتظار می‌رود متن هر عبارت سناریو با قالب متن داده شده در کد برای آن بند مطابقت داشته باشد (برای مثال، انتظار می‌رود که در یک سناریو عبارت داریم (Given) با یک جمله از فرم "یک بازی X در Y" دنبال شود). JBehave از تطبیق عبارات به قالب‌ها پشتیبانی می‌کند و دارای پشتیبانی داخلی برای درآوردن الفاظ از قالب و انتقال آن‌ها به عنوان پارامتر به متدها در کد آزمون می‌باشد. کد تست برای هر نوع بند در یک سناریو یک نوع پیاده‌سازی فراهم می‌کند که با کد مورد آزمایش تعامل می‌کند و بر اساس سناریو تست انجام می‌دهد. در این مورد:

• دستورtheGameIsRunning با تنظیم شبکه بازی اولیه به یک عبارت داریم (Given) واکنش نشان می‌دهد.
• دستورiToggleTheCellAt در پاسخ به عبارت وقتی که (When) رویداد تغیر وضعیت توصیف شده در جمله را فراخوانی می‌کند.
• متدtheGridShouldLookLike با مقایسه وضعیت خانه‌های بازی به وضعیت مورد انتظار از سناریو واکنش نشان می‌دهد.

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

در نهایت، برای اجرای آزمون، JBehave به برخی از برنامه‌های رابطی نیاز دارد که فایل‌های متنی را که حاوی سناریو هستند و وابستگی‌ها (مانند موارد بازیGame)را به کد آزمون تزریق می‌کند، شناسایی کند .این کد رابط در اینجا نشان داده نمی‌شود، زیرا یک نیاز فنی JBehave است و مستقیماً به اصل تست ت.ر.م مربوط نمی‌شود.

یک زیر شاخه جداگانه توسعه مبتنی بر رفتار به وسیلهٔ ابزارهایی است که از مشخصات به عنوان زبان ورودی به جای داستان کاربر استفاده می‌کنند. یک نمونه از این سبک ابزا RSpec است که توسط دن نورس توسعه داده شده‌است. ابزارهای مشخصات از داستان‌های کاربر به عنوان یک فرمت ورودی برای سناریوهای آزمایش استفاده نمی‌کنند، بلکه از ویژگی‌های عملکردی برای واحدهای مورد آزمایش استفاده می‌کنند. این مشخصات اغلب دارای ماهیت فنی بیشتری نسبت به داستان‌های کاربر هستند و معمولاً برای ارتباط با پرسنل تجاری به اندازه داستان‌های کاربر، مناسب نیستند. یک نمونه از این مشخصه برای پشته می‌تواند به صورت زیر باشد:

مشخصات: پشته

وقتی که: یک پشته جدید ایجاد می‌شود.
آنگاه: آن پشته خالی است.

وقتی که: یک عنصر به پشته اضافه می‌شود
آنگاه: این عنصر در بالای پشته قرار دارد

وقتی که: یک پشته دارای N عنصر است.
و عنصر E در بالای پشته قرار دارد
آنگاه: a یک دستور pop عنصر E را بازمی‌گرداند
و اندازه جدید پشته N-1 است

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

ابزارهای تست مشخصات مانند RSpec و JDave از ابزارهایی مانند JBehave در طبیعت تا حدودی متفاوت هستند. از آنجایی که آن‌ها به عنوان جایگزینی برای ابزارهای تست پایهٔ واحد مانند JUnit, دیده می‌شوند، این ابزار تمایل دارد از جدایی داستان و کد تست چشم پوشی کند و ترجیح می‌دهد خصوصیات را مستقیماً در کد تست تعبیه کند. به عنوان مثال، یک آزمون RSpec برای hashtable می‌تواند به صورت زیر باشد:

describe Hash do
  let(:hash) { Hash[:hello, 'world'] }

  it { expect(Hash.new).to eq({}) }

  it "hashes the correct information in a key" do
    expect(hash[:hello]).to eq('world')
  end

  it 'includes key' do
    hash.keys.include?(:hello).should be true
  end
end

این مثال مشخصاتی را در زبان قابل خواندن که در کد اجرایی تعبیه شده‌است نشان می‌دهد.Iدر این مورد، انتخاب ابزار این است که با اضافه کردن متدهایی به نام it و should زبان مشخصه‌ها را به زبان کد تست رسمی تبدیل کند. همچنین مفهوم یک پیش شرط مشخصه تحت عنوان بخش before وجود دارد که پیش شرط‌هایی را که مشخصات بر اساس آن است، ایجاد می‌کند.

 Hash
 should eq {}
 includes key
 hashes the correct information in a key