تست واحد با Mockito/PowerMockito – بلاگ Calsoft

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

مانند یک کهنه کار، Mockito می تواند در کفش های مختلف جا شود و هر نقشی را در کد ایفا کند و جداسازی و آزمایش اجزای جداگانه را آسان می کند. در درجه اول، Mockito یک چارچوب طنز است. این به توسعه دهندگان نرم افزار اجازه می دهد تا تست های تاثیرگذار را با استفاده از API های تمیز و ساده برای اجرای تست واحد برای برنامه های کاربردی مبتنی بر جاوا بنویسند. علاوه بر این، این ابزار را می توان با فریمورک های دیگری مانند JUnit و TestNG نیز استفاده کرد. همچنین از شبیه سازی های در حال اجرا بر روی هر سیستمی، صرف نظر از نصب جاوا، پشتیبانی می کند.

تست واحد با استفاده از قابلیت‌های یک فریم ورک ساختگی یکی از مفیدترین روش‌ها برای مدت طولانی به حساب می‌آمد و چارچوب Mockito در سال‌های اخیر به عنوان تسلط بر این زمینه شناخته شده است. با این حال، برای تشویق طراحی کدهای بهتر و ساده سازی ایجاد API عمومی، برخی از ویژگی ها عمداً از ابزار حذف شده اند. با توجه به دلیل قوی برای انجام این کار، این کاستی‌ها آزمایش‌کنندگان را به نوشتن کدهای سنگین سوق می‌دهند تا تولید ساختگی را دوام بیاورند.

خوب، دقیقاً همان جایی است که Power Mockito وارد می شود!

اما قبل از اینکه از طریق وبلاگ ما به طور کامل چشم انداز Mockito و Power Mockito را درک کنید، اجازه دهید ابتدا درک اولیه ای از اصول داشته باشیم.

تست واحد چیست؟

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

طعنه چیست؟

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

اما طعنه چیست؟

Mocking فرآیندی است که برای انجام تست واحد زمانی که واحد کد نرم‌افزار تحت آزمایش وابستگی‌های خارجی دارد، استفاده می‌شود. دستور کار کلی تمسخر جداسازی و جداسازی کد مورد آزمایش است. در تمسخر، وابستگی های خارجی با اشیاء جایگزین کاملاً کنترل شده جایگزین می شوند که می توانند رفتار وابستگی های اصلی را تحریک کنند. سه نوع اصلی از اشیاء جایگزین وجود دارد: ضربه آف، ضربه آف، و تقلبی.

تفاوت و ارتباط بین Mockito، PowerMock و PowerMockito چیست؟

موکیتو این یک چارچوب استاندارد است که مجموعه ای از عملکردها مانند تمسخر، بررسی مبهم و غیره را ارائه می دهد. با این حال، در ابتدا امکان تمسخر روش های خصوصی یا ایستا وجود نداشت.

قدرت MOQ از سوی دیگر، یک کدک کلاس سفارشی و دستکاری بایت کد را برای پشتیبانی از سازنده های تمسخر آمیز، روش های استاتیک، حذف اولیه سازهای استاتیک و موارد دیگر به کار می گیرد. با این حال، نقطه ضعف PowerMock این است که طراحی ضعیف برنامه را ارائه می دهد.

PowerMockito این یک API افزونه است که مطابق با Mockito کار می‌کند و قابلیت‌های ضروری را برای همکاری بدون زحمت با Java Reflection API فراهم می‌کند.

تست رمزگشا با استفاده از Mockito/PowerMockito

Mockito یک چارچوب متن باز برای تمسخر در جاوا است. ویژگی هایی که برای تست واحد ارائه می دهد مهم هستند. نوشتن تست موردی را برای توسعه دهندگان ساده کرده است. در حالی که Mockito می‌تواند به نوشتن موارد آزمایشی کمک کند، موارد خاصی وجود دارد که برای انجام آن طراحی نشده است، از جمله تمسخر یا آزمایش روش‌های خصوصی، نهایی یا ثابت. اینجاست که PowerMockito به کمک می آید. PowerMockito برای آزمایش روش های خصوصی، نهایی یا استاتیک طراحی شده است زیرا از Java Reflection API استفاده می کند. با این حال، توصیه‌شده‌ترین راه برای شروع کار با Mockito یا PowerMockito این است که وابستگی‌های Maven را پیدا کنید و آنها را به پروژه پیوند دهید. وابستگی Maven یک فایل بایگانی ساده مانند JAR و ZIP است که توسط برنامه‌های جاوا استفاده می‌شود و پروژه برای ساخت، کامپایل، آزمایش و اجرا به آن نیاز دارد.

در اینجا وابستگی هایی وجود دارد که باید اضافه کنیم:

وابستگی های Maven

org
mockito-all
1.9.5
امتحان
org
powermock-api-mockito
1.6.2
امتحان
org
powermock-module-junit4
1.6.2
امتحان

توضیحات

اجازه می دهد تا اشیاء مورد نیاز برای آزمایش را به صورت مختصر ایجاد کنید.

  • کد زائد تولید ارواح را کاهش می دهد.
  • کلاس آزمون را خواناتر می کند.

چند نمونه –

@اجرا با– نشان می دهد که کدام چارچوب API باید ارجاع شود
برای PowerMockito – @RunWith(PowerMockRunner.class)

برای موهیتو –@اجرا با(کلاس MockitoJUnitRunner)

@PrepareForTest-فقط در مورد PowerMockito استفاده می شود. این به PowerMockito می گوید که کدام کلاس ها را با استفاده از Java Reflection API برای آزمایش آماده کند.

@امتحان– روش را به عنوان یک مورد تست جونیت تعریف می کند

@mok– به جای مسخره کردن چیزی به طور سنتی. این حاشیه نویسی مستقیماً شیء اعلام شده را مسخره می کند

@spy– برای جاسوسی از نمونه موجود

@قبل از– برای اهداف اولیه، یعنی مقداردهی اولیه شی قبل از استفاده

نحو کلی برای طعنه –

برای تمسخر تماس های متد –
MethodPowerMockito.when(object.printMessage(Mockito.anyString())).thenReturn(message);
زمانی که روش چاپ پیام با هر رشته ای فراخوانی شود، ماک بالا پیامی را برمی گرداند.

در مورد روش های استاتیک از روش زیر استفاده کنید:

1. برای تمسخر تماس های متد –
MethodPowerMockito.when(object.printMessage(Mockito.anyString())).thenReturn(message);
زمانی که روش چاپ پیام با هر رشته ای فراخوانی شود، ماک فوق پیامی را برمی گرداند.

2. در مورد روش های استاتیک از روش زیر استفاده کنید:

PowerMockito.mockStatic(PropertiesReader.class);PowerMockito.when(PropertiesReader.getProperty(Constants.PAGE_SIZE)).thenReturn(ONE);

در اینجا getProperty(..) یک متد استاتیک است که در کلاس PropertiesReader وجود دارد
بنابراین، کلاس mock static قبل از مسخره کردن روش استاتیک آن.

3.

PowerMockito.whenNew(ClassWithFinalMethods.class).withNoArguments().thenReturn(mockObject);

این ایجاد شی جدید را مسخره می کند
برای مثال، هنگامی که یک نمونه جدید از نوع ایجاد می کنید – ClassWithFinalMethods، شیء مسخره شده – “mockObject” به جای شیء جدید واقعی/واقعی برگردانده می شود.

4.

Whitebox.setInternalState(mockVmReplication1، ID_PROPERTY، REPLICATION_ID1);

1. این حالت/مقدار متغیرهای عضو را در شی مورد تمسخر تنظیم می کند
در مثال بالا، ID_PROPERTY برای mockVmReplication1 به = REPLICATION_ID1 تنظیم می شود

فراخوانی روش های واقعی برای آزمایش با استفاده از اشیاء مسخره شده –
روش های واقعی را می توان از موارد تست جونیت به دو صورت فراخوانی کرد:

1. از doCallRealMethod() استفاده کنید –

Mockito.when(mockObject.methodUnderTest().thenCallRealMethod();

هنگامی که با استفاده از یک شیء مسخره شده فراخوانی می شود، متد واقعی – متدUnderTest() – mockObject.methodUndertest();

2. از ایجاد شی واقعی استفاده کنید

ClassUnderMock obj = new ClassUnderMock();
obj.methodUnderTest();

موارد مثبت منفی
doCallRealMethod اشیاء واقعی ایجاد نمی کند ایجاد واقعی شی، اشیاء واقعی ایجاد می کند که توصیه نمی شود مورد تمسخر قرار گیرند
ساخت شی واقعی از تنظیم متغیرهای عضو در سازنده اجتناب می کند شما باید حروف متغیرهای عضوی را که در سازنده تنظیم شده اند تنظیم کنید

تایید و تایید کنید

ادعا و تأیید برای بررسی / تأیید نتایج ساختگی استفاده می شود.
کلاس Assertion شامل چندین روش ثابت است که می توان از آنها برای آزمایش نتایج تمسخر استفاده کرد. در اینجا چند نمونه آورده شده است:
Assert.assertEquals – زمانی که مقادیر واقعی و مورد انتظار برابر نیستند، شکست می خورد
Assert.assertNotNull – زمانی که مقدار واقعی null باشد با شکست مواجه می شود
Assert.assertNotEquals – زمانی که مقادیر واقعی و مورد انتظار برابر باشند، شکست می خورد
Assert.assertTrue – زمانی که مقدار واقعی نادرست باشد، از کار می افتد
Assert.assertFalse – زمانی که مقدار واقعی درست باشد از کار می افتد

تایید می کند()-

  1. برای اطمینان از اینکه کد تمام عملکردهای مورد نیاز را در تمام (یا اکثر) ترکیبات/مقدارهای ورودی برآورده می کند.
  2. برای اطمینان از اینکه می‌توانم پیاده‌سازی را تغییر دهم و به موارد تست JUnit تکیه کنم تا به من بگویم که همه عملکردهای من هنوز راضی هستند.

Mockito.verify(mockedObject, Mockito.times(1)).methodUnderTest();

با این کار بررسی می شود که آیا () methdUndertest فقط 1s در mockedObject نامیده می شود
در غیر این صورت، اجرا با ردیابی زیر ناموفق خواهد بود-
“دوبار خواستم اما یک بار داشتم”

یه چیز کوچیک

تست واحد یک عمل ضروری در توسعه نرم‌افزار است و اطمینان حاصل می‌کند که هر مؤلفه همانطور که در نظر گرفته شده کار می‌کند و استانداردهای کیفیت را برآورده می‌کند. Mockito و PowerMockito ابزارهای ارزشمندی در این فرآیند هستند. Mockito با API ساده و تمیز خود، تمسخر و تست واحد را ساده می کند، در حالی که PowerMockito این قابلیت ها را از طریق Java Reflection API به روش های خصوصی، نهایی و استاتیک گسترش می دهد. آنها با هم، توسعه دهندگان را قادر می سازند تا تست های کارآمد و قابل اعتماد بنویسند، وابستگی ها را کاهش دهند و کیفیت کد را بهبود بخشند.

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

Calsoft با استفاده از تکنیک ها و ابزارهای پیشرفته تست، راه حل های آزمایشی پیشرفته ای را ارائه می دهد. تمرکز ما بر تسریع سفر مشتری از QA به QE بی نظیر است.

منبع: https://www.calsoftinc.com/blogs/unit-testing-mockito-powermockito.html