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

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

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

تخصصی قطعه سازی پشتیبانی

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

داستان در مقابل مشخصات

یک زیر شاخه جداگانه توسعه مبتنی بر رفتار به وسیلهٔ ابزارهایی است که از مشخصات به عنوان زبان ورودی به جای داستان کاربر استفاده می‌کنند. یک نمونه از این سبک ابزا 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
  endend
این مثال مشخصاتی را در زبان قابل خواندن که در کد اجرایی تعبیه شده‌است نشان می‌دهد.Iدر این مورد، انتخاب ابزار این است که با اضافه کردن متدهایی به نام it و should زبان مشخصه‌ها را به زبان کد تست رسمی تبدیل کند. همچنین مفهوم یک پیش شرط مشخصه تحت عنوان بخش before وجود دارد که پیش شرط‌هایی را که مشخصات بر اساس آن است، ایجاد می‌کند.
 Hash
 should eq {}
 includes key
 hashes the correct information in a key