مقالات

توسعه تست محور، رویکردها و مزایا چیست؟

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

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

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

توسعه تست محور (TDD) به عنوان بخشی از یک الگوی طراحی نرم افزار بزرگتر به نام برنامه نویسی افراطی (XP) که بخشی از متدولوژی توسعه نرم افزار چابک است، سرچشمه گرفت.

مفهوم ساده TDD نوشتن و رفع تست های ناموفق قبل از نوشتن کد جدید (قبل از توسعه) است. این به جلوگیری از تکرار کد کمک می کند زیرا ما در هر زمان مقدار کمی کد را برای گذراندن آزمون می نویسیم. (آزمون ها چیزی جز شرایط الزامی نیستند که برای برآورده شدن آنها باید آزمایش کنیم).

توسعه تست محور فرآیند توسعه و اجرای تست های خودکار قبل از توسعه واقعی برنامه است. از این رو، TDD را گاهی Test First Development نیز می نامند.

مراحل رویکرد TDD

قبل از اینکه هر کد جدیدی نوشته شود، برنامه نویس باید ابتدا یک تست واحد ناموفق ایجاد کند. سپس، برنامه نویس – یا زوج، یا اوباش – فقط به اندازه کافی کد ایجاد می کند تا آن نیاز را برآورده کند. پس از گذراندن آزمون، برنامه نویس می تواند پروژه را بازسازی کند و بدون تغییر رفتار، پیشرفت هایی را انجام دهد.

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


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

مزایای TDD

توسعه آزمایش محور می تواند برنامه های کاربردی با کیفیت بالا را در زمان کمتری نسبت به روش های قدیمی تر ایجاد کند. اجرای موفقیت آمیز TDD مستلزم آن است که توسعه دهندگان و آزمایش کنندگان به طور دقیق نحوه استفاده از برنامه و عملکرد آن در دنیای واقعی را پیش بینی کنند.

خبرنامه نوآوری
مهم ترین اخبار نوآوری را از دست ندهید. برای دریافت آنها از طریق ایمیل ثبت نام کنید.

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

مزایای مورد انتظار:

  • کاهش قابل توجه در نرخ نقص، به قیمت افزایش متوسط ​​در تلاش اولیه توسعه
  • هزینه های سربار بیش از کاهش تلاش در مراحل پایانی پروژه ها جبران می شود
  • TDD منجر به کیفیت طراحی بهتر در کد و به طور کلی، درجه بالاتری از کیفیت "داخلی" یا فنی می شود، به عنوان مثال با بهبود معیارهای انسجام و جفت.

معایب TDD

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

همچنین، بسیاری از برنامه نویسان مهارت هایی برای جداسازی و ایجاد کدهای تمیز ندارند. همه اعضای تیم باید تست های واحد را ایجاد و نگهداری کنند وگرنه به سرعت منسوخ می شوند. و سازمانی که به سمت TDD نگاه می کند باید زمان سرمایه گذاری کند، اکنون کمی سرعت خود را کاهش دهد تا بعداً سریعتر پیش رود.

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

اشتباهات متداول:

  • فراموش کردن اجرای مکرر تست ها
  • همزمان تست های زیادی بنویسید
  • تست هایی را بنویسید که خیلی بزرگ یا درشت هستند
  • نوشتن تست های بیش از حد بی اهمیت، مانند حذف اظهارات
  • نوشتن تست برای کدهای بی اهمیت
  • پذیرش جزئی: تنها تعداد کمی از توسعه دهندگان در یک گروه کاری از TDD استفاده می کنند
  • تعمیر و نگهداری ضعیف مجموعه آزمایشی، که معمولاً منجر به یک مجموعه آزمایشی با مدت زمان بسیار طولانی می شود
  • مجموعه آزمایشی رها شده است (یعنی به ندرت یا هرگز اجرا نمی شود) - گاهی به دلیل نگهداری ضعیف، گاهی به دلیل جابجایی تیم

فلسفه TDD

TDD به برنامه نویس این امکان را می دهد که هنگام نوشتن نرم افزار قدم های کودکی بردارد. این تست قبل از آزمایش عملکرد نوشته شده است و اطمینان حاصل می کند که برنامه برای آزمایش پذیری مناسب است. آزمایش روی مقدار کمی از کد برای شناسایی خطاهایی که در کد آزمایش شده رخ می دهد انجام می شود. سپس عملکرد اجرا می شود. این به عنوان "رفاکتور سبز قرمز" نامیده می شود که در آن قرمز به معنای شکست و سبز نشان دهنده عبور است. سپس این مراحل تکرار می شود. اولین هدف یک برنامه نویس این است که بر روی کار مورد نظر تمرکز کند و بر آن غلبه کند.

مراحل مختلف درگیر در چرخه توسعه آزمایش محور عبارتند از:
  • افزودن یک تست: هر ویژگی جدید در TDD با آزمایشی شروع می‌شود که قبل از اجرای هر ویژگی باید در محل قرار داده شود. پیش نیاز نوشتن یک تست قبل از اجرای این ویژگی، درک دقیق نیاز توسط توسعه دهنده است. این از طریق داستان های کاربری و موارد استفاده به دست می آید. بنابراین یک توسعه دهنده قبل از نوشتن کد برنامه، نیاز را درک می کند.
  • همه تست ها را اجرا کنید و بررسی کنید که آیا کد جدید با شکست مواجه می شود: این اطمینان حاصل می کند که مهار تست به درستی کار می کند و تست جدید بدون کد جدید با شکست مواجه نمی شود. این مرحله همچنین آزمون را تأیید می کند و احتمال قبولی آزمون جدید را از بین می برد.
  • Write Code: مرحله بعدی که در ادامه می آید نوشتن کدی است که تست را پاک می کند. کد جدید کامل نیست اما بعداً مطابق با الزامات اصلاح می شود. این به سادگی برای آزمایش طراحی شده است و هیچ ویژگی دیگری ندارد.
  • اجرای تست های خودکار: اگر هر تست تولید شده تست را به راحتی پشت سر بگذارد، به این معنی است که کد تمام مشخصات لازم را دارد. سپس مرحله نهایی چرخه را می توان شروع کرد.
  • کد Refactoring: این شبیه به حذف تکرار است. یک refactoring هیچ یک از عملکردهای موجود را خراب نمی کند و به حذف تکرار بین تولید و کد آزمایشی کمک می کند. اکنون کد در صورت نیاز پاک می شود.
  • تکرار: چرخه مانند موارد قبلی با آزمایش جدید تکرار می شود. شرط ضروری این است که اندازه گام کوچک باشد، با حدود 1-10 تغییر بین هر آزمایش. اگر کد جدید در یک تست جدید شکست بخورد، برنامه نویس باید اشکال زدایی بیشتری انجام دهد. ادغام مداوم نقاط بازرسی قابل برگشت را فراهم می کند.

Ercole Palmeri

خبرنامه نوآوری
مهم ترین اخبار نوآوری را از دست ندهید. برای دریافت آنها از طریق ایمیل ثبت نام کنید.

مقالات اخیر

مداخله نوآورانه در واقعیت افزوده، با یک بیننده اپل در پلی کلینیک کاتانیا

یک عمل جراحی چشم با استفاده از نمایشگر تجاری Apple Vision Pro در پلی کلینیک کاتانیا انجام شد…

3 می 2024

مزایای رنگ آمیزی صفحات برای کودکان - دنیایی از جادو برای همه سنین

توسعه مهارت های حرکتی ظریف از طریق رنگ آمیزی، کودکان را برای مهارت های پیچیده تری مانند نوشتن آماده می کند. رنگ کردن…

2 می 2024

آینده اینجاست: چگونه صنعت کشتیرانی اقتصاد جهانی را متحول می کند

بخش دریایی یک قدرت واقعی اقتصادی جهانی است که به سمت یک بازار 150 میلیاردی حرکت کرده است.

1 می 2024

ناشران و OpenAI توافق نامه هایی را برای تنظیم جریان اطلاعات پردازش شده توسط هوش مصنوعی امضا می کنند.

دوشنبه گذشته، فایننشال تایمز از قراردادی با OpenAI خبر داد. FT مجوز روزنامه نگاری در سطح جهانی خود را صادر می کند…

آوریل 30 2024

نوآوری را به زبان خود بخوانید

خبرنامه نوآوری
مهم ترین اخبار نوآوری را از دست ندهید. برای دریافت آنها از طریق ایمیل ثبت نام کنید.

ما را دنبال کنید