در این مقاله دوقسمتی به اینکه TDD (Test-driven development) چیست نگاهی می‌اندازم و از مساله‌ی همیشگی سرعت یا کیفیت حرف میزنم. از ادعاهای رایج و نتایج تحقیقات در خصوص TDD گفتم و در نهایت مورد تست اتوماتیک در CI پایپ‌لاین بررسی کردم.
ارائه یک محصول کم‌خطا و سریع به مشتری نیاز به وجود توامان سرعت و کیفیت است.
رابرت مارتین میگه تنها راهی که میشه سریع بود، اینه‌که با کیفیت بری. در واقع با کاستن خطاها، بهره‌وری بالاتر میرود که نتیجه‌ی آن افزایش کیفیت است.
The only way to go fast is to go well.
تی‌دی‌دی نه کاری به تکنولوژی داره و نه حتی به مساله. یک مهارته از فکر کردن به مساله‌ای که در حال حل آن هستید قبل از اینکه اونو واقعا حلش کنید. بنابراین زمان کافی خواهیم داشت که به مساله‌ی واقعی فکر کنیم.
توسعه‌های کوتاه است که با چند قدم قرمز - سبز - ری‌فکتور تکرار میشود.
قرمز: برای کاری که انتخاب کردیم و سیستم باید پیاده‌سازی کنه، یک تست مینویسیم و به خطا خوردن تست میشینیم.
سبز: تلاش میکنیم که یک پیاده‌سازی ساده کنیم که تست را پاس کند.
ری‌فکتور: بعد که تست سبز پاس شد برمیگردیم و سعی میکنیم بهبود بدیم کد را.
این سه مرحله روی هر تسک کوچک انجام و ادامه میابد تا یک تسک بزرگتر انجام شود.
مثل هر چیز دیگری TDD نیز موافق و مخالف دارد. عده‌ای میگویند که زیاد طول میکشد و سربار مازادیست بر تیم. از طرف دیگر عده‌ای دیگر هستند که میگویند که بخاطر تولید کدهای باکیفیت و افزایش بهره‌وری توسعه محصول کار ارزشمندی است.
نتایج تحقیقات میدانی فراوانی نشان میدهد که هر دو طرف درست میگویند.
دو نتیجه‌ی عمومی از تحقیقات: TDD منجر به افزایش کیفیت کد و تست‌ها میشوند. / TDD در کوتاه مدت کاهنده و در درازمدت افزاینده بهره‌وری خواهد بود.
واقعیت اینست که TDD باید روی برخی مسائل اجرا بشه تا هزینه‌اش، ارزش داشته باشد. و در واقع یک نسخه‌ی متعالی بر هر سناریویی نیست.
همه سازمان‌ها برای کدهای خودشون تست مینویسند که کد پیاده‌سازی شده را بررسی کنند و محصولی تمیز تحویل میشتری شود. معمولا واحد QA سازمان مسئول تست است که محصول کار کند. وقتی یک تست بصورت دستی انجام میشه verb میشه ولی میتونه هم با انجام خودکار به صورت یک noun شناسایی بشود.
تست Automated قطعه کدی است که کد پیاده‌سازی شده را وریفای میکند و یک Assertionی مطرح میکند که کد به‌درستی کار میکند.
ارزش استفاده از Automated test این است که به‌سادگی قابل تکرار باشد.
تغییر QA با تست‌های خودکار و CI
در کنار تست های خودکار نقش QA میتونه موثر باشد. ماشین خیلی بهتر میتواند کارهای روتین تست دستی را انجام دهد و بنابراین انسان باید موارد پیچیده‌تر را هندل کند. مانند مواردی که مرتبط به concurrency یا security هستند.
در این حالت QA نقشش از حالت انفعال به فعال یا Proactive تبدیل میشود. و تست‌های خودکار باعث میشوند همه کدها تست شوند و سریعتر فیچرها ریلیز شوند.
اغلب این تست‌های در CI انجام خواهد شد و تنها در صورتیکه همه‌ی تست ها پاس شد امکان Deploy وجود دارد.
تی‌دی‌دی یک فرآیند است و میتواند با هر نوع تستی بیاید. در حالیکه یونیت تست فقط یک مدل از تست است.
ادامه دارد ...
در قسمت بعد مشکلاتی که TDD در سازمان‌ها میتواند یا نمیتوانند مرتفع کند را بررسی خواهیم کرد. همچنین برای شروع و سنجش اثربخشی و بهره‌وری استفاده از TDD راهکارهایی را بررسی خواهیم کرد.
