فائدہ:
- قبولیت کے اصول سے آزادانہ طور پر یونٹ ٹیسٹ میں متوقع قدر کا حساب لگا کر مصنوعی ذہانت کو غلط رویے کو 'درست' کے طور پر قبول کرنے سے روکنے کی صلاحیت
- AAA اور FIRST اصولوں کو لاگو کرکے اور بیرونی انحصار کا مذاق اڑاتے ہوئے تیز، آزاد اور دوبارہ قابل ٹیسٹ پرنٹ کرنے کی صلاحیت
- اتپریورتن (کوڈ بریکنگ) کے ساتھ ٹیسٹوں کی جانچ کرنے اور ڈیزائن کی بو کے طور پر ٹیسٹ کرنے کے مشکل کوڈ کو پہچاننے کی صلاحیت
ٹیسٹنگ اہرام کی سب سے بڑی اور تیز ترین پرت یونٹ ٹیسٹنگ ہے — ٹیسٹنگ جو کسی فنکشن یا کوڈ کے چھوٹے ٹکڑے کی ہر چیز سے الگ تھلگ ہونے کی تصدیق کرتی ہے۔ یونٹ کے ہزاروں ٹیسٹ سیکنڈوں میں چلتے ہیں اور ایک بگ پکڑ لیتے ہیں جب کہ کوڈ ابھی بھی ڈویلپر کی سکرین پر ہوتا ہے۔ مصنوعی ذہانت (AI) شاید یونٹ ٹیسٹ تیار کرنے میں سب سے زیادہ ماہر ہے: آپ اسے ایک فنکشن دیتے ہیں، AI درجنوں ٹیسٹ تیار کرتا ہے۔ لیکن یہی سہولت سب سے بڑے جال کو جنم دیتی ہے: AI آسانی سے ایسے ٹیسٹ تیار کرتا ہے جو "سبز رنگ میں چمکتے ہیں لیکن کسی چیز کی تصدیق نہیں کرتے" یا کوڈ کے موجودہ (شاید ناقص) رویے کو "درست" کے طور پر قبول کرتے ہیں۔ اس یونٹ میں آپ سیکھیں گے کہ AI کے ساتھ صحیح معنوں میں حفاظتی یونٹ ٹیسٹ کیسے لکھنا ہے اور قابل امتحان کوڈ اور AI کے درمیان تعلق۔
اچھے یونٹ ٹیسٹ کی خوبیاں: پہلا
اچھے یونٹ ٹیسٹ پہلے اصولوں کی پیروی کرتے ہیں: تیز، آزاد (ٹیسٹ ایک دوسرے پر منحصر نہیں ہونے چاہئیں)، دہرائے جانے کے قابل (دوہرائے جانے کے قابل — کسی بھی ماحول میں ایک ہی نتیجہ)، خود تصدیق (کلیئر پاس/فیل)، بروقت (وقت پر)۔ AI پیدا کرنے والے ٹیسٹ کرواتے وقت اپنے آپ کو ان اصولوں کی یاد دلائیں؛ خاص طور پر پوچھیں کہ ٹیسٹ "آزاد" اور "دوبارہ قابل" ہونے کے لیے بیرونی دنیا (اصل ڈیٹا بیس، نیٹ ورک، گھڑی) پر منحصر نہیں ہے۔
AAA پیٹرن اور اظہار خیال
ایک ٹھوس یونٹ ٹیسٹ AAA ڈھانچے کی پیروی کرتا ہے: ترتیب دیں (تیار کریں — ان پٹ اور انحصار کو ترتیب دیں)، ایکٹ (عمل کریں — ٹیسٹ کے تحت فنکشن کو کال کریں)، اسسٹ (توثیق کریں — متوقع قدر کے ساتھ نتیجہ کا موازنہ کریں)۔ تنقیدی ایک دعویٰ ہے۔ AI کی سب سے عام غلطی ٹیسٹ کے تحت کوڈ کے آؤٹ پٹ سے دعویٰ اخذ کرنا ہے - "جو بھی کوڈ واپس آتا ہے وہ سچ ہے" منطق۔ اس سے ٹیسٹ بے معنی ہو جاتا ہے۔ صحیح طریقہ یہ ہے کہ متوقع قدر کا آزادانہ طور پر تعین کیا جائے (قبولیت کے معیار سے، دستی طور پر اس کا حساب لگائیں)۔
توجہ: اگر آپ AI کو کہتے ہیں کہ "اس فنکشن کے لیے ایک ٹیسٹ لکھیں"، تو AI فنکشن کو چلا سکتا ہے اور اس کی آؤٹ پٹ کو "متوقع" کے طور پر لکھ سکتا ہے۔ یہ ٹیسٹ پاس ہوتا ہے چاہے فنکشن غلط ہو۔ اس کے بجائے، "آپ ان اصولوں کے مطابق متوقع نتائج کا حساب لگاتے ہیں، فنکشن کے موجودہ آؤٹ پٹ کا حوالہ نہ دیں۔"
طنز، سٹبس اور انحصار
یونٹ ٹیسٹنگ کے لیے تنہائی کی ضرورت ہوتی ہے۔ اگر آپ کا فنکشن ڈیٹابیس یا API پر منحصر ہے، تو انہیں جانچ میں فرضی اشیاء (مذاق/سٹب — ایک کنٹرول شدہ، ڈمی متبادل) سے تبدیل کر دیا جاتا ہے۔ یہ ٹیسٹ کو تیز، آزاد اور تولیدی بناتا ہے۔ AI فرضی تنصیب پیدا کر سکتا ہے؛ لیکن ضرورت سے زیادہ مذاق اڑانے سے بچو: اگر آپ ہر چیز کا مذاق اڑاتے ہیں، تو ٹیسٹ صرف اس بات کی تصدیق کرے گا کہ "مذاق کیا لوٹتا ہے"، اصل منطق نہیں۔ توازن: بیرونی دنیا کی تقلید کریں، آزمائش کے تحت حقیقی منطق پر عمل کریں۔
ٹیسٹ ایبلٹی اور اے آئی
ایک دلچسپ رائے ہے: کوڈ جس کی جانچ کرنا مشکل ہے وہ اکثر خراب ڈیزائن کردہ کوڈ ہوتا ہے۔ اگر AI کو کسی فنکشن (بہت زیادہ انحصار، پوشیدہ عالمی حالت، ضمنی اثرات) کے ٹیسٹ لکھنے میں دشواری پیش آتی ہے، تو یہ ڈیزائن کی بو ہے۔ AI سے یہ پوچھنا کہ "آپ اس کوڈ کو جانچنے کے قابل بنانے کے لیے کس طرح ری فیکٹر کریں گے" بہتر ٹیسٹنگ اور بہتر کوڈ دونوں کی طرف لے جاتا ہے۔
پیرامیٹرائزڈ ٹیسٹ اور ڈیٹا کا تنوع
ایک ہی قاعدہ کو مختلف ان پٹ کے ساتھ تصدیق کرنے کے لیے ہر بار الگ ٹیسٹ لکھنا مشکل اور برقرار رکھنا مشکل ہے۔ پیرامیٹرائزڈ ٹیسٹنگ - ایک ڈھانچہ جو بار بار ایک ہی ٹیسٹ منطق کو ان پٹ اور متوقع نتائج کی فہرست پر چلاتا ہے - اس تکرار کو ختم کرتا ہے: ایک واحد ٹیسٹ باڈی کو درجنوں ان پٹ جوڑوں کے ساتھ کھلایا جاتا ہے۔ جب آپ اسے اپنے قبولیت کے اصول بتاتے ہیں تو AI ان پٹ سے متوقع نتائج کی میزیں تیار کرنے میں بہت موثر ہے۔ خاص طور پر، یہ منظم طریقے سے حد اقدار اور مساوات کی کلاسوں کو ٹیبلیٹ کرتا ہے۔
لیکن یہاں بھی ایک جال ہے: AI ٹیسٹ کے تحت کوڈ سے تیار کردہ ٹیبل میں متوقع نتائج اخذ کرتا ہے۔ پیرامیٹرائزڈ ٹیسٹنگ میں یہ غلطی اور بھی خطرناک ہے، کیونکہ ایک غلط منطق درجنوں لائنوں کو باطل کر دیتی ہے۔ لہذا، ہمیشہ متوقع نتیجہ کے کالم کو قبولیت کے اصول کے مطابق آزادانہ طور پر شمار کریں اور دستی طور پر کم از کم چند قطاروں کی توثیق کریں۔ تفصیلی کالم کے لیے بھی پوچھیں "ہر قطار کس چیز کی نمائندگی کرتی ہے"؛ لہذا جب ایک قطار ٹوٹتی ہے تو آپ فوری طور پر دیکھیں کہ کون سی حالت ٹوٹی ہے۔
ٹپ: جان بوجھ کر پیرامیٹرائزڈ ٹیسٹ ٹیبل میں "ٹریپ قطار" شامل کریں — یعنی جان بوجھ کر نتیجہ کو غلط ٹائپ کریں۔ اگر آپ ٹیسٹ چلاتے وقت وہ لائن سرخ نہیں ہوتی ہے، تو آپ کا ٹیسٹ درحقیقت اس صورتحال کی تصدیق نہیں کر رہا ہے۔ یہ ایک فوری فرضی پاس چیک ہے۔
کمزور فوری / مضبوط اشارہ
کمزور: "اس فنکشن کے لیے یونٹ ٹیسٹ لکھیں۔"
مضبوط: "taxCalculate(ramount, rate) فنکشن کے لیے [language/framework] یونٹ ٹیسٹ لکھیں۔ قبولیت کا اصول: نتیجہ = رقم * شرح، 2 اعشاریہ پر گول؛ منفی رقم یا شرح ایک غلطی پیدا کرتی ہے؛ اگر شرح 0 ہے تو 0 لوٹاتا ہے۔ AAA ڈھانچہ استعمال کریں۔ دستی طور پر حساب لگائیں؛ متوقع اصولوں کے مطابق THE کو تبدیل نہ کریں۔ اور منفی صورتیں (0، منفی، بہت بڑا، گول سے اعشاریہ تک) ہر ٹیسٹ کے نام کو اس قاعدے کی وضاحت کرنے دیں جس کی یہ تصدیق کرتا ہے "نہیں۔"
طاقتور فوری؛ یہ قبولیت کا اصول، آزاد متوقع قدر کی توقع، ساخت اور کنارے کے معاملات دیتا ہے۔ اس طرح، امتحان ضابطے کا آئینہ نہیں بلکہ قاعدے کا محافظ بن جاتا ہے۔
یونٹ ٹیسٹ کوالٹی ٹیبل
علامت
غلط ٹیسٹ (جعلی اعتماد)
اچھا ٹیسٹ
دعوی
کوئی نہیں یا "نوٹ نہیں"
متوقع ٹھوس قدر
متوقع قدر کا ذریعہ
فنکشن کا آؤٹ پٹ
قبولیت کا قاعدہ / دستی حساب کتاب
لت
اصل DB/نیٹ ورک/گھنٹہ
موک/سٹب کے ساتھ موصل
کنارے کیس
صرف خوشگوار سڑک
حد، منفی، غلطی
جب آپ کوڈ کو توڑ دیتے ہیں۔
سبز رہتا ہے
سرخ ہو جاتا ہے
نام
ٹیسٹ 1، ٹیسٹ کا طریقہ
اس اصول کی وضاحت کرتا ہے جس کی تصدیق کرتا ہے۔
چار کاپی کرنے کے قابل ٹیمپلیٹس
1) اصول پر مبنی یونٹ ٹیسٹنگ:
آپ کا کردار: سینئر سافٹ ویئر ٹیسٹ انجینئر۔ درج ذیل فنکشن پر ایک یونٹ ٹیسٹ [language/framework] کے ساتھ لکھیں: [دستخط]۔ قبولیت کے اصول: [قواعد]۔- AAA ڈھانچہ استعمال کریں۔- ان اصولوں کے مطابق دستی طور پر متوقع قدروں کا حساب لگائیں۔ فنکشن کے موجودہ آؤٹ پٹ کا حوالہ نہ دیں۔ - الگ الگ ٹیسٹ کے ساتھ حد، منفی، غلطی اور خوش راہ کا احاطہ کریں۔ - ہر ٹیسٹ کے نام کو اس اصول کی وضاحت کرنے دیں جس کی وہ تصدیق کرتا ہے۔ - فرضی بیرونی انحصار؛ اصل منطق کو کام کریں۔
2) اتپریورتن مزاحمت کنٹرول:
یہ یونٹ ٹیسٹ دیکھیں۔ 5 معمولی تبدیلیوں کی فہرست بنائیں جو میں ٹیسٹ کے تحت کوڈ میں کر سکتا ہوں (a - a + کی بجائے، a >= a > کی بجائے، ایک باؤنڈری شفٹ) اور مجھے بتائیں کہ ان میں سے کون سا ٹیسٹ سرخ ہو جائے گا؟ اگر کوئی واپس نہیں کیا جاتا ہے، تو ٹیسٹ ناکافی ہے۔ کوڈ + ٹیسٹ: [پیسٹ]
3) ٹیسٹیبلٹی کا جائزہ:
اس فنکشن کے لیے یونٹ ٹیسٹ لکھنا کیوں مشکل ہے؟ پوشیدہ لت، عالمی حیثیت، ضمنی اثرات، کیا بہت سی ذمہ داریاں ہیں؟ اسے قابل آزمائش بنانے کے لیے کم سے کم ری فیکٹرنگ تجویز کریں۔ رویے کو تبدیل نہ کریں. کوڈ: [پیسٹ کریں]
4) نامکمل منظر نامے کی تکمیل:
درج ذیل فنکشن اور دستیاب ٹیسٹ دیئے گئے ہیں۔ فہرست بنائیں کہ کون سے طرز عمل/ ایج کیس کا کبھی تجربہ نہیں کیا گیا (اسکوپ گیپ) اور ہر ایک کے لیے ایک ٹیسٹ شامل کریں۔ فنکشن + ٹیسٹ: [پیسٹ]
تین چھوٹے مقدمات
کیس 1 - کوڈ کی عکس بندی کی جانچ کریں۔ ایک ڈویلپر نے AI کو راؤنڈنگ فنکشن کے لیے ایک ٹیسٹ لکھوایا تھا۔ 10 ٹیسٹ سبز تھے۔ درحقیقت، فنکشن غلط سمت میں گول کر رہا تھا، لیکن AI نے فنکشن کے آؤٹ پٹ سے متوقع قدریں لی تھیں، اس لیے ٹیسٹوں نے غلطی کو "سچ" سمجھا۔ جب متوقع اقدار کو "قواعد پر مبنی" ٹیمپلیٹ کے ساتھ دستی طور پر شمار کیا گیا تو، 4 ٹیسٹ سرخ ہو گئے اور اصل غلطی سامنے آ گئی۔
کیس 2 - میوٹیشن کنٹرول کی قدر۔ ایک ٹیم نے 45 یونٹ ٹیسٹوں پر انحصار کیا۔ "میوٹیشن مضبوطی کی جانچ" کے ساتھ کوڈ میں 20 معمولی تبدیلیوں کی کوشش کی؛ ٹیسٹ ان میں سے صرف 11 پکڑے گئے۔ باقی 9 رکاوٹیں خاموشی سے گزر گئیں۔ ٹیم نے کمزور ٹیسٹ کو مضبوط کیا؛ اگلی ریلیز میں ان بہتر ٹیسٹوں کے ذریعے حساب کی اصل غلطی پکڑی گئی۔
کیس 3 - عدم استحکام ایک ڈیزائن کی بو ہے۔ AI آرڈرنگ فنکشن کے لیے ٹیسٹ نہیں لکھ سکتا تھا، اسے حقیقی ڈیٹا بیس کی مسلسل ضرورت تھی۔ "ٹیسٹ ایبلٹی ریویو" ٹیمپلیٹ نے ظاہر کیا کہ فنکشن نے ڈیٹا بیس تک رسائی کو سرایت کر دیا ہے۔ جب انحصار انجکشن کو ہٹا دیا گیا تھا، ٹیسٹ لکھا جا سکتا تھا اور کوڈ صاف ہو گیا تھا.
عام غلطیاں
- کوڈ سے متوقع قدر اخذ کرنا۔ AI فنکشن آؤٹ پٹ کو "درست" کے طور پر قبول کرتا ہے۔ ٹیسٹ جو غلط کوڈ کی تصدیق کرتا ہے۔
- دعوے کے بغیر یا معمولی دعوے کے ساتھ ٹیسٹ کریں۔ "اس نے غلطی نہیں کی، وہ پاس ہو گیا" منطق؛ یہ کسی چیز کی تصدیق نہیں کرتا ہے۔
- انتہائی مذاق۔ ہر چیز کا مذاق اڑانا اور صرف اس چیز کی جانچ کرنا جو فرضی واپس آئے۔ حقیقی منطق کا تجربہ نہیں کیا جاتا ہے۔
- بس خوشی کا راستہ۔ حد، منفی اور غلطی کی حالتوں کو نظرانداز کرنا۔
- کوڈ کو توڑ کر جانچ نہیں کرنا۔ اتپریورتن کی جانچ کیے بغیر سبز پر بھروسہ کرنا۔
- عدم استحکام کو نظر انداز کرنا۔ سخت جانچ کو آگے بڑھانے کے بجائے خراب ڈیزائن کو پہچاننا اور ٹھیک کرنا۔
خلاصہ میں
یونٹ ٹیسٹ ٹیسٹنگ اہرام کی تیز ترین اور سب سے بڑی پرت ہیں۔ یہ سب سے سستے لمحے میں غلطی پکڑ لیتا ہے۔ AI یونٹ ٹیسٹ تیار کرنے کی بہت صلاحیت رکھتا ہے، لیکن اس کا سب سے بڑا نقصان ٹیسٹ لکھنا ہے جو کوڈ سے ہی متوقع قدر اخذ کر کے غلط رویے کو "درست" مان لیتے ہیں۔ حل: قبولیت کے اصول دیں، متوقع قدروں کا دستی طور پر حساب لگائیں، AAA اور FIRST اصولوں کو نافذ کریں، باہر کی دنیا کا مذاق اڑائیں اور حقیقی منطق کو چلائیں، اور ہر ٹیسٹ کو میوٹیشن (کوڈ کو توڑ کر) کے ذریعے پرکھیں۔ کوڈ جس کی جانچ کرنا مشکل ہے وہ ڈیزائن کا نشان ہے جس کو درست کرنے کی ضرورت ہے۔
درخواست کا کام
ایک فنکشن منتخب کریں جس میں آپ کے اپنے پروجیکٹ سے کاروباری اصول شامل ہو۔ قبولیت کے قواعد لکھیں اور AI تحریری ٹیسٹ "قواعد پر مبنی یونٹ ٹیسٹنگ" ٹیمپلیٹ کے ساتھ کرائیں۔ متوقع قدروں کا حساب دستی طور پر کریں۔ پھر "میوٹیشن مضبوطی کی جانچ" کا اطلاق کریں: کوڈ میں کم از کم 5 چھوٹے وقفے کریں اور پیمائش کریں کہ کتنے ٹیسٹ سرخ ہوجاتے ہیں۔ نہ پکڑی گئی بدعنوانی کے لیے نیا ٹیسٹ شامل کریں۔ رپورٹ کریں کہ کتنی رکاوٹیں پکڑی گئیں (جیسے میوٹیشن سکور)۔
چیک لسٹ
- میں نے قبولیت کے اصول دیے ہیں اور متوقع قدروں کا حساب دستی طور پر کیا ہے۔
- [ ] میں نے اس بات کو یقینی بنایا کہ ٹیسٹوں نے کوڈ سے متوقع قدر حاصل نہیں کی۔
- میں نے AAA اور FIRST رہنما خطوط پر عمل کرتے ہوئے آزاد جانچ قائم کی ہے۔
- میں نے بیرونی انحصار کا مذاق اڑایا اور اصل منطق چلائی۔
- میں نے حد، منفی اور غلطی کے کیسز کا احاطہ کیا۔
- کوڈ (میوٹیشن) کو توڑ کر میں نے ثابت کیا کہ ٹیسٹ واقعی حفاظت کرتے ہیں۔