مباحث مهندسی نرم‌افزار

[سید علا سبزپوش]

بخش 1

مفاهیم تست و خصوصیات تست .

 

همه ما می دانیم که تست نرم افزار از حیاتی ترین و مهمترین مسایل توسعه نرم افزار است . یکی از مفاهیمی که در تست نرم افزار مطرح می شود . تست واحد یا unit test  است . یعنی نوشتن تستهایی برای هر جز نرم افزار است .

 

تعریف تست واحد  unit test

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

چیزی که این وسط اهمیت فراوانی دارد . نحوه نوشتن تست خوب .

 

اهمیت نوشتن یک تست خوب تا بدان جا ست که اگر تست بدی انجام شود ، همانند آن است که هیچ تستی انجام نشده است .

خصوصیات تست خوب :

 

1-باید خودکار و قابل تکرار باشد . شما هر وقت اراده کنید باید بتوانید تست خود را دوباره اجرا کنید.

2-اجرا و اعمال آن باید آسان باشد . تست خوب باید براحتی قابل اجرا باشد چرا که ما بارها به اجرای آن نیاز دارید پس فرآیند آن باید راحت و ساده باشد .

3-یکبار نوشته شود و در آینده فقط اجرا شود ،

4-توسط هر فردی قابل اجرا باشد ، از آنجا که ممکن است پروژه گروهی باشد لذا تست ما باید بگونه نوشته شود که هر توسعه دهنده دیگری بتواند براحتی آن را اجرا کند .

5-زمان تست کوتاه باشد ، نباید تست ما زمان بر باشد . چون در این حالت دیگر هیچ کس حاضر به اجرای آن تست نخواهد بود .

 

ادغام تستها

در بحث بالا گفتم که تست واحد برای هر واحد نوشته می شود اما نرم افزار ما ممکن است از صدها و هزاران واحد کوچکتر دیگری تشکیل شده باشد .تستها باید بگونه ای نوشته شوند که قابل ادغام با یکدیگر باشند ، ما می دانیم نرم افزار از واحدهای به هم متصل و زنجیرواری تشکیل می شود .

لذا باید تستهای ما هم این امکان را داشته باشند که با هم ادغام شوند و در مواقع لزوم با هم اجرا شوند . فراموش نکنیم که اهمیت نوشتن تستهایی که زمانبر نباشد در ادغام تستها کاملا مشخص است .

[سید علا سبزپوش]

بخش ۲

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

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

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

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



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

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

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


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

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

 

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

 

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

 

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

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


http://blog.irscrum.com/?p=800

[سید علا سبزپوش]

Frameworks for Unit testing


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

 

بدون ابزار تست چه محدودیتهایی خواهیم داشت

 

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

 

2-تست ما تکرار پذیر نیست . از مهمترین نکات تست قابلیت تکرار است . به طوری که همزمان با توسعه نرم افزار تستها باید تکرار شوند .

 

3-شما نمی توانید برای تمام کد هایتان تست بنویسید . در واقع مجتمع سازی تستها ، بدون استفاده از ابزار های تست کاری سخت و غیر ممکن است .

 

با استفاده از ابزار تست چه مشکلاتی حل می شود .

 

1-تستها قانونمند می شود و به آسانی نوشته می شوند .چرا که این ابزارها دارای مجموعه ای از کتابخانه های آماده برای تسهیل عمل تست هستند.

 

2-اجرای یکباره و چند باره تست آسان می شود . در واقع این ابزارها به کمک امکاناتی که دارند تکرار پذیری تست را آسان می کند و شما می توانید پیشرفت تست و یا حالتهای تست را ارزیابی کنید

 

3-مشاهده نتایج حاصل از تست . شما می توانید با کمک ین ابزارها بدانید که چه تعداد تست در حال اجرا است یا اجرا شده است .کدام تست با مشکل مواجه شده و دلیل شکست تست چه بوده و.....

 

از چه ابزاری استفاده کنیم .

ابزارهای تست فراوان است اما من می خواهم بر روی ابزار xUnit  تمرکز کنم و سعی می کنم به معرفی این ابزار بپردازم . این ابزار به آنها xUnit Frameworks  گفته می شود .که حرف اول x   نشان دهنده زبان مورد پشتیبانی است مثلا برای زبان جاوا jUnit   و برای دات نت NUnit  و ..

 

شما می توانید این ابزار را از سایت http://www.nunit.org/  دریافت کنید .