
Self-Testing Code اصطلاحی است که مارتین فولر در کتاب Refactoring خود از آن نام برده است و اشاره به روش هایی دارد که تست های همه جانبه برای کدها نوشته می شود که به وسیله یک command می توانیم تست ها را اجرا کنیم .این روش باعث می شود که اطمینان حاصل کنیم که تست ها میتوانند باگهای پنهان را آشکار کنند.
به عبارتی زمانی که شما در حال نوشتن نرم افزار خود هستید همزمان یک bug detector هم توسعه خواهید داد.به عبارتی تغییرات در کد با اجرای تست ها روی کد،آزمایش می شود و اطمینان از کد بالا خواهد رفت.
نوشتن تست برای کد بخش جدایی ناپذیر از فرایند Continuous Integration است.به عبارتی نداشتن تست برای کدها یعنی نداشتن Continuous Integration و به تبع آن نداشتن Continuous Delivery.
از مزایای تست نویسی برای کدها کم کردن تعداد باگ در محیط عملیات خواهد بود.فرایند نوشتن تست به این صورت است که همان زمان که برنامه نویس در حال نوشتن کد می باشد،به نوشتن تست نیز فکر کند.
اما مزیت اصلی تست نویسی نه صرفا کم کردن تعداد باگها در محیط عملیات،که جلوگیری از بوجود آمدن مشکل در زمان تغییرات خواهد بود.حتی خود اصلاح باگها نیز می تواند باعث بوجود آمدن باگهای جدید در سیستم شود.در همچین شرایطی نه تنها اضافه کردن ویژگی جدید ،که حتی Refactoring که نیز به شدت ترسناک می شود و باعث می شود که بدهی فنی بوجود آوریم .این ما را در یک مارپیچ بدتر شدن قرار می دهد.اما با نوشتن تست داستان کاملا متفاوت خواهد بود.
Self-Testing Code را بعضا با موضوع TDD یکسان در نظر میگیرند ولی TDD رویکردی است که تست نویسی را بهینه تر می کند ولی این بدان معنا نیست که اگر TDD استفاده نکنیم حتما اشتباه کرده ایم.می توان تستها را بعد از نوشتن کد نوشت به شرط آنکه تا زمانی که تست نوشته نشده کار را تمام شده در نظر نگیریم.
تست نویسی رویکرد تیم را به رفع باگ تغییر خواهد بود.بدین صورت که ابتدا بعد از اعلام باگ ابتدا تست یا تست هایی نوشته خواهد شد که باگ را شبیه سازی کند سپس به رفع باگ اقدام خواهیم نمود.همچنین در این صورت وجود باگ در عملیات به معنای صرفا مشکل در کد نویسی نیست و باید رویکرد تست نویسی نیز مورد بررسی قرار گیرد.