در ادامه‌ی مقاله‌ی قبلی که در خصوص چیستی TDD، ادعای رایج پیرامون آن و نکاتی چند پیرامون سرعت و کیفیت و تست‌های خودکار در CI صحبت شد، در این مقاله قصد دارم به مشکلاتی که TDD میتواند حل کند بپردازم و به این نکته اشاره‌کنم که TDD در نهایت، یک سیلور بولت نیست. در آخر، بحث را در خصوص سنجه‌های اندازه‌گیری موفقیت در TDD و معرفی شاخص‌های کمی و کیفی آن تکمیل خواهم کرد.
روش TDD در چهار بعد میتونه موثر نشان داده شود: کیفیت داخلی کد / کیفیت خارجی کد / کیفیت تست / بهره‌وری
مشکلاتی که در کیفیت داخلی معمولا پیش می‌آید:
۱- شلختگی در کد
۲- وجود افراد کلیدی
۳- آنبوردینگ سخت
۴- رشد پیچده
۵- تاخیر بابت عدم فهم کد
مشکلاتی که در کیفیت بیرونی معمولا پیش می‌آید:
۱- تعداد زیاد ثبت Bugها
۲- ریپورت‌های فراوان مشکلات
۳- فرصت کافی نداشتن دولوپر برای توسعه جدید
۴- regression (پسرفت) انجام کاری و مشکل‌دار بودن مجدد آن
به کمک TDD کیفیت درونی و بیرونی کد(بهبود مشکلات فوق) افزایش خواهد یافت. تعداد خطای کمتر و فیکس سریعتر خطاهای احتمالی در کنار سرعت بیشتر تیم را شاهد خواهیم بود. همچنین افزایش‌دهنده‌ی مسئولیت و حس تعلق دولوپر جهت نوشتن تست‌های دقیق‌تر و پاس کردن آنها و در مجموع با نوشتن کدها و تست‌های باکیفیت‌تر منجر به افزایش بهره‌وری خواهیم شد.
تی‌دی‌دی یا TDD در نهایت یک silver bullet یا علاج قطعی دردی نیست.
اگر نگاه کوتاه‌مدت به بهره‌وری سریع یا speed to market داریم و اولویت‌مون اینه‌که میخاهیم برای عقب‌نموندن در بازار، زودهنگام ریلیز داشته باشیم، و قصد داریم بست‌پرکتیس‌هایی نظیر TDD را فدا کنیم، باید مراقب آن بود. و در فرصت مقتضی به آن رو آورد.
بنابراین همانطور که در مقاله‌ی قبل در خصوص نتایج تحقیقات اثربخشی TDD در سازمان‌ها صحبت شد، TDD برای کوتاه‌مدت انتخاب ناکارآمدی است.
استفاده از TDD در کوتاه مدت کاهنده و در درازمدت افزاینده بهره‌وری خواهد بود.
شناسایی انگیزه‌ها برای استفاده از TDD و درآوردن شاخصه‌هایی برای اندازه‌گیری آنها و البته دادن زمان کافی برای نشستن نتایج در عمل هم اهمیت زیادی دارد.
برای شاخص quantitativeها (کمی‌ها) از flow metricsهایی نظیر Cycle time/Number of Release یا Time spent on bugs استفاده کرد و از Code Coverage پرهیز کرد که مقیاس بسیار غیردقیقی است.
مفهوم code coverage اینست که چقدر کدهامون تحت نظارت یونیت‌تست‌ها هستند.
از بعد Qualitativeها (کیفی) میشود به Team happiness/Team communication/Sense of ownership رسید.
نکته‌ی مهم اینکه از بکارگیری تعداد زیادی شاخص پرهیز کنیم.
با توجه به مطالب ارائه‌شده استفاده از TDD مانند استفاده از هر الگو و بهترین‌روشی بایستی آگاهانه و در جای صحیح خود باشد و قطعا استفاده از آن نسخه‌ی واحدی برای هر شرایطی نیست.
تجربه‌ی شما در استفاده از TDD چه بوده است؟
