توسعه مبتنی بر **آزمون پذیرش** (به انگلیسی: Acceptance Test-driven development)، (خلاصه: ATDD) یک روش توسعه مبتنی بر ارتباط بین مشتریان تجاری، توسعه دهندگان و آزمایش کنندگان است. شامل بسیاری از شیوه‌های مشابه مشخصات با مثال توسعه رفتار محور، توسعه محور مثال، و پشتیبانی محور است. توسعه همچنین توسعه محور داستان نامیده می‌شود. همه این فرایندها به توسعه دهندگان و آزمایش کنندگان در درک نیازهای مشتری قبل از اجرای برنامه کمک می‌کند و به مشتریان این امکان را می‌دهد که بتوانند با زبان دامنه خود مکالمه کنند.

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

بررسی اجمالی
------------

آزمون‌های پذیرش از دید کاربر - نمای بیرونی سیستم. آنها جلوه‌های بیرونی قابل مشاهده را بررسی می‌کنند، مانند مشخص کردن خروجی صحیح یک سیستم خاص با ورودی خاص. آزمون‌های پذیرش می‌توانند تأیید کنند که چگونه وضعیت چیزی تغییر می‌کند، مانند سفارش که از «پرداخت» به «حمل شده» می‌رود. آنها همچنین می‌توانند تعامل با رابط‌های سیستم‌های دیگر، مانند پایگاه داده‌های مشترک یا خدمات وب را بررسی کنند. به‌طور کلی، آنها مستقل از اجرای هستند، اگرچه ممکن است اتوماسیون آنها نباشد.

### ایجاد

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

### استراتژی تست

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

معیارهای پذیرش و آزمایش‌ها
--------------------------

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

### قالب آزمایش

آزمون‌های پذیرش معمولاً از این فرم پیروی می‌کنند:

**داده شده (تنظیم)**

یک حالت مشخص از یک سیستم است.
**وقتی (ماشه)**

یک عمل یا رویدادی رخ می‌دهد
**سپس (تأیید)**

وضعیت سیستم تغییر کرده یا خروجی تولید شده‌است

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

```
Given Book that has not been checked out
And User who is registered on the system
When User checks out a book
Then Book is marked as checked out

```

### تست کامل

مراحل قبلی هیچ داده نمونه خاصی را شامل نمی‌شود، بنابراین برای تکمیل آزمون اضافه شده‌است:

**داده شده:**

کتابی که بررسی نشده‌است

|  |  |
| --- | --- |
| کتابها |  |
| عنوان | بررسی شد |
| کتاب عالی | نه |

کاربری که در سیستم ثبت شده‌است

منابع
-----

1. ↑  Pugh, Ken (2011). *Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration*. Addison-Wesley. ISBN 978-0-321-71408-4.