تست کد و نرم افزار

چند وقت پیش شنیدم که شهرداری برای تحویل پروژه های نرم افزاری از پیمانکارها از TFS استفاده می کند. یعنی به جای آن که DLL و نسخه اجرایی دریافت کند، آنچه که پیمانکار روی سرور TFS کامیت کرده را دریافت و خودش Build و در محل مورد نظر نصب می کند. اگر این موضوع واقعا به همین شکل اتفاق افتاده باشد خیلی جالب و البته مفید است. این کار نشان می دهد که سواد نرم افزاری در سطح کشور و به خصوص در بخش دولتی و حاکمیتی بالا رفته است. و این خبر خوبی است.

همین چند روز پیش مشابه این خبر را در مورد یک سازمان دولتی شنیدم. گویا این که Developer های پیمانکار سورس را روی سرور TFS سازمان Check in می کنند و دیگر کاری به Publish ندارند. مثل این که Deploy به طور کامل توسط کارفرما انجام می شود.

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

این اخبار را که می شنوم، ناباورانه از خودم می پرسم که آیا ممکن است روزی برسد که Automated Test هم مثل قضیه Source Control در اذهان جا بیفتد بلکه کمی کیفیت نرم افزارها بالاتر برود؟ حالا فرقی نمی کند که این ابتکار از طرف شرکت ها و پیمانکارها اتفاق بیفتد یا از طرف دولت و کارفرماها. هر کسی که موفق بشود تست های مکانیزه از جمله Unit Test را جا بیندازد، دنیا و آخرتش آباد است!

در تیم های برنامه نویسی موضوعی وجود دارد به اسم پدیده الاکلنگی. این پدیده نامیمون یعنی وقتی باگی در یک جای نرم افرار برطرف می شود، باگ دیگری در یک جای دیگر بیرون می زند. درست است که کیفیت پایین کد مقصر اصلی این قضیه است، اما اگر Automated Test کافی وجود می داشت، خراب شدن بخش دیگر نرم افزار در همان لحظه تغییر قابل مشاهده بود. دیگر نیازی نبود که پروژه به دست مشتری برسد تا او هم پس از آبروریزی به مجری اعلام کند.

وضعیت خیلی از پروژه ها به این شکل است که بعد از مدت زمانی که کد بیس stable شد، تغییر در آن خیلی سخت می شود. به عبارت دیگر، کمتر کسی زیر بار تغییر در کد می رود. چون معلوم نیست که تغییر در فلان بخش کد، چند جای دیگر را تحت تاثیر قرار می دهد. اگر Unit Test به تعداد کافی و با Coverage مناسب وجود داشته باشد، ترس از تغییر هم بسیار کاهش پیدا خواهد کرد. با هر تغییری می شود چک کرد که آیا همه تست ها همچنان سبز است یا خیر.

نوشتن Unit Test زمان بر است، نگهداری آن هم وقت گیر و پر دردسر است. اضافه کردن Unit Test به یک پروژه به طور تخمینی 20 تا 30 درصد به زمان توسعه می افزاید. علاوه بر این، تست نوشتن مهارت می خواهد و باید به طرز مناسبی نوشته شود در غیر این صورت اتلاف منابع خواهد بود. اما زندگی با Unit Test بسیار زیباتر و مطمئن تر خواهد بود.

امیدوارم روزی هم برنامه نویس ها، هم تیم ها، هم شرکت ها و هم مشتری ها و کارفرماها به اهمیت و ارزش تست های اتوماتیک و به طور کلی تر کیفیت کد و نرم افزار پی ببرند و آن را در روتین روزانه شان جا بدهند.

اصل این نوشته در این آدرس منتشر شده است.