مفاهیم تست نرم افزار و آزمایش واحد (Unit Testing)
Loading
صفحه 1 از 7 12345 ... آخرینآخرین
نمایش نتایج: از 1 به 10 از 68

موضوع: مفاهیم تست نرم افزار و آزمایش واحد (Unit Testing)

  1. #1
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,819
    Thanks
    22
    Thanked 47 Times in 42 Posts

    Post مفاهیم تست نرم افزار و آزمایش واحد (Unit Testing)





    Unit Testing یا آزمایش واحد (=تست واحد) روشی است برای آزمایش نرم افزار که در آن قسمت های واحدی از سورس کد پروژه مورد آزمایش قرار می گیرند تا مشخص شود که همان کاری که انتظار می رود را انجام می دهد. منظور از Unit یا واحد، کوچکترین قسمت قابل تست یک برنامه است که می تواند یک تابع یا یک متد باشد. هر واحد به صورت جداگانه مورد آزمایش قرار می گیرد تا از صحت عملکرد آن اطمینان حاصل گردد. در ابتدا شاید انجام تست واحد عملی وقت گیر و اضافی به نظر بیاید، اما اگر شما از صحت عملکرد قسمت های کوچک برنامه خود اطمینان داشته باشید، در آخر کار با باگ ها و مشکلات بسیار کمتری مواجه خواهید شد که این باعث کاهش زمان تولید و تست و در نتیجه بالا رفتن بازدهی و تحویل به موقع خروجی به پروژه به کارفرما می شود.

    تست واحد مربوط به برنامه نویسان است و ربطی به کاربران یا حتی آزمایش کنندگان کیفی یک نرم افزار ندارد. یک برنامه نویس اگر تمام قسمت های کوچک برنامه خود را مورد آزمایش واحد قرار داده باشد، در پایان برنامه ای با حداقل باگ را تحویل کاربران خواهد داد. برای انجام تست واحد در پلت فرم های مختلف ابزارهای مختلفی وجود دارد. برای دات نت می توان فریم ورک های Unit Testing زیادی مثال زد. در ادامه با برخی از فریم ورک های تست واحد برای دات نت آشنا می شوید.

    NUnit : یک فریم ورک خوش ساخت کدباز است که از دنیای جاوا و با پورت کردن پروژه JUnit به دات نت بوجود آمد و با استفاده از Resharper و TestDriven.NET می توان از تمام قابلیت های آن در ویژوال استادیو بهره برد. مستندات خوبی دارد و مثال های بسیار زیادی برای آن در وب وجود دارد.
    MbUnit : فریم ورکی با قابلیت توسعه پذیری بالاست که از آزمایش های واحد پیشرفته پشتیبانی می کند و به توسعه دهندگان اجازه می دهد تا تمام اجزای واحد نرم افزارهای خود را تست کنند و از صحت عملکرد آن ها مطمئن شوند.
    csUnit : یک فریم ورک کدباز و رایگان است که تمام ویژگی های یک فریم ورک تست واحد خوب را یکجا دارد. با تمام زبان های برنامه نویسی دات نت سازگاری دارد و شامل ابزار GUI، پلاگین ویژوال استادیو و خط فرمان برای اجرای آزمایش هاست.
    xUnit : فریم ورک کدباز جدیدی است که به توسعه دهندگان اجازه می دهد تا از TDD به سادگی هر چه تمام تر برای توسعه نرم افزار خود استفاده کنند. شامل ابزار GUI و خط فرمان برای اجرای تست هاست و می توانید با استفاده از TestDriven.NET یا Resharper در ویژوال استادیو از آن بهره ببرید.
    Visual Studio Unit Testing Framework : راه حل مایکروسافت برای انجام آزمایش های واحد در دات نت است که در نسخه های Team System ویژوال استادیو 2005 به بعد وجود دارد. تست های واحد ساخته شده با این فریم ورک می توانند به صورت مستقیم درون ویژوال استادیو اجرا شوند یا با ابزار MSTest.exe از خط فرمان اجرا شوند.
    farasun.wordpress.com
    منبع
پاسخ با نقل قول پاسخ با نقل قول

  • #2
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,819
    Thanks
    22
    Thanked 47 Times in 42 Posts

    Post آشنایی با آزمایش واحد (unit testing) در دات نت

    آزمایش واحد چیست؟

    آزمایش واحد (unit testing) هنر و تمرین بررسی صحت عملکرد قطعه‌ای از کد (که در اینجا واحد نامیده شده است)، به وسیله کدهای دیگری است که توسط برنامه نویس نوشته خواهند شد. عموما این آزمایش‌ها جهت بررسی یک متد تهیه می‌شوند. در این مرحله باید درنظر داشت که هدف، بررسی کارآیی نرم افزار نیست. هدف این است که بررسی کنیم آیا قطعه کد جدیدی که به برنامه اضافه شده است درست کار می‌کند و آیا هدف اصلی از توسعه آن‌را برآورده می‌سازد؟
    برای مثال متدی را توسعه داده‌اید که آدرس یک دومین را از آدرس اینترنتی دریافت شده، جدا می‌سازد. با استفاده از آزمایشات واحد متعدد می‌توان از صحت عملکرد آن اطمینان حاصل کرد.

    اهمیت و مزایای آزمایش واحد کدامند؟


    • کامپایل شدن کد به معنای صحت عملکرد آن نیست. حتما نیاز به روش‌هایی برای آزمایش سیستم وجود دارد. صرفا به شما حقوق داده نمی‌شود که کد بنویسید. به شما حقوق داده می‌شود که کد قابل اجرایی را تهیه کنید.


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


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


    • با استفاده از آزمایش‌های واحد، بدترین حالات ممکن را قبل از وقوع می‌توان در نظر گرفت و بررسی کرد.


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


    • با توجه به امکان اجرای خودکار این آزمایشات، به عنوان جزئی ایده‌آل از پروسه تولید نرم افزار محسوب می‌شوند.


    حد و مرز یک آزمایش واحد کجاست؟

    آزمایش شما، آزمایش واحد نامیده نخواهد شد اگر:

    • با دیتابیس سر و کار داشته باشد.
    • با شبکه در ارتباط باشد.
    • با فایل‌ها کار کند.
    • نیاز به تمهیدات ویژه‌ای برای اجرای آن وجود داشته باشد. مثلا وجود یک فایل config برای اجرای آن ضروری باشد.
    • همراه و همزمان با سایر کدهای آزمایش‌های واحد شما قابل اجرا نباشد.

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





    *توسط وحيد نصيري

  • #3
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,819
    Thanks
    22
    Thanked 47 Times in 42 Posts

    Post مفاهیم تست نرم افزار و خصوصیات تست

    همه ما می دانیم که تست نرم افزار از حیاتی ترین و مهمترین مسایل توسعه نرم افزار است . یکی از مفاهیمی که در تست نرم افزار مطرح می شود . تست واحد یا 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/ دریافت کنید .


  • #4
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,819
    Thanks
    22
    Thanked 47 Times in 42 Posts

    Post کاربرد unit testing چیست و چه تفاوتی با خطایابی(debugging) دارد؟



    همانطور که می دانید مرحله آزمایش نرم افزار یکی از مراحل اصلی تولید است. این آزمایش و بررسی صحت عملکرد برنامه در سطوح مختلفی می تواند صورت گیرد. اما دو مرحله که معمولاً انجام می شود، چنین است:
    1. آزمایش نهایی نرم افزار تولید شده بصورت جعبه سیاه که به آن Integration Testing هم گفته می شود. این آزمایش ها لازم است ولی کافی نیست و در سیستم های بزرگ اصلاً پاسخگو نیست.

    2. آزمایش کوچک ترین قسمت های قابل آزمایش برنامه: به این نوع از آزمایش Unit Testing گفته می شود. در واقع در این روش تک تک اجزای برنامه بصورت جداگانه آزمایش می شوند تا مطمئن شویم که هر کدام درست کار می کنند. در این صورت می توان مطمئن بود که عملکرد کلی سیستم هم درست باشد. این نوع از آزمایش در دسته آزمایش های جعبه سفید قرار داده می شود.

    در Unit Testing، معمولاً یک کلاس یا متد مورد آزمایش قرار می گیرد. اجزاء برنامه بصورت جداگانه مورد بررسی قرار می گیرند نه در ارتباط با دیگر قسمت. بدیهی است نمی شود یک قسمت از برنامه را بدون اتصال به دیگر اجزای برنامه و بصورت مستقل مورد آزمایش قرار داد. از سوی دیگر اگر قسمتی بصورت جداگانه مورد آزمایش قرار نگیرد، در صورت بروز خرابی نمی توان مطمئن شد که خرابی از آن قسمت باشد. برای انجام این کار روش هایی بوجود آمده است که سعی می شود تا اجزای دیگر برنامه شبیه سازی شوند. بدین ترتیب از عملکرد درست آنها در زمان آزمایش مطمئن هستیم.

    البته معمولاً در خط تولیدهای پیشرفته نرم افزار، این آزمایش قسمت های در روال های build نرم افزار قرار داده می شود تا بصورت خودکار اجزای مختلف برنامه مور آزمایش قرار داده شود. در صورت بروز مشکل به توسعه دهنده مربوطه اطلاع داده می شود تا قسمت مورد نظر را اصلاح نماید.

    معمولاً آزمایش های قسمت ها توسط برنامه سازها نوشته می شود. این در حالی است که آزمایش برنامه از دید کاربر معمولاً توسط برنامه سازها انجام نمی شود. مباحث زیادی در مورد آزمایش نرم افزار مطرح می شود که در این جا نمی توان به همه آنها اشاره کرد. فقط اینکه برای بکار گیری Unit Testing باید از framework های جانبی در زبان های مختلف استفاده کنید. برای نمونه در جاوا یک نمونه کاملاً قوی و آسان JUnit و در net. همان NUnit است. البته بدون این framework ها هم می توانید آزمایش قسمت ها را انجام دهید. ولی با استفاده از این framework ها کارتا بسیار ساده تر می شود.
    بعنوان آخرین نکته این که آزمایش قسمت ها را می توان در زمان های مختلفی در مراحل تولید نوشت. اما یکی از معروف ترین و موفق ترین روش های unit testing بنام TDD توصیه می کند تا آنها را پیش از نوشتن برنامه و کلاس ها بنویسید.

    بروز رسانی
    اما در مورد تفاوت Unit Testing و Debugging این دو اصلاً کاربردهای متفاوتی دارند. اما به چند تفاوت زیر توجه کنید:

    1. debug بصورت interactive و توسط توسعه دهنده انجام می شود. در حالیکه Unit Testing معمولاً بصورت خودکار و بدون دخالت برنامه ساز انجام می شود. (در موارد زیادی در مراحل Build این کار انجام می شود.)

    2. debug برای رفع نهایی مشکل قسمت برنامه انجام می شود. یعنی برنامه ساز متوجه خطای برنامه شده است و سعی می کند با debug خطای برنامه را بصورت دقیق مشخص کند و رفع کند. ولی در Unit Testing هدف تنها این است که وجود خطا در یک قسمت برنامه به برنامه ساز اطلاع داده شود و هیچ صحبتی از نوع خطا و جزئیات آن نیست. تنها اینکه خطایی در قسمت مربوطه رخ داده است. 3. روش اشکالزدایی در debug بصورت جعبه سفید است یعنی برنامه ساز بصورت کامل می تواند جزئیات را مورد بررسی قرار دهد. در حالیکه در Unit Testing آزمایش بصورت جعبه سیاه انجام می شود. یعنی ورودی ها متد تأمین می شود و متد مربوطه باید خروجی ها را تحویل دهد.

  • #5
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,819
    Thanks
    22
    Thanked 47 Times in 42 Posts

    Exclamation قبل از رفع باگ، براي آن تست بنويسيد

    از دقت كردن در نحوه اداره پروژه‌هاي خوب و بزرگ در سطح دنيا، مي‌توان به نكات آموزنده‌اي رسيد. براي مثال NHibernate را درنظر بگيريد. اين پروژه شايد روز اول كپي مطابق اصل نمونه جاواي آن بوده، اما الان از خيلي از جهات يك سر و گردن از آن بالاتر است. پشتيباني LINQ را اضافه كرده، خودش Syntax جديدي را به نام QueryOver ارائه داده و همچنين معادلي را جهت حذف فايل‌هاي XML به كمك امكانات جديد زبان‌هاي دات نتي مانند lambda expressions ارائه كرده. خلاصه اين تيم، فقط يك كپي كار نيست. پايه رو از يك جايي گرفته اما سبب تحول در آن شده. از اهداف پروژه‌هاي سورس باز هم همين است: براي هر كاري چرخ را از صفر ابداع نكنيد.

    اگر به نحوه اداره كلي پروژه NHibernate‌ دقت كنيد يك مورد مشهود است:

    • تمام گزارش‌هاي باگ بدون Unit test نديد گرفته مي‌شوند.
    • از كليه بهبودهاي ارائه شده (وصله‌ها يا patch ها) بدون Unit test صرفنظر مي‌شود.
    • از كليه موارد جديد ارائه شده بدون Unit test هم صرفنظر خواهد شد.


    بنابراين اگر در issue tracker اين تيم رفتيد و گفتيد: «سلام، اينجا اين مشكل هست»، خيالتان راحت باشد كه نديد گرفته خواهيد شد.

    سؤال : چرا اين‌ها اينطور رفتار مي‌كنند؟!

    - وجود Unit test دقيقا مشخص مي‌كند كه چه قسمت يا قسمت‌هايي به گزارش باگ شما مرتبط هستند. نيازي نيست حتما بتوانيد يك خطا را با جملات ساده شرح دهيد. اين مساله خصوصا در پروژه‌هاي بين المللي حائز اهميت است. ضعف زبان انگليسي همه جا هست. همينقدر كه توانسته‌ايد براي آن يك Unit test بنويسيد كه مثلا در اين عمليات با اين ورودي،‌ نتيجه قرار بوده بشود 10 و مثلا شده 5 يا حتي اين Exception صادر شده كه بايد كنترل شود، يعني مشكل را كاملا مشخص كرده‌ايد.
    - وجود Unit tests ، انجام Code review و همچنين Refactoring را تسهيل مي‌بخشند. در هر دو حالت ياد شده، هدف تغيير كاركرد سيستم نيست؛ هدف بهبود كيفيت كدهاي موجود است. بنابراين دست به يك سري تغييرات زده خواهد شد. اما سؤال اينجا است كه از كجا بايد مطمئن شد كه اين تغييرات، سيستم را به هم نريخته‌اند. پروژه‌ي جاري چند سال است كه در حال توسعه است. قسمت‌هاي زيادي به آن اضافه شده. با نبود Unit tests ممكن است بعضي از قسمت‌ها زايد يا احمقانه به نظر برسند.

    - بهترين مستندات كدهاي تهيه شده، Unit tests آن هستند. براي مثال علاقمند هستيد كه NHibernate را ياد بگيريد؟ هرچه مي‌گرديد مثال‌هاي كمي را در اينترنت در اين زمينه پيدا مي‌كنيد؟ وقت خودتان را تلف نكنيد! اين پروژه بالاي 2000 آزمون واحد دارد. هر كدام از اين آزمون‌ها نحوه‌ي بكارگيري قسمت‌هاي مختلف را به نحوي كاربردي بيان مي‌كنند.
    - وجود Unit tests از پيدايش مجدد باگ‌ها جلوگيري مي‌كنند. اگر آزمون واحدي وجود نداشته باشد، امروز كدي اضافه مي‌شود. فردا همين كد توسط عده‌اي ديگر زايد تشخيص داده شده و حذف مي‌شود! بنابراين احتمال بروز مجدد اين خطا در آينده وجود خواهد داشت. با وجود Unit tests، فلسفه وجودي هر قسمتي از كدهاي موجود پروژه دقيقا مشخص مي‌شود و در صورت حذف آن‌، با اجراي آزمون‌هاي خودكار سريعا مي‌توان به كمبودهاي حاصل پي‌برد.

    *توسط وحيد نصيري

  • #6
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,819
    Thanks
    22
    Thanked 47 Times in 42 Posts

    پیش فرض Setting up Visual C#2010 Express with NUnit

    This example of how to set up Visual C# 2010 Express to run NUnit .
    First, the directory layout of the Joger project looks like this:


    The highlighted nunit.framework.dll is the NUnit assembly that the test project Joger.Test must have as a reference:


    In the “Post-build event command line” text box of Joger.Test, the highlighted command reads:

    $(SolutionDir)External\NUnit-2.5.9.10348\bin\net-2.0\nunit.exe $(TargetPath) /run With this setup, I can press F6 to build my solution and get NUnit to run my tests automatically after a successful build:



    This, however, doesn’t work on devices that only support the .NET Compact Framework. Microsoft has a special built-in unit testing story for those with Visual Studio 2008. More on that in another post.


  • #7
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,819
    Thanks
    22
    Thanked 47 Times in 42 Posts

    پیش فرض


    ----------------------------------------------------------



    ........................................
    ویرایش توسط admin : Monday 8 October 2012 در ساعت 12:59 PM

  • #8
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,819
    Thanks
    22
    Thanked 47 Times in 42 Posts

    پیش فرض



  • #9
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,819
    Thanks
    22
    Thanked 47 Times in 42 Posts

  • #10
    مهرداد تاجيك - مدير سایت Array admin آواتار ها
    تاریخ عضویت
    Thursday 30 June 2005
    محل سکونت
    تهران - ایران
    نوشته ها
    1,819
    Thanks
    22
    Thanked 47 Times in 42 Posts

    Exclamation ReSharper :automatically detects unit tests of NUnit in your projects

    Unit Testing

    Running and Debugging tests



    ReSharper automatically detects unit tests of NUnit and MSTest frameworks in your projects. Other unit testing frameworks such as xUnit.net and MSpec are supported via ReSharper plug-ins.
    Next to declarations of test classes and single tests, ReSharper adds special icons on the left gutter of the editor window. Click these icons to run or debug tests.
    Tests can also be run from the context menu. In addition, an arbitrary set of unit tests can be run or debugged from the Visual Studio's Solution Explorer. Just right-click the project or solution and select Run unit tests or Debug unit tests.

    Unit Test Explorer




    ReSharper presents Unit Test Explorer — a structured list of unit tests for reviewing the structure of tests in your whole solution. The tree is available via the ReSharper | Windows menu and is quickly populated after you build your project. Using Unit Test Explorer, you can run any combination of tests in one or more unit test sessions.


    Unit Test Sessions



    ReSharper runs unit tests in the Unit Test Sessions window. It is designed to help you run any number of unit test sessions, independently of each other, as well as simultaneously. Sessions can be composed of any combination of tests. In the debugging mode, only one session can be run at a time.
    The unit test tree shows the structure of tests belonging to a sessions, which you can ****** to show only passed, failed or ignored unit tests. You can navigate to the code of any unit test by double-clicking it.
    The progress bar and the status bar display the current progress. You can stop, run or re-build and re-run unit tests at any time.
    The preview pane lets you analyze test results and navigate from a failed test's output to the code lines that originated the exception, all with a single click.

    Profiling Unit Tests with dotTrace Performance




    You can also quickly profile the performance of unit tests from Visual Studio via JetBrains dotTrace Performance, a powerful .NET profiling tool.
    To profile tests, you will need to install dotTrace Performance. You will then be able to start profiling directly from the editor using the sidebar marks that ReSharper adds for test classes and individual tests.


  • صفحه 1 از 7 12345 ... آخرینآخرین

    علاقه مندي ها (Bookmarks)

    علاقه مندي ها (Bookmarks)

    مجوز های ارسال و ویرایش

    • شما نمیتوانید موضوع جدیدی ارسال کنید
    • شما امکان ارسال پاسخ را ندارید
    • شما نمیتوانید فایل پیوست کنید.
    • شما نمیتوانید پست های خود را ویرایش کنید
    •