تور آشنایی با پلتفرم خودکار قسمت پانزدهم

متن صدای ویدیو :

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

اگر یادتان باشد در ویدیوهای قبلی Debug را توضیح دادم و گفتم برای Debug یک DLL برای این که شما بتونید از Breakpoint خودکار یا Breakpoint visual studio استفاده کنید حتما باید اون DLL را در mod Debug ، منتشر کنید تا بتوانید Breakpoint های خودکار یا visual studio استفاده کنید. ممکن است یک زمانی باشد که برنامه نویس دیگر برای شما کد می زند و شما علاقه ای ندارید علاوه بر دسترسی Compile دسترسی publish هم به او بدهید. در این جور مواقع شما می توانید از Unit Test هم استفاده کنید حالا علاوه بر آن کار اصلی که Test نوشتن دارد و می تواند نرم افزار را قبل از تحویل به مشتری تست کند از آن تست به عنون Document هم استفاده کنید برای خود platform این خود یک قابلیت دیگری برای Debug برنامه تان دارد.

خود پلتفرم را که نصب می کنید در framework خودکار یک DLL  تست نمونه sample  برای شما وجود دارد به نام KS.Dynamic.UnitTest.dll وقتی آن را انتخاب می کنیم می بینیم که از نوع Assembly test است و مکان ذخیره سازی آن Output است و بقیه ی چیزهایش شبیه DLL های compile نشده معمولی است که ما کد می نوشتیم. کد آن هم دقیقا همانطور است. دوباره جایگذاری دارد، بعد در قسمت وابستگی ها ، آن DLL که می خواهیم برای آن test بسازیم آن را باید reference کنیم یعنی به وابستگی های DLL ، test مان اضافه کنیم اما ساختارش یک تفاوت کوچکی با DLL compile نشده دارد .

ما در اینجا حتما باید تا سطح Method را تعریف کنیم یعنی شما اگر دقت کنید این فضای نام و این Unit Test که کلاسمان است این متدمان Test do Test متدهای Test هم معمولا با کلمه ی test شروع می شود به علاوه ی آن متد قابلیت هایی که می خواهند test کنند. هر متد test تان باید یک متد از DLL یا یک سری قابلیت ها و متدهای آن DLL را test کند و الان در اینجا قرار است که DLL business ما یک متدی دارد به اسم Do test که این قرار است test do test آن متد را تست کند.

در کد این متد خروجی باید حتما  از نوع bool باشد یعنی یا تست ما با موفقیت است true بر میگردیم یا با شکست مواجه می شود که با False بر می گردیم و پارامترهای ورودی حتما باید از نوع string باشد. من داخل بدنه این متد تست آمده ام test class را که در اصل یک class است در لایه ی business ، new کرده ام و متد Do test اش را call کرده ام با پارامتر ورودی که همان string باشد و حالا چون این خودش True , False بر می گرداندند. من همان Return این را گذاشته ام و این True , False برگرداندن دست خودتان است. حالا اگر اینجا خطایی اتفاق افتاد خطا log می شود یا می توانید API Debug استفاده کنید و خطایتان را ذخیره کنید و بروید خطایتان را ببینید یا از log بروید و خطا را نگاه کنید. ولی اگر موفقیت آمیز بود true برگردانید.

نکته ی مهمی که اینجا وجود دارد شاید شما بگویید که do test من method business ، یه complex object به عنوان ورودی می گیرد ، قرار نیست که فقط String باشد ، اصلا" ممکنه یک عدد بگیره یا هر چیز دیگه ایی ، ببینید پارامتر ورودی حتما" باید از نوع string باشه ولی در اینجا خودتون می تونید if یا switch بگذارید و بگید مثلا اگر String=A بود New complex object با این Data، اگر B بود New complex object با یک Data دیگری بعد یک بار با A را تست کنید و یک بار B را تست کنید ببینید نتیجه کدام true است و نتیجه ی کدام False است. پس در اینجا برای شما محدودیت وجود ندارد، این نوع String که حتما آن متدی هم که می خواهید تست کنید باید از نوع String باشد، نه شما خودتان در اینجا کد CSharp هست و می توانید آن complex object را بسازید و پاس بدهید براساس این پارامتر ورودی که می آید تصمیم بگیرید که چه مقادیری برای تست باید ارسال شود. این در اصل فقط یک Flag است که بدانید چه چیزی را باید تست کنید.

من می آیم در خود DLL و اینجا از قسمت Compile با ساخت وابستگی ها را می زنم که هم DLL test و هم DLL business با هم ساخته شوند. در قسمت خروجی ها می آیم و می بینم که بله DLL test من ساخته شده است، هم در Mode Debug و هم در mode release فقط نکته ی مهمی که در اینجا وجود دارد این است که test ها روی DLL از نوع release اجرا می شود نه روی دیباگ اگر شما بخواهید که مثلا connection test تان را connection Debug تان را موقع test استفاده کنید دیگر نمی توانید از IF Debug visual studio استفاده کنید.

اینجا حتما باید از  isDebug خود پلتفرم که در قسمت Debug توضیح دادم استفاده کنید و connection تان را ببرید مثلا روی connection test یا مثلا می توانید خود آن class که قرار است test کنید را Constructor به آن بدهید و IsTestMode اش به صورت پیش فرض False باشد موقعی که در متد تست تان New می کنید آن را با true پاس بدهید تا بفهمید که connection تان را باید روی test بگذارید. ولی By defaults روی محیط release اجرا می شود یعنی مفهومش این است که Debug تان را انجام داده اید و روی DLL Debug تان و حالا آخرین مرحله که می خواهد برسد دست مشتریتان test هایتان را روی release انجام دهید تا مطمئن شوید.

من خروجی DLL business را چک می کنم ببینم ساخته شده یا نه. در قسمت مدیریت خروجی ها می بینم که آن هم ساخته شده. کدهای تحت .NET یک منوی دیگر غیر از مدیریت assembly ها به اسم اجرای یک Unit Test من می زنم از قسمت انتخاب Assembly test ما باید DLL test مان را انتخاب کنیم همانطور که می بینید فقط DLL از نوع test را در اینجا آورده است من KS.Dynamic.UnitTest را انتخاب می کنم و از قسمت انتخاب کد ، متد تست رو انتخاب می کنم و از قسمت نگارش ، نگارش DLL test را انتخاب می کنم.

نکته ای وجود دارد ، آن فردی که قرار است Unit Test را اجرا کند اگر فرد دیگری باشد غیر از خودتان می توانید روی ورژن های مختلف DLL test تان هم به او دسترسی بدهید. فرضاً tester تان تا ورژن 4 می تواند Test را اجرا کند و ورژن 5 را که هنوز مطمئن نیستید از کد داخل آن به او دسترسی نمی دهید. حالا در ویدیوهای امنیت راجع به آن بیشتر برایتان توضیح می دهم که شما حتی در سطح ورژن هم می توانید دسترسی بدهید نه تنها در سطح DLL و از انتخاب متد Test do test را انتخاب می کنیم اینجا هم حالا مثلا یک عدد می دهم و اجرا می کنم می بینید که true یعنی test ما با موفقیت انجام شد.