تازه های سایت

مقدماتی بر آزمون واحد یا Unit Testing قسمت اول

سلام دوستان خوبم. امیدوارم حالتون خوب باشه. احتمالا اگه برنامه نویسی رو جدی تر پیگیری کرده باشید، یه چیزایی از unit testing به گوشتون خورده. در این سری از آموزش‌ها سعی داریم این بخش از آزمون نرم افزارها رو با هم یاد بگیریم. تاکید کردم با هم به این دلیل که منم چیزی بلد نیستم. من یه چیزایی میگم شما هم بیایید گیر بدید اینجاش رو اشتباه کردی! تو سر و کله هم بزنیم بلکه یه چیزی یاد بگیریم.

مشکل از کجا شروع می‌شه

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

خب حالا چه تغییراتی ممکنه توی کد ایجاد بشه؟

معمولا ما به چهار دلیل زیر کدمون رو تغییر می‌دیم:

  1. برای اضافه کردن یک ویژگی جدید به کد
  2. برای رفع یک باگ
  3. برای اصلاح معماری نرم افزار
  4. بهینه‌سازی استفاده از منابع مثل CPU یا حافظه

در زمانی که ما قصد تغییر در یک کد، به دلایل بالا را داریم، معمولا ممکن است در حال تغییر یک یا چند مورد از موارد زیر باشیم:

  1. ساختار برنامه. تغییر در کلاس‌ها و ایجاد ساختارهای جدید و یا شکستن ساختارهای پیچیده
  2. عملکرد. ایجاد تغییر در نحوه عملکرد برنامه
  3. تغییر در استفاده از منابع.

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

ولی در هنگام اصلاح معماری نرم افزار، یا اصلاح استفاده از منابع، نباید تغییری در عملکرد برنامه ایجاد شود.  به این عمل Refactoring می‌گویم.

منظورمان از Refactoring تغییراتی است که در کد می‌دهیم و هدفمان اصلاح ساختار و یا بهینه سازی نرم‌افزار است و قصد داریم عملکرد ثابت بماند.

مشکل بعدی چیه؟

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

مشکل اصلی در تغییر یک بخش از برنامه، ترس از ثابت ماندن رفتار مابقی برنامه است.

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

پس بهتره قبل از هر تغییر سه سوال زیر رو از خودمون بپرسیم:

  1. چه تغییراتی قصد داریم بدهیم؟
  2. چگونه تایید می‌کنیم که تغییراتی که دادیم به درستی انجام شده است؟
  3. چگونه تایید می‌کنیم که هیچ جای دیگری را تغییر نداده‌ایم؟

خب پس چه کنیم؟

معمولا به دو طریق می‌توانیم در یک برنامه تغییر ایجاد کنیم:

  1. تغییر بده و دعا کن!
  2. محافظت کن و تغییر بده!

حالت اول رو خوب بلدیم 🙂 تغییر می‌دیم و دعا می‌کنیم که خدایا، بخش‌های دیگه ثابت مونده باشن. یا خیلی با احتیاط می‌ریم جلو. از اون احتیاط های خرکی. مثل جراحی که به دلیل احتیاط، داره با کارد میوه‌خوری یه بدبختی رو جراحی میکنه. خب این دیگه اسمش خریته نه احتیاط.

تغییر در نرم‌افزار دل شیر میخواد 😀 با کارد میوه خوری نمیشه رفت جلو. پس شیوه اول رو می‌بوسیم میذاریم کنار.

ولی شیوه دوم، شیوه‌ای هست که قصد داریم توی این پست‌ها بیشتر در موردش صحبت کنیم. خیلی مختصر شیوه دوم رو تعریف کنیم: قبل از تغییر یه بخش، اون بخش رو با تست محافظت کن، بعد اقدام به تغییر کن.

پس شعار ما تا قسمت بعدی این باشه:‌ اول محافظت، بعد تغییر.

فعلا خداحافظ

۲۴ total views, 1 views today

Print Friendly
Facebook0Google+0Twitter0LinkedIn0

درباره‌ی سعید دادخواه

یه برنامه نویس !

جوابی بنویسید

ایمیل شما نشر نخواهد شد.خانه های ضروری نشانه گذاری شده است. *

*


پنج × = 30