توسعه آزمون‌محور
توسعهٔ آزمون‌محور (تام) (به انگلیسی: Test-driven development) یک فرایند توسعهٔ نرم‌افزاری است که بر پایه تکرار یک سری دوره‌های خیلی کوتاه توسعه قرار دارد: ابتدا برنامه‌نویس یک مورد آزمایشی (در ابتدا دارای شکست) برای بهبود مطلوب یا ایجاد قابلیت جدید می‌نویسد، سپس کمترین مقدار تغییرات کدی را که باعث قبول شدن آزمایش می‌شود می‌نویسد، سپس کد جدید را با استانداردهای قابل قبول سازماندهی مجدد می‌کند.
یک مهندس نرم‌افزار آمریکایی به نام کنت بک، که توسعه یا «بازکشف» این روش را به وی نسبت می‌دهند، در سال ۲۰۰۳ اظهار داشت که TDD طرح‌های ساده و الهام بخش اعتماد به نفس را تشویق می‌کند.
Test-driven development مربوط به مفاهیم آزمون-برای اولین بار (test-first programming concepts) برنامه‌نویسی و شدید برنامه‌نویسی (extreme programming) است که در سال ۱۹۹۹[1] مطرح شد اما اخیراً علاقه بیشتری را نسبت به خود ایجاد کرده‌است.[2]
برنامه نویسان همین‌طور می‌توانند این مفهوم را برای بهبود و اشکال زدایی کد میراث تهیه شده با روش‌های قدیمی تر به کار گیرند.[3]
چرخه توسعه آزمون محور
چرخه توسعه آزمون محور (به انگلیسی: Test-driven development؛ به اختصار TDD) یک فرایند توسعه نرم‌افزار است که متکی بر تکرار یک چرخه توسعه بسیار کوتاه است که طی آن نیازمندی‌ها تبدیل به موارد آزمون بسیار خاص می‌شوند و سپس نرم‌افزار به قدری بهبود بخشیده می‌شود که فقط بتواند تست‌های مطرح شده را پاس کند. این روند مخالف نحوه توسعه سنتی نرم‌افزار است که اجازه می‌دهد تا بخش‌هایی به نرم‌افزار اضافه شود که هنوز تست‌های لازم را نگذرانده‌است و سپس آن بخش‌های جدید را تست می‌کند.
توسعه آزمون محور، بر مبنای نوشتن آزمون (Test) برای نرم‌افزار بر اساس نیازمندی‌ها (requirements) قبل از نوشتن برنامه شکل گرفته‌است. در این فرایند هدف توسعه دهنده معطوف به گذراندن این تست‌ها می‌شود. ابتدا چون برنامه خالی است، تمامی آزمون‌ها باید با عدم موفقیت رو به رو شوند، اما برنامه‌نویس گام به گام برای هر ویژگی (feature) این آزمون‌ها را پشت سر می‌گذارد که اگر در هر مرحله موفقیت‌آمیز نبود، بازمی‌گردد و کد را دیباگ می‌کند.
البته باید توجه داشت که در متدولوژی TDD علاوه بر آزمون‌های گام به گام نیازمند آزمون‌های موازی مستقل نیز هستیم.
چرخه کلی روش توسعه آزمون محور شامل گام‌هایی به ترتیب زیر است که بر اساس کتاب Test-Driven Development by Example نوشته شده‌است:[4]
۱. یک تست جدید بنویس
در روش توسعه آزمون محور هر ویژگی جدید با افزودن یک تست شروع می‌شود. طبیعی است این تست باید طوری طراحی شود که تنها با افزوده شدن صحیح و کامل ویژگی جدید مطلوب پاس شود.
۲. تمام تست‌ها را اجرا کن و ببین آیا تست جدید پاس می‌شود یا خیر
در این مرحله قصد داریم مطمئن شویم تست جدیدی که افزودیم خطا بدهد، وگرنه با افزودن کد جدید امکان اینکه چک شود ویژگی جدید واقعاً به درستی افزوده شده‌است یا خیر وجود نخواهد داشت.
۳. کد را بنویس
در این گام تنها کد اضافه ای که نیاز هست تا تست جدید پاس شود را می‌نویسیم و به زیاده روی در توسعه نمی‌پردازیم.
۴. مجدداً تست‌ها را اجرا کن
این بار اگر تمام تست‌ها پاس شوند مطمئن می‌شویم که تمام ویژگی‌های قبلی به درستی کار می‌کنند و علاوه بر آن ویژگی جدید نیز به‌طور صحیح اضافه شده‌است.
۵. کد را Refactor کن
روشن است که کد کل برنامه باید هر چند وقت یک بار تمیز و مرتب شود تا از ایجاد کد کثیف اجتناب شود و امکان بهبود مناسب و سریع در آینده فراهم باشد. در این گام قصد داریم دقیقاً همین کار را انجام دهیم. در این گام به‌طور ویژه لازم است به ملاحظات توسعه همانند رعایت وراثت و خوانایی و امکان نگهداری مناسب کد و الگوهای طراحی برنامه توجه داشته باشیم.
۶. گام‌های ۱ الی ۵ را (برای هر ویژگی جدید که اضافه می‌کنی) تکرار کن
برای هر ویژگی جدید گام‌های فوق را تکرار می‌کنیم.
مزایای توسعه آزمون محور
یک مطالعه در سال ۲۰۰۵ به این نتیجه رسید که استفاده از روش توسعه آزمون محور به معنی نوشتن تعداد بیشتری تست هست و برنامه‌نویسانی که تعداد بیشتری تست می‌نویسند (برخلاف تصور عموم) بازدهی بیشتری دارند. همین‌طور برنامه‌نویسانی که از روش توسعه آزمون محور بهره می‌بردند گزارش کردند که به تعداد دفعات کمتری نیاز به استفاده از Debugger در کار خود داشتند، که این امر به نوبه خود موجب بهبود و افزایش بهره‌وری آنها می‌شود. چنین کاهشی در تعداد دفعات نیاز به استفاده از Debugger طبیعی به نظر می‌رسد، چرا که هر گام از توسعه و هر ویژگی جدیدی که به برنامه افزوده می‌شود خود همراه با تست در محل می‌باشد و تا زمانی که تست مربوطه و تمام تست‌های پیشین برنامه پاس نشوند به مرحله بعد نمی‌رویم. همین‌طور گزارش شده‌است که در روش توسعه آزمون محور هرگاه به خطایی برخورد کنیم معمولاً بازگشت به آخرین نسخه بدون خطا و شروع مجدد کار بهینه تر از استفاده از Debugger است که این امر عملاً نیاز به دیباگ کردن کد و هزینه‌های مالی و زمانی نگهداری و تعمیر کد را کاهش می‌دهد.
از ویژگی‌ها و مزیت‌های دیگر این متدولوژی می‌توان موارد زیر را نام برد:
۱. بررسی کامل‌تر در ابتدا:
این فرایند باعث می‌شود قبل از نوشتن برنامه، به جنبه‌های مختلف نیازمندی‌ها فکر کنیم و مواردی که روش‌های موجود می‌توانند شکست بخورند را بررسی کرده و در داخل آزمون‌ها در نظر بگیریم.
۲. متمرکز کردن اهداف:
برنامه‌نویس هدف خود را با داشتن آزمون‌ها به روشنی می‌داند و می‌توانند صرفاً با تمرکز بر روی همین آزمون‌ها، از یک هدف و نیازمندی مبهم خود را دور کند.
۳. کاهش هزینه‌ها در نهایت
ممکن است TDD در ابتدا پرهزینه به نظر بیاید، اما به دلیل این که فرایند آزمون مرحله به مرحله و برای بخش‌های مختلف برنامه و بر اساس نیازمندی‌های مورد نیاز است، احتمال وارد شدن هزینه سنگینی که به خاطر عدم تطابق برنامه با نیازها پرداخت خواهد شد کاهش میابد
۴. توسعه گام به گام
در بسیاری از موارد پیش آماده که برنامه را کامل نوشتیم و بعد به آزمون آن پرداختیم و به اشکالی برخوردیم، ولی چون از سر منشأ مشکلات به صورت دقیق آگاه نبودیم، نتوانستیم آنها را رفع کنیم. توسعه آزمون محور این مسئله را نیز برای ما برطرف می‌کند.
۵. مستندسازی
اگر از عملکرد تابعی در برنامه اطمینان نداشته باشیم، می‌توانیم با بررسی آزمون مربوط به آن تابع و پاسخ مد نظر، شهودی از رفتار مورد انتظار آن تابع داشته باشیم.
۶. کدهای مرتب‌تر
با توجه به این که از رفتار تابع‌ها به صورت مجزا می‌توان اطمینان یافت، می‌توان refactoring را به صورت آنی‌تری انجام داد، همچنین سطح‌های دسترسی توابع (خصوصی و عمومی) را پس از اطمینان از صحت درستی به صورت درجا مشخص کنیم و مجبور نشویم برای تست یک تابع در توابع دیگر این سطح دسترسی‌ها را تغییر دهیم.
کارهای آزمون محور
روش آزمون محور (به انگلیسی: Test-driven Work) در خارج از حیطه توسعه نرم‌افزار نیز به کار گرفته شده‌است. این روش تحت عنوان کار آزمون محور در تیم‌های تولیدی و خدماتی مورد استفاده قرار گرفته‌است. در کار آزمون محور همانند توسعه نرم‌افزار آزمون محور، تیم‌ها تعداد آزمون کنترل کیفیت برای هر جنبه از موضوع کار طراحی می‌کنند و سپس به ارزیابی آن و طراحی جهت ارضای آن می‌پردازند تا موفق شوند آن را پاس کنند.
شش گام ذکر شده در توسعه نرم‌افزار آزمون محور با تغییراتی جزئی به شکل زیر برای کار آزمون محور نیز به کار گرفته می‌شوند:
- "افزودن چک" به جای "افزودن آزمون
- "اجرای تمام چک‌هاً به جای "اجرای تمام آزمون‌ها
- "انجام کار" به جای "نوشتن کد
- "اجرای تمام چک‌هاً به جای "اجرای تمام آزمون‌ها
- "کار را مرتب کن" به جای "کد را Refactor کن
- «گام‌های ۱ الی ۵ را (برای هر ویژگی جدید که اضافه می‌کنی) تکرار کن» (بدون تغییر نسبت به TDD)
جستارهای وابسته
منابع
- Lee Copeland (December 2001). "Extreme Programming". Computerworld. Retrieved January 11, 2011.
- Newkirk, JW and Vorontsov, AA. Test-Driven Development in Microsoft .NET, Microsoft Press, 2004.
- Feathers, M. Working Effectively with Legacy Code, Prentice Hall, 2004
- Beck, K. Test-Driven Development by Example, Addison Wesley - Vaseem, 2003
پیوند به بیرون
- TestDrivenDevelopment در WikiWikiWeb
- Bertrand Meyer (September 2004). "Test or spec? Test and spec? Test from spec!". Archived from the original on 2005-02-09.
- Microsoft Visual Studio Team آزمون از روش TDD
- نوشتن نگهداری واحد آزمون است که به شما صرفه جویی در وقت و اشک
- بهبود کیفیت نرم‌افزار با استفاده از Test-Driven Development (TDD)