صفحه شخصی سید علا سبزپوش

برنامه نویس دات نت و sql_server --ریاضیات

صفحه شخصی سید علا سبزپوش

برنامه نویس دات نت و sql_server --ریاضیات

زمان نوشتن تست

بخش ۲

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

برای حل این مشکل مفهوم Test Driven development  مطرح شد که که مخفف آن همان TDD  است .

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

اکنون برای فهم بهتر به دوشکل زیر نگاه کنید در تصویر اول توسعه و تست بر اساس کد نویسی اول و در آخر تست انجام می شود



اما در شکل 2 بر اساس TDD  است . ابتدا تست را می نویسیم .همانطور که در شکل پایین می بینید یک حلقه مارپیچی جالبی می بینید که ابتدا تستها نوشته می شوند ترتیب اعمال ما بصورت زیر است

1-نوشتن تست  2-نوستن کدها ۳-refactor 

4-نوشتن تست بعدی



حال با توجه به شکل بالا مختصری توضیح می دهم .

1-ما برای نوشتن تست ابتدایی در واقع تستی را می نویسیم برای حالتی  که کد ما دچار خطا شود مثلا اگر تقسیم دو عدد باشد ما در تست عدد صفر را به مخرج می فرستیم تا نتیجه خطا را مشاهده کنیم در واقع ما در تست درست بودن را تست نمی کنیم به تعبیری دیگر ما  با داده ها قابل قبول تست نمی کنیم بلکه تست ما بر اساس داده ها غیر قابل قبول است تا برای آنها شرایط قابل کنترل فراهم کنیم .

 

2-کدهای خود را بر اساس تستها به گونه ای می نویسیم که بتوانند تستها را به درستی پاس کنند .

 

3-refactor  یعد از اینکه شما تست را پاس کردید ، شما به تست بعدی منتقل می شوید .یا شاید برای خوانایی و بهتر شدن کد عمل refactor  را برروی کدهای خود اعمال کنید .

 

نکته : refactor  یعنی تغییر دادن قطعه ای از کد برای خوانایی بهتر ، بدون آنکه عملکرد آن قطعه کد دچار تغییر شود .

اما برای فهم جالبتر موضوع لینک زیر را قرار دادم که دوستان می توانند برای فهم بهتر آن را مطالعه کنند .


آیا TDD در عمل امکان پذیر می باشد؟



نظرات 1 + ارسال نظر
علی نوبر یکشنبه 18 اردیبهشت‌ماه سال 1390 ساعت 03:37 ب.ظ http://softwaring.blogfa.com

بله در عمل ممکن است و روش کارایی است. تیم ما این روش را تجربه کرده و نتیجه خوبی گرفته است.
هر چند همیشه هزینه پروژه اجازه به کار گرفتن این روش را نمی دهد.
نکته دیگر اینکه این روش بهتر است در کلیه اشکال تست به کار گرفته شود و نه فقط در Unit Test. به عبارت دیگر به همان اندازه که این روش در Unit Test ارزش ایجاد می کند در تست های Fuctional / UAT / Integration و ... نتیجه بخش است.

با تشکر از مطلب
علی

برای نمایش آواتار خود در این وبلاگ در سایت Gravatar.com ثبت نام کنید. (راهنما)
ایمیل شما بعد از ثبت نمایش داده نخواهد شد