جاوا یونٹ ٹیسٹنگ: تکنیک، تصورات، مشق

آج آپ کو شاید ہی کوئی ایسی ایپلی کیشن ملے گی جو ٹیسٹوں سے ڈھکی نہ ہو، اس لیے یہ موضوع نئے ڈویلپرز کے لیے پہلے سے کہیں زیادہ متعلقہ ہو گا: بغیر ٹیسٹ کے آپ کہیں بھی نہیں جا سکتے۔ بطور اشتہار، میرا مشورہ ہے کہ آپ میرے ماضی کے مضامین کو دیکھیں۔ ان میں سے کچھ ٹیسٹ کا احاطہ کرتے ہیں (اور یہاں تک کہ مضامین بہت مفید ہوں گے):

1. MySql کو تبدیل کرنے کے لیے ماریا ڈی بی کا استعمال کرتے ہوئے ڈیٹا بیس کی انٹیگریشن ٹیسٹنگ
2. کثیر لسانی درخواست کا نفاذ
3. فائلوں کو ایپلیکیشن میں محفوظ کرنا اور ان کے بارے میں ڈیٹا بیس میں محفوظ کرنا

آئیے اس بات پر غور کریں کہ اصولی طور پر کس قسم کی جانچ استعمال کی جاتی ہے، اور اس کے بعد ہم ہر چیز کا تفصیل سے مطالعہ کریں گے جو آپ کو یونٹ ٹیسٹنگ کے بارے میں جاننے کی ضرورت ہے۔

جانچ کی اقسام

ٹیسٹ کیا ہے؟ جیسا کہ وکی کہتا ہے: " ایک ٹیسٹ یا ٹیسٹ سسٹم کو مختلف حالات میں رکھ کر اور اس میں قابل مشاہدہ تبدیلیوں کو ٹریک کرکے سسٹم کے بنیادی عمل کا مطالعہ کرنے کا ایک طریقہ ہے۔" دوسرے لفظوں میں، یہ مخصوص حالات میں ہمارے سسٹم کے درست آپریشن کا امتحان ہے۔ ٹھیک ہے، آئیے دیکھتے ہیں کہ جانچ کی کیا اقسام ہیں:

1. یونٹ ٹیسٹنگ وہ ٹیسٹ ہیں جن کا کام انفرادی طور پر سسٹم کے ہر ماڈیول کی جانچ کرنا ہے۔ یہ ضروری ہے کہ یہ نظام کے کم سے کم قابل تقسیم ٹکڑے ہوں، مثال کے طور پر، ماڈیول۔

2. سسٹم ٹیسٹنگ ایک اعلیٰ سطحی ٹیسٹ ہے جو کسی ایپلیکیشن کے بڑے حصے یا مجموعی طور پر سسٹم کے آپریشن کی جانچ کرتا ہے۔

3. ریگریشن ٹیسٹنگ وہ جانچ ہے جس کا استعمال یہ جانچنے کے لیے کیا جاتا ہے کہ آیا نئی خصوصیات یا بگ فکسز ایپلی کیشن کی موجودہ فعالیت کو متاثر کرتے ہیں اور کیا پرانے کیڑے دوبارہ ظاہر ہوتے ہیں۔

4. فنکشنل ٹیسٹنگ تصریحات، صارف کی کہانیوں وغیرہ میں بیان کردہ تقاضوں کے ساتھ درخواست کے حصے کی تعمیل کی جانچ کر رہی ہے۔

   فنکشنل ٹیسٹنگ کی اقسام:

   • سسٹم کے اندرونی نفاذ کے علم کے ساتھ درخواست کے کچھ حصے کی تعمیل کے لیے "وائٹ باکس" ٹیسٹ ؛
   • سسٹم کے اندرونی نفاذ کے بارے میں علم کے بغیر ضروریات کے ساتھ درخواست کے حصے کی تعمیل کے لیے "بلیک باکس" ٹیسٹ ۔
5. کارکردگی کی جانچ ٹیسٹ کی ایک قسم ہے جو اس رفتار کا تعین کرنے کے لیے لکھی جاتی ہے جس پر کوئی نظام یا اس کا کچھ حصہ کسی خاص بوجھ کے تحت چلتا ہے۔
6. لوڈ ٹیسٹنگ - معیاری بوجھ کے تحت سسٹم کے استحکام کو جانچنے اور زیادہ سے زیادہ ممکنہ چوٹی تلاش کرنے کے لیے ڈیزائن کیے گئے ٹیسٹ جس پر ایپلیکیشن صحیح طریقے سے کام کرتی ہے۔
7. اسٹریس ٹیسٹنگ ٹیسٹنگ کی ایک قسم ہے جسے غیر معیاری بوجھ کے تحت کسی ایپلیکیشن کی فعالیت کو جانچنے اور زیادہ سے زیادہ ممکنہ چوٹی کا تعین کرنے کے لیے ڈیزائن کیا گیا ہے جس پر سسٹم کریش نہیں ہوگا۔
8. سیکیورٹی ٹیسٹنگ - کسی سسٹم کی سیکیورٹی کو جانچنے کے لیے استعمال کیے جانے والے ٹیسٹ (ہیکرز، وائرس کے حملوں، خفیہ ڈیٹا تک غیر مجاز رسائی اور زندگی کی دیگر خوشیوں سے)۔
9. لوکلائزیشن ٹیسٹنگ کسی ایپلیکیشن کے لیے لوکلائزیشن ٹیسٹنگ ہے۔
10. یوز ایبلٹی ٹیسٹنگ ٹیسٹنگ کی ایک قسم ہے جس کا مقصد صارفین کے لیے قابل استعمال، فہم، کشش اور سیکھنے کی اہلیت کو جانچنا ہے۔
یہ سب اچھا لگتا ہے، لیکن عملی طور پر یہ کیسے کام کرتا ہے؟ یہ آسان ہے: مائیک کوہن کا ٹیسٹنگ اہرام استعمال کیا جاتا ہے: یہ اہرام کا ایک آسان ورژن ہے: اب اسے چھوٹے حصوں میں تقسیم کیا گیا ہے۔ لیکن آج ہم خراب نہیں کریں گے اور آسان ترین آپشن پر غور کریں گے۔

1. یونٹ - ایپلی کیشن کی مختلف پرتوں میں استعمال ہونے والے یونٹ ٹیسٹ، ایپلی کیشن کی سب سے چھوٹی قابل تقسیم منطق کی جانچ کرتے ہیں: مثال کے طور پر، ایک کلاس، لیکن اکثر طریقہ۔ یہ ٹیسٹ عام طور پر بیرونی منطق سے زیادہ سے زیادہ الگ تھلگ کرنے کی کوشش کرتے ہیں، یعنی یہ وہم پیدا کرنے کے لیے کہ باقی ایپلی کیشن معیاری موڈ میں کام کر رہی ہے۔

   ان میں سے بہت سارے ٹیسٹ ہمیشہ ہونے چاہئیں (دوسری اقسام سے زیادہ)، کیونکہ وہ چھوٹے ٹکڑوں کی جانچ کرتے ہیں اور بہت ہلکے ہوتے ہیں، بہت زیادہ وسائل استعمال نہیں کرتے (وسائل سے میرا مطلب ہے رام اور وقت)۔

2. انضمام - انضمام کی جانچ۔ یہ نظام کے بڑے ٹکڑوں کو چیک کرتا ہے، یعنی یہ یا تو منطق کے کئی ٹکڑوں (کئی طریقوں یا کلاسوں) کا مجموعہ ہے، یا کسی بیرونی جزو کے ساتھ کام کرنے کی درستگی ہے۔ عام طور پر یونٹ ٹیسٹ کے مقابلے میں ان میں سے کم ٹیسٹ ہوتے ہیں، کیونکہ یہ زیادہ بھاری ہوتے ہیں۔

   انضمام کے ٹیسٹ کی ایک مثال کے طور پر، آپ ڈیٹا بیس سے منسلک ہونے اور اس کے ساتھ کام کرنے والے طریقوں کے درست عمل کو جانچنے پر غور کر سکتے ہیں ۔

3. UI - ٹیسٹ جو یوزر انٹرفیس کے آپریشن کو چیک کرتے ہیں۔ وہ اطلاق کی تمام سطحوں پر منطق کو متاثر کرتے ہیں، اسی لیے انہیں اینڈ ٹو اینڈ بھی کہا جاتا ہے۔ ایک اصول کے طور پر، ان میں سے بہت کم ہیں، کیونکہ وہ سب سے زیادہ وزن والے ہیں اور انہیں سب سے زیادہ ضروری (استعمال شدہ) راستوں کو چیک کرنا چاہیے۔

   اوپر دی گئی تصویر میں ہم مثلث کے مختلف حصوں کے علاقوں کا تناسب دیکھتے ہیں: حقیقی کام میں ان ٹیسٹوں کی تعداد میں تقریباً ایک ہی تناسب برقرار رکھا جاتا ہے۔

   آج ہم سب سے زیادہ استعمال ہونے والے ٹیسٹوں - یونٹ ٹیسٹوں پر گہری نظر ڈالیں گے، کیونکہ تمام خود احترام جاوا ڈویلپرز کو ان کو بنیادی سطح پر استعمال کرنے کے قابل ہونا چاہیے۔

یونٹ ٹیسٹنگ کے کلیدی تصورات

ٹیسٹ کوریج (کوڈ کوریج) ایپلیکیشن ٹیسٹنگ کے معیار کے اہم جائزوں میں سے ایک ہے۔ یہ کوڈ کا فیصد ہے جو ٹیسٹوں (0-100%) کے ذریعے احاطہ کرتا ہے۔ عملی طور پر، بہت سے لوگ اس فیصد کا پیچھا کرتے ہیں، جس سے میں متفق نہیں ہوں، کیونکہ وہ ایسے ٹیسٹ شامل کرنا شروع کر دیتے ہیں جہاں ان کی ضرورت نہیں ہوتی ہے۔ مثال کے طور پر، ہماری سروس میں بغیر کسی اضافی منطق کے معیاری CRUD (create/get/update/delete) آپریشنز ہیں۔ یہ طریقے خالصتاً بیچوان ہیں جو کام کو اس پرت کو سونپتے ہیں جو ریپوزٹری کے ساتھ کام کرتی ہے۔ اس صورت حال میں، ہمارے پاس جانچنے کے لیے کچھ نہیں ہے: شاید یہ طریقہ تاؤ سے کوئی طریقہ کہتا ہے، لیکن یہ سنجیدہ نہیں ہے۔ ٹیسٹ کوریج کا اندازہ لگانے کے لیے، عام طور پر اضافی ٹولز استعمال کیے جاتے ہیں: JaCoCo، Cobertura، Clover، Emma، وغیرہ۔ اس مسئلے کے مزید تفصیلی مطالعہ کے لیے، چند موزوں مضامین رکھیں:
• JavaRush اور Habré پر کوڈ کوریج کے بارے میں مواد ؛
• بنیادی ٹیسٹنگ تھیوری
ٹی ڈی ڈی (ٹیسٹ سے چلنے والی ترقی) - ٹیسٹ سے چلنے والی ترقی۔ اس نقطہ نظر میں، سب سے پہلے، ایک ٹیسٹ لکھا جاتا ہے جو ایک مخصوص کوڈ کو چیک کرے گا. یہ بلیک باکس ٹیسٹنگ ثابت ہوا: ہم جانتے ہیں کہ ان پٹ پر کیا ہے اور ہم جانتے ہیں کہ آؤٹ پٹ پر کیا ہونا چاہیے۔ یہ کوڈ کی نقل سے بچتا ہے۔ ٹیسٹ پر مبنی ترقی ایپلی کیشن کی ہر چھوٹی فعالیت کے لیے ڈیزائننگ اور ٹیسٹ تیار کرنے کے ساتھ شروع ہوتی ہے۔ TDD نقطہ نظر میں، سب سے پہلے، ایک ٹیسٹ تیار کیا جاتا ہے جو اس بات کی وضاحت اور تصدیق کرتا ہے کہ کوڈ کیا کرے گا۔ TDD کا بنیادی مقصد کوڈ کو صاف، آسان اور غلطی سے پاک بنانا ہے۔ نقطہ نظر مندرجہ ذیل اجزاء پر مشتمل ہے:
1. ہم اپنا ٹیسٹ لکھ رہے ہیں۔
2. ہم امتحان چلاتے ہیں، چاہے وہ پاس ہو یا نہ ہو (ہم دیکھتے ہیں کہ سب کچھ سرخ ہے - خوفزدہ نہ ہوں: ایسا ہی ہونا چاہیے)۔
3. ہم وہ کوڈ شامل کرتے ہیں جو اس ٹیسٹ کو پورا کرے (ٹیسٹ چلائیں)۔
4. ہم کوڈ کو ری ایکٹر کرتے ہیں۔
اس حقیقت کی بنیاد پر کہ یونٹ ٹیسٹ ٹیسٹ آٹومیشن اہرام میں سب سے چھوٹے عناصر ہیں، TDD ان پر مبنی ہے۔ یونٹ ٹیسٹ کی مدد سے ہم کسی بھی کلاس کی کاروباری منطق کو جانچ سکتے ہیں۔ بی ڈی ڈی (رویے سے چلنے والی ترقی) - رویے کے ذریعے ترقی۔ یہ نقطہ نظر TDD پر مبنی ہے۔ مزید واضح طور پر، یہ واضح زبان (عام طور پر انگریزی میں) میں لکھی گئی مثالوں کا استعمال کرتا ہے جو ترقی میں شامل ہر فرد کے لیے نظام کے رویے کو واضح کرتی ہے۔ ہم اس اصطلاح میں غور نہیں کریں گے، کیونکہ یہ بنیادی طور پر ٹیسٹرز اور کاروباری تجزیہ کاروں کو متاثر کرتا ہے۔ ٹیسٹ کیس - ایک اسکرپٹ جو ٹیسٹ کے تحت کوڈ کے نفاذ کی تصدیق کے لیے ضروری اقدامات، مخصوص شرائط اور پیرامیٹرز کو بیان کرتا ہے۔ فکسچر ٹیسٹنگ ماحول کی حالت ہے جو ٹیسٹ کے تحت طریقہ کار کے کامیاب نفاذ کے لیے ضروری ہے۔ یہ استعمال شدہ شرائط کے تحت اشیاء اور ان کے برتاؤ کا پہلے سے طے شدہ سیٹ ہے۔

جانچ کے مراحل

ٹیسٹ تین مراحل پر مشتمل ہے:
1. ٹیسٹ کیے جانے والے ڈیٹا کی وضاحت کرنا (فکسچر)۔
2. ٹیسٹ کے تحت کوڈ کا استعمال کرنا (مطالعہ کے تحت کال کرنا)۔
3. نتائج کی جانچ کرنا اور ان کا متوقع نتائج سے موازنہ کرنا۔
ٹیسٹ ماڈیولرٹی کو یقینی بنانے کے لیے، آپ کو ایپلیکیشن کی دوسری تہوں سے الگ تھلگ رہنے کی ضرورت ہے۔ یہ stubs، mocks اور جاسوسوں کا استعمال کرتے ہوئے کیا جا سکتا ہے. موکس ایسی اشیاء ہیں جو حسب ضرورت ہیں (مثال کے طور پر، ہر ٹیسٹ کے لیے مخصوص) اور آپ کو جوابات کی شکل میں میتھڈ کالز کے لیے توقعات قائم کرنے کی اجازت دیتے ہیں جو ہم وصول کرنے کا ارادہ رکھتے ہیں۔ توقعات کی جانچ فرضی اشیاء پر کال کے ذریعے کی جاتی ہے۔ اسٹبس - جانچ کے دوران کالوں کا سخت جواب فراہم کرتے ہیں۔ وہ کال کے بارے میں معلومات بھی محفوظ کر سکتے ہیں (مثال کے طور پر، پیرامیٹرز یا ان کالز کا نمبر)۔ ان کو بعض اوقات ان کی اپنی اصطلاح سے بھی کہا جاتا ہے - جاسوس ( جاسوس )۔ بعض اوقات یہ اصطلاحات stubs اور mock میں الجھن ہوتی ہے: فرق یہ ہے کہ stub کسی چیز کی جانچ نہیں کرتا ہے، لیکن صرف ایک دی گئی حالت کی نقل کرتا ہے۔ ایک طنز ایک ایسی چیز ہے جس سے توقعات وابستہ ہوتی ہیں۔ مثال کے طور پر، یہ کہ ایک دیے گئے کلاس طریقہ کو ایک مخصوص تعداد میں بار کہا جانا چاہیے۔ دوسرے لفظوں میں، آپ کا ٹیسٹ کبھی بھی سٹب کی وجہ سے نہیں ٹوٹے گا، لیکن یہ ایک مذاق کی وجہ سے ٹوٹ سکتا ہے۔

ٹیسٹ کے ماحول

تو اب کاروبار پر اترتے ہیں۔ جاوا کے لیے کئی ٹیسٹنگ ماحول (فریم ورک) دستیاب ہیں۔ ان میں سب سے زیادہ مقبول JUnit اور TestNG ہیں۔ ہمارے جائزے کے لیے، ہم استعمال کرتے ہیں: JUnit ٹیسٹ ایک طریقہ ہے جو کلاس میں ہوتا ہے جو صرف جانچ کے لیے استعمال ہوتا ہے۔ ایک کلاس کا نام عام طور پر وہی رکھا جاتا ہے جس کلاس کی وہ آخر میں +Test کے ساتھ جانچ کر رہی ہے۔ مثال کے طور پر، CarService→ CarServiceTest۔ ماون بلڈ سسٹم خود بخود ٹیسٹ ایریا میں ایسی کلاسز کو شامل کرتا ہے۔ درحقیقت اس کلاس کو ٹیسٹ کلاس کہا جاتا ہے۔ آئیے بنیادی تشریحات کو تھوڑا سا دیکھیں: @Test - ایک ٹیسٹ کے طریقہ کے طور پر اس طریقہ کی تعریف (حقیقت میں، اس تشریح کے ساتھ نشان زد طریقہ ایک یونٹ ٹیسٹ ہے)۔ @Before - اس طریقہ کو نشان زد کرتا ہے جسے ہر ٹیسٹ سے پہلے عمل میں لایا جائے گا۔ مثال کے طور پر، کلاس ٹیسٹ کا ڈیٹا بھرنا، ان پٹ ڈیٹا پڑھنا وغیرہ۔ @After - اس طریقہ کے اوپر رکھا گیا ہے جسے ہر ٹیسٹ کے بعد بلایا جائے گا (ڈیٹا صاف کرنا، ڈیفالٹ اقدار کو بحال کرنا)۔ @BeforeClass - طریقہ کے اوپر رکھا گیا - @Before کے مشابہ۔ لیکن یہ طریقہ کسی مخصوص کلاس کے تمام ٹیسٹوں سے پہلے صرف ایک بار کہا جاتا ہے اور اس لیے اسے جامد ہونا چاہیے۔ اس کا استعمال زیادہ ہیوی ڈیوٹی آپریشنز کرنے کے لیے کیا جاتا ہے، جیسے ٹیسٹ ڈیٹا بیس کو اٹھانا۔ @AfterClass @BeforeClass کے برعکس ہے: دی گئی کلاس کے لیے ایک بار پھانسی دی گئی، لیکن تمام ٹیسٹوں کے بعد عمل میں لایا گیا۔ استعمال کیا جاتا ہے، مثال کے طور پر، مستقل وسائل کو صاف کرنے یا ڈیٹا بیس سے منقطع کرنے کے لیے۔ @Ignore - نوٹ کریں کہ نیچے دیا گیا طریقہ غیر فعال ہے اور مجموعی طور پر ٹیسٹ چلانے پر نظر انداز کر دیا جائے گا۔ یہ مختلف صورتوں میں استعمال ہوتا ہے، مثال کے طور پر، اگر بنیادی طریقہ تبدیل کیا گیا تھا اور اس کے لیے ٹیسٹ دوبارہ کرنے کا کوئی وقت نہیں تھا۔ ایسے معاملات میں، یہ بھی مشورہ دیا جاتا ہے کہ تفصیل شامل کریں - @Ignore("Some description")۔ @Test (متوقع = Exception.class) - منفی ٹیسٹ کے لیے استعمال کیا جاتا ہے۔ یہ وہ ٹیسٹ ہیں جو جانچتے ہیں کہ غلطی کی صورت میں کوئی طریقہ کس طرح برتاؤ کرتا ہے، یعنی ٹیسٹ سے توقع ہوتی ہے کہ طریقہ کچھ رعایت دے گا۔ اس طرح کے طریقہ کو @Test تشریح کے ذریعہ ظاہر کیا جاتا ہے، لیکن پکڑنے میں غلطی کے ساتھ۔ @Test(timeout=100) - چیک کرتا ہے کہ طریقہ 100 ملی سیکنڈ سے زیادہ میں نہیں چلتا ہے۔ @Mock - ایک کلاس کا استعمال کسی فیلڈ پر کسی دیے گئے شے کو فرضی کے طور پر سیٹ کرنے کے لیے کیا جاتا ہے (یہ جنیٹ لائبریری سے نہیں ہے، بلکہ موکیٹو سے ہے)، اور اگر ہمیں اس کی ضرورت ہو تو، ہم ایک مخصوص صورتحال میں فرضی طرز عمل کو ترتیب دیں گے۔ ، براہ راست ٹیسٹ کے طریقہ کار میں۔ @RunWith(MockitoJUnitRunner.class) - طریقہ کلاس کے اوپر رکھا گیا ہے۔ یہ اس میں ٹیسٹ چلانے کا بٹن ہے۔ رنرز مختلف ہو سکتے ہیں: مثال کے طور پر، درج ذیل ہیں: MockitoJUnitRunner، JUnitPlatform، SpringRunner، وغیرہ)۔ JUnit 5 میں، @RunWith تشریح کو زیادہ طاقتور @ExtendWith تشریح سے بدل دیا گیا۔ آئیے نتائج کا موازنہ کرنے کے کچھ طریقوں پر ایک نظر ڈالیں:
• assertEquals(Object expecteds, Object actuals)- چیک کرتا ہے کہ آیا منتقل شدہ اشیاء برابر ہیں۔
• assertTrue(boolean flag)- چیک کرتا ہے کہ آیا پاس شدہ ویلیو درست آتی ہے۔
• assertFalse(boolean flag)- چیک کرتا ہے کہ آیا پاس شدہ قدر غلط لوٹتی ہے۔
• assertNull(Object object)- چیک کرتا ہے کہ آیا اعتراض کالعدم ہے۔
• assertSame(Object firstObject, Object secondObject)- چیک کرتا ہے کہ آیا منظور شدہ اقدار ایک ہی چیز کا حوالہ دیتے ہیں۔
• assertThat(T t, Matcher<T> matcher)- چیک کرتا ہے کہ آیا t میچر میں بیان کردہ شرط کو پورا کرتا ہے۔
assertj سے ایک مفید موازنہ فارم بھی ہے - assertThat(firstObject).isEqualTo(secondObject) یہاں میں نے بنیادی طریقوں کے بارے میں بات کی ہے، کیونکہ باقی اوپر کی مختلف حالتیں ہیں۔

جانچ کی مشق

اب ایک مخصوص مثال کا استعمال کرتے ہوئے مندرجہ بالا مواد کو دیکھتے ہیں۔ ہم سروس کے طریقہ کار کی جانچ کریں گے - اپ ڈیٹ۔ ہم ڈاؤ پرت پر غور نہیں کریں گے، کیونکہ یہ ہماری ڈیفالٹ ہے۔ آئیے ٹیسٹ کے لیے ایک اسٹارٹر شامل کریں:

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-test</artifactId>
   <version>2.2.2.RELEASE</version>
   <scope>test</scope>
</dependency>

تو، سروس کلاس:

@Service
@RequiredArgsConstructor
public class RobotServiceImpl implements RobotService {
   private final RobotDAO robotDAO;

   @Override
   public Robot update(Long id, Robot robot) {
       Robot found = robotDAO.findById(id);
       return robotDAO.update(Robot.builder()
               .id(id)
               .name(robot.getName() != null ? robot.getName() : found.getName())
               .cpu(robot.getCpu() != null ? robot.getCpu() : found.getCpu())
               .producer(robot.getProducer() != null ? robot.getProducer() : found.getProducer())
               .build());
   }
}

8 - ڈیٹا بیس سے اپڈیٹ شدہ آبجیکٹ کو کھینچیں 9-14 - بلڈر کے ذریعے آبجیکٹ بنائیں، اگر آنے والی آبجیکٹ میں فیلڈ ہے - اسے سیٹ کریں، اگر نہیں - جو ڈیٹا بیس میں ہے اسے چھوڑ دیں اور ہمارے ٹیسٹ کو دیکھیں:

@RunWith(MockitoJUnitRunner.class)
public class RobotServiceImplTest {
   @Mock
   private RobotDAO robotDAO;

   private RobotServiceImpl robotService;

   private static Robot testRobot;

   @BeforeClass
   public static void prepareTestData() {
       testRobot = Robot
               .builder()
               .id(123L)
               .name("testRobotMolly")
               .cpu("Intel Core i7-9700K")
               .producer("China")
               .build();
   }

   @Before
   public void init() {
       robotService = new RobotServiceImpl(robotDAO);
   }

1 — ہمارا رنر 4 — ایک فرضی 11 کی جگہ لے کر ڈاؤ پرت سے سروس کو الگ کریں — کلاس کے لیے ایک ٹیسٹ ہستی مقرر کریں (جسے ہم ٹیسٹ ہیمسٹر کے طور پر استعمال کریں گے) 22 — ایک سروس آبجیکٹ سیٹ کریں جسے ہم ٹیسٹ کریں گے۔

@Test
public void updateTest() {
   when(robotDAO.findById(any(Long.class))).thenReturn(testRobot);
   when(robotDAO.update(any(Robot.class))).then(returnsFirstArg());
   Robot robotForUpdate = Robot
           .builder()
           .name("Vally")
           .cpu("AMD Ryzen 7 2700X")
           .build();

   Robot resultRobot = robotService.update(123L, robotForUpdate);

   assertNotNull(resultRobot);
   assertSame(resultRobot.getId(),testRobot.getId());
   assertThat(resultRobot.getName()).isEqualTo(robotForUpdate.getName());
   assertTrue(resultRobot.getCpu().equals(robotForUpdate.getCpu()));
   assertEquals(resultRobot.getProducer(),testRobot.getProducer());
}

یہاں ہم ٹیسٹ کی تین حصوں میں واضح تقسیم دیکھتے ہیں: 3-9 - سیٹنگ فکسچر 11 - ٹیسٹ شدہ حصہ 13-17 کو انجام دینا - نتائج کی جانچ کرنا مزید تفصیلات: 3-4 - moka dao 5 کے لیے رویے کی ترتیب - ایک مثال قائم کرنا کہ ہم اپنے معیار 11 کے اوپر اپ ڈیٹ کریں گے - طریقہ استعمال کریں اور نتیجہ 13 لیں - چیک کریں کہ یہ صفر 14 نہیں ہے - نتیجہ کی شناخت اور مخصوص طریقہ کے دلائل کو چیک کریں 15 - چیک کریں کہ آیا نام کو اپ ڈیٹ کیا گیا ہے 16 - دیکھیں cpu 17 کے نتیجے میں - چونکہ ہم نے اسے اپ ڈیٹ مثال کے فیلڈ میں سیٹ نہیں کیا ہے، اس لیے اسے وہی رہنا چاہیے، آئیے اسے چیک کریں۔ آئیے شروع کریں: ٹیسٹ سبز ہے، آپ سانس چھوڑ سکتے ہیں)) تو، آئیے خلاصہ کرتے ہیں: ٹیسٹنگ کوڈ کے معیار کو بہتر بناتا ہے اور ترقی کے عمل کو مزید لچکدار اور قابل اعتماد بناتا ہے۔ تصور کریں کہ سینکڑوں کلاس فائلوں کے ساتھ سافٹ ویئر کو دوبارہ ڈیزائن کرتے وقت ہمیں کتنی محنت کرنی پڑے گی۔ ایک بار جب ہم ان تمام کلاسوں کے لیے یونٹ ٹیسٹ لکھ لیتے ہیں، تو ہم اعتماد کے ساتھ ری فیکٹر کر سکتے ہیں۔ اور سب سے اہم بات یہ ہے کہ یہ ترقی کے دوران آسانی سے غلطیوں کو تلاش کرنے میں ہماری مدد کرتا ہے۔ دوستو، آج میرے لیے بس یہی ہے: لائکس ڈالیں، تبصرے لکھیں)))