TDD اور یونٹ ٹیسٹنگ کیا ہے [ترجمہ]

یہ مضمون کتاب The Complete Software Career Guide کے ایک باب کی موافقت ہے۔ اس کے مصنف جان سونمیز اسے لکھتے ہیں اور اپنی ویب سائٹ پر کچھ ابواب پوسٹ کرتے ہیں۔

ابتدائیوں کے لیے ایک مختصر لغت

یونٹ ٹیسٹنگ یا یونٹ ٹیسٹنگ پروگرامنگ میں ایک ایسا عمل ہے جو آپ کو درستگی کے لیے پروگرام کے سورس کوڈ کے انفرادی ماڈیولز کو چیک کرنے کی اجازت دیتا ہے۔ خیال یہ ہے کہ ہر غیر معمولی فعل یا طریقہ کے لیے ٹیسٹ لکھیں۔ ریگریشن ٹیسٹنگ تمام قسم کے سافٹ ویئر ٹیسٹنگ کا ایک عام نام ہے جس کا مقصد سورس کوڈ کے پہلے سے ٹیسٹ شدہ علاقوں میں غلطیوں کا پتہ لگانا ہے۔ اس طرح کی غلطیاں - جب پروگرام میں تبدیلیاں کرنے کے بعد، کوئی چیز جس کو کام جاری رکھنا چاہیے وہ کام کرنا بند کر دیتی ہے - کو ریگریشن ایرر کہا جاتا ہے۔ سرخ نتیجہ، فیل - امتحان میں ناکامی. متوقع نتیجہ اور اصل میں فرق۔ سبز نتیجہ، پاس - مثبت امتحان کا نتیجہ۔ اصل نتیجہ اس سے مختلف نہیں جو حاصل کیا گیا تھا۔ *** میرا ٹیسٹ ڈریوین ڈویلپمنٹ (TDD) اور یونٹ ٹیسٹنگ کے ساتھ بہت ملا جلا تعلق ہے، محبت سے نفرت اور دوبارہ واپس جانا۔ میں ایک شوقین پرستار تھا اور ساتھ ہی ساتھ اس کے استعمال اور دیگر "بہترین طریقوں" کے بارے میں ایک مشکوک شکی تھا۔ میرے رویے کی وجہ اس حقیقت پر مبنی ہے کہ سافٹ ویئر ڈویلپمنٹ کے عمل میں ایک سنگین مسئلہ ابھرا ہے: ڈویلپرز، اور بعض اوقات مینیجر، مخصوص ٹولز اور طریقہ کار کو صرف اس لیے استعمال کرتے ہیں کہ ان کا تعلق "بہترین طریقوں" سے ہے۔ ان کے استعمال کی اصل وجہ ابھی تک واضح نہیں ہے۔ ایک دن میں نے ایک خاص پراجیکٹ پر کام کرنا شروع کیا، اور اس عمل میں مجھے اطلاع ملی کہ ہم کوڈ میں ترمیم کریں گے جس میں یونٹ ٹیسٹ کی ایک بڑی تعداد شامل ہے۔ کوئی مذاق نہیں، ان میں سے تقریباً 3000 تھے۔ یہ عام طور پر ایک اچھی علامت ہے، یہ اشارہ ہے کہ ڈویلپرز جدید طریقہ کار استعمال کر رہے ہیں۔ اس نقطہ نظر کے ساتھ کوڈ اکثر ساختہ ہوتا ہے، اور یہ ایک سوچے سمجھے فن تعمیر پر مبنی ہوتا ہے۔ ایک لفظ میں، ٹیسٹوں کی موجودگی نے مجھے خوش کیا، اگر صرف اس لیے کہ اس کا مطلب پروگرامرز کے سرپرست کے طور پر میرا کام آسان بنانا تھا۔ چونکہ ہمارے پاس پہلے سے ہی یونٹ ٹیسٹ ہو چکے تھے، مجھے بس اتنا کرنا تھا کہ ڈویلپمنٹ ٹیم کو ان کی مدد کے لیے جوڑنا اور اپنا کوڈ لکھنا شروع کرنا تھا۔ میں نے IDE (مربوط ترقیاتی ماحول) کھولا اور پروجیکٹ کو لوڈ کیا۔ یہ ایک بڑا منصوبہ تھا! مجھے "یونٹ ٹیسٹ" کا لیبل لگا ایک فولڈر ملا۔ "بہت اچھا،" میں نے سوچا۔ - آئیے اسے لانچ کرتے ہیں اور دیکھتے ہیں کہ کیا ہوتا ہے۔ اس میں صرف چند منٹ لگے، اور میری حیرت کی بات یہ ہے کہ تمام ٹیسٹ پاس ہو گئے، سب کچھ سبز تھا ( "سبز" ٹیسٹ کا مثبت نتیجہ ہے۔ اس بات کا اشارہ ہے کہ کوڈ توقع کے مطابق کام کر رہا ہے۔ سرخ رنگ "ناکامی" یا ناکامی کی نشاندہی کرتا ہے، پھر ایک ایسا معاملہ ہے جب کوڈ صحیح طریقے سے کام نہیں کرتا ہے - مترجم کا نوٹ )۔ ان سب نے امتحان پاس کیا۔ اسی لمحے میرے اندر کا شکوہ جاگ اٹھا۔ کیسے آئے، تین ہزار یونٹ ٹیسٹ، اور انہوں نے ان سب کو ایک ساتھ لیا - اور مثبت نتیجہ دیا؟ اپنی طویل مشق میں، مجھے وہ وقت یاد نہیں رہا جب میں نے کوڈ میں ایک بھی منفی یونٹ ٹیسٹ کے بغیر کسی پروجیکٹ پر کام کرنا شروع کیا تھا۔ کیا کرنا ہے؟ دستی طور پر چیک کریں! ChY نے ایک بے ترتیب ٹیسٹ کا انتخاب کیا، سب سے زیادہ انکشاف کرنے والا نہیں، لیکن یہ فوری طور پر واضح ہو گیا کہ وہ کیا چیک کر رہا ہے۔ لیکن اس کے ذریعے کام کرتے ہوئے، میں نے کچھ مضحکہ خیز دیکھا: ٹیسٹ میں متوقع نتائج (دعاوں) کے ساتھ کوئی موازنہ نہیں تھا! یعنی حقیقت میں کچھ بھی چیک نہیں کیا گیا ! ٹیسٹ میں کچھ مراحل تھے، وہ کیے گئے، لیکن ٹیسٹ کے اختتام پر، جہاں وہ اصل اور متوقع نتائج کا موازنہ کرے، وہاں کوئی چیک نہیں تھا۔ "امتحان" نے کچھ نہیں آزمایا۔ میں نے ایک اور ٹیسٹ کھولا۔ اس سے بھی بہتر: نتیجہ کے ساتھ موازنہ کرنے والے آپریٹر پر تبصرہ کیا گیا ہے۔ شاندار طور پر! یہ ٹیسٹ پاس کرنے کا ایک بہترین طریقہ ہے، صرف اس کوڈ پر تبصرہ کریں جس کی وجہ سے یہ ناکام ہو رہا ہے۔ میں نے ایک اور ٹیسٹ چیک کیا، پھر دوسرا... ان میں سے کسی نے بھی کچھ چیک نہیں کیا۔ تین ہزار ٹیسٹ، اور یہ سب بالکل بیکار ہیں۔ یونٹ ٹیسٹ لکھنے اور یونٹ ٹیسٹنگ کو سمجھنے اور ٹیسٹ سے چلنے والی ترقی (TDD) میں بہت بڑا فرق ہے۔

یونٹ ٹیسٹنگ کیا ہے؟

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

کیا کبھی کبھی یونٹ ٹیسٹنگ کہا جاتا ہے؟

یونٹ ٹیسٹنگ اکثر انضمام کی جانچ کے ساتھ الجھ جاتی ہے۔ کچھ "یونٹ ٹیسٹ" ایک سے زیادہ کلاسوں کی جانچ کرتے ہیں یا کوڈ کی بڑی اکائیوں کی جانچ کرتے ہیں۔ بہت سارے ڈویلپرز کا دعویٰ ہے کہ وہ یونٹ ٹیسٹ لکھتے ہیں جب حقیقت میں وہ کم سطح کے وائٹ باکس ٹیسٹ لکھتے ہیں۔ ان لڑکوں سے بحث مت کرو۔ بس اتنا جان لیں کہ وہ دراصل انضمام کے ٹیسٹ لکھتے ہیں، اور حقیقی یونٹ ٹیسٹ دوسرے حصوں سے الگ تھلگ کوڈ کی سب سے چھوٹی اکائی کی جانچ کرتے ہیں۔ ایک اور چیز جسے اکثر یونٹ ٹیسٹنگ کہا جاتا ہے وہ ہے یونٹ ٹیسٹ بغیر کسی متوقع قدر کے خلاف جانچے۔ دوسرے الفاظ میں، یونٹ ٹیسٹ جو حقیقت میں کسی چیز کی جانچ نہیں کرتے ہیں۔ کوئی بھی ٹیسٹ، متحد ہو یا نہ ہو، اس میں کسی نہ کسی قسم کی تصدیق شامل ہونی چاہیے - ہم اسے متوقع نتائج کے خلاف اصل نتیجہ کی جانچ کہتے ہیں۔ یہ مفاہمت ہی طے کرتی ہے کہ امتحان پاس ہوتا ہے یا ناکام ہوتا ہے۔ ایک امتحان جو ہمیشہ گزرتا ہے بیکار ہے۔ ایک امتحان جو ہمیشہ ناکام ہوتا ہے بیکار ہے۔

یونٹ ٹیسٹنگ کی قدر

میں یونٹ ٹیسٹنگ کا شوقین کیوں ہوں؟ جنرلائزڈ ٹیسٹنگ کو کال کرنا کیوں نقصان دہ ہے، جس میں دوسرے کوڈ سے الگ تھلگ سب سے چھوٹے بلاک کی جانچ نہیں ہوتی، بلکہ کوڈ کا ایک بڑا حصہ، "یونٹ ٹیسٹنگ" شامل ہوتا ہے؟ اگر میرے کچھ ٹیسٹ موصول اور متوقع نتائج کا موازنہ نہیں کرتے ہیں تو کیا مسئلہ ہے؟ کم از کم وہ کوڈ پر عمل کرتے ہیں۔ میں سمجھانے کی کوشش کروں گا۔ یونٹ ٹیسٹ کرنے کی دو اہم وجوہات ہیں۔ سب سے پہلے کوڈ ڈیزائن کو بہتر بنانا ہے۔ یاد رکھیں میں نے کیسے کہا کہ یونٹ ٹیسٹنگ واقعی ٹیسٹنگ نہیں ہے؟ جب آپ مناسب یونٹ ٹیسٹ لکھتے ہیں، تو آپ خود کو کوڈ کی سب سے چھوٹی اکائی کو الگ کرنے پر مجبور کرتے ہیں۔ یہ کوششیں آپ کو خود کوڈ کے ڈھانچے میں مسائل کو دریافت کرنے کی طرف لے جائیں گی۔ آپ کو ٹیسٹ کلاس کو الگ تھلگ کرنا اور اس میں انحصار شامل نہ کرنا بہت مشکل ہو سکتا ہے، اور اس سے آپ کو یہ احساس ہو سکتا ہے کہ آپ کا کوڈ بہت مضبوطی سے جوڑا گیا ہے۔ آپ کو معلوم ہو سکتا ہے کہ آپ جس بنیادی فعالیت کو جانچنے کی کوشش کر رہے ہیں وہ متعدد ماڈیولز میں پھیلی ہوئی ہے، جس سے آپ کو یقین ہو جائے گا کہ آپ کا کوڈ کافی مربوط نہیں ہے۔ جب آپ یونٹ ٹیسٹ لکھنے بیٹھتے ہیں، تو آپ کو اچانک دریافت ہو سکتا ہے (اور مجھ پر یقین کریں، ایسا ہوتا ہے!) کہ آپ کو اندازہ نہیں ہے کہ کوڈ کو کیا کرنا ہے۔ اس کے مطابق، آپ اس کے لیے یونٹ ٹیسٹ نہیں لکھ سکیں گے۔ اور یقیناً، آپ کو کوڈ کے نفاذ میں ایک حقیقی خرابی مل سکتی ہے، کیونکہ یونٹ ٹیسٹ آپ کو باکس سے باہر سوچنے اور ان پٹ کے مختلف سیٹوں کی جانچ کرنے پر مجبور کرتا ہے جن پر آپ نے غور نہیں کیا ہوگا۔ اگر آپ یونٹ ٹیسٹ بناتے وقت "دوسروں سے الگ تھلگ کوڈ کی سب سے چھوٹی اکائی کی جانچ کریں" کے اصول پر سختی سے عمل کرتے ہیں، تو آپ کو اس کوڈ اور ان ماڈیولز کے ڈیزائن کے ساتھ ہر طرح کی پریشانیوں کا سامنا کرنا پڑے گا۔ سافٹ ویئر ڈویلپمنٹ لائف سائیکل میں، یونٹ ٹیسٹنگ جانچ کی سرگرمی سے زیادہ تشخیصی سرگرمی ہے۔ یونٹ ٹیسٹنگ کا دوسرا بنیادی مقصد ریگریشن ٹیسٹوں کا ایک خودکار سیٹ بنانا ہے جو سافٹ ویئر کے رویے کی نچلی سطح کی وضاحت کے طور پر کام کر سکے۔ اس کا کیا مطلب ہے؟ جب آپ آٹا گوندھتے ہیں تو آپ اسے نہیں توڑتے۔ اس نقطہ نظر سے، یونٹ ٹیسٹ ٹیسٹ ہیں، خاص طور پر ریگریشن ٹیسٹ۔ تاہم، یونٹ ٹیسٹنگ کا مقصد صرف ریگریشن ٹیسٹ بنانا نہیں ہے۔ عملی طور پر، یونٹ ٹیسٹ شاذ و نادر ہی رجعت کو پکڑتے ہیں، کیونکہ آپ جس کوڈ کی جانچ کر رہے ہیں اس کی اکائی میں تبدیلی تقریباً ہمیشہ یونٹ ٹیسٹ میں ہی تبدیلیوں پر مشتمل ہوتی ہے۔ جب کوڈ کو "بلیک باکس" کے طور پر جانچا جاتا ہے تو ریگریشن ٹیسٹنگ اعلیٰ سطح پر زیادہ موثر ہوتی ہے، کیونکہ اس سطح پر کوڈ کے اندرونی ڈھانچے کو تبدیل کیا جا سکتا ہے، جبکہ بیرونی رویے کے وہی رہنے کی توقع کی جاتی ہے۔ یونٹ ٹیسٹ بدلے میں اندرونی ساخت کو چیک کرتے ہیں، تاکہ جب وہ ڈھانچہ بدل جائے تو یونٹ ٹیسٹ ناکام نہ ہوں۔ وہ ناقابل استعمال ہو جاتے ہیں اور اب انہیں تبدیل کرنے، پھینکنے یا دوبارہ لکھنے کی ضرورت ہے۔ اب آپ بہت سے تجربہ کار سافٹ ویئر ڈویلپرز کے مقابلے میں یونٹ ٹیسٹنگ کے حقیقی مقصد کے بارے میں زیادہ جانتے ہیں۔

ٹیسٹ پر مبنی ترقی (TDD) کیا ہے؟

سافٹ ویئر ڈویلپمنٹ کے عمل میں، ایک اچھی تفصیلات سونے میں اس کے وزن کے قابل ہے۔ TDD نقطہ نظر یہ ہے کہ کوئی بھی کوڈ لکھنے سے پہلے، آپ سب سے پہلے ایک ٹیسٹ لکھتے ہیں جو ایک تصریح کے طور پر کام کرے گا، یعنی اس بات کی وضاحت کریں کہ کوڈ کو کیا کرنا چاہیے۔ یہ ایک انتہائی طاقتور سافٹ ویئر ڈویلپمنٹ تصور ہے، لیکن اکثر اس کا غلط استعمال ہوتا ہے۔ عام طور پر، ٹیسٹ سے چلنے والی ترقی کا مطلب ہے ایپلیکیشن کوڈ کی تخلیق کی رہنمائی کے لیے یونٹ ٹیسٹ کا استعمال۔ لیکن حقیقت میں، اس نقطہ نظر کو کسی بھی سطح پر لاگو کیا جا سکتا ہے. تاہم، اس مضمون میں ہم فرض کریں گے کہ ہم اپنی درخواست کے لیے یونٹ ٹیسٹنگ کا استعمال کر رہے ہیں۔ TDD نقطہ نظر ہر چیز کو اپنے سر پر موڑ دیتا ہے، اور اس کوڈ کو جانچنے کے لیے پہلے کوڈ لکھنے اور پھر یونٹ ٹیسٹ لکھنے کے بجائے، آپ پہلے یونٹ ٹیسٹ لکھتے ہیں اور پھر اس ٹیسٹ کو سبز بنانے کے لیے کوڈ لکھتے ہیں۔ اس طرح، یونٹ ٹیسٹنگ "ڈرائیوز" کوڈ کی ترقی۔ یہ عمل بار بار دہرایا جاتا ہے۔ آپ ایک اور ٹیسٹ لکھتے ہیں جو کوڈ کو کیا کرنا چاہئے اس کی زیادہ فعالیت کی وضاحت کرتا ہے۔ اس کے بعد آپ کوڈ لکھیں اور اس میں ترمیم کریں تاکہ یہ یقینی بنایا جا سکے کہ ٹیسٹ کامیابی سے مکمل ہو جائے۔ ایک بار جب آپ کا نتیجہ سبز ہو جاتا ہے، تو آپ کوڈ کو ری فیکٹر کرنا شروع کر دیتے ہیں، یعنی اسے مزید جامع بنانے کے لیے اسے ری فیکٹر کرنا یا صاف کرنا۔ عمل کے اس سلسلے کو اکثر "ریڈ-گرین-ری فیکٹرنگ" کہا جاتا ہے کیونکہ پہلے یونٹ ٹیسٹ ناکام ہوجاتا ہے (سرخ)، پھر کوڈ کو ٹیسٹ کے مطابق ڈھالنے کے لیے لکھا جاتا ہے، اس بات کو یقینی بناتے ہوئے کہ یہ کامیاب ہوتا ہے (سبز)، اور آخر میں کوڈ کو بہتر بنایا جاتا ہے ( ری فیکٹرنگ)۔

TDD کا مقصد کیا ہے؟

ٹیسٹ سے چلنے والی ترقی (TDD)، جیسے یونٹ ٹیسٹنگ، غلط استعمال کی جا سکتی ہے۔ آپ جو کچھ کرتے ہیں اسے "TDD" کہنا اور یہاں تک کہ یہ سمجھے بغیر کہ آپ ایسا کیوں کر رہے ہیں اس پریکٹس کی پیروی کرنا بہت آسان ہے۔ TDD کی سب سے بڑی قدر یہ ہے کہ معیار کی وضاحتیں پیدا کرنے کے لیے ٹیسٹ کیے جاتے ہیں۔ TDD بنیادی طور پر درست وضاحتیں لکھنے کی مشق ہے جو کوڈنگ لکھنے سے پہلے خود بخود چیک کی جا سکتی ہیں۔ ٹیسٹ بہترین وضاحتیں ہیں کیونکہ وہ جھوٹ نہیں بولتے ہیں۔ وہ آپ کو دو ہفتوں کے اذیت کے بعد اس کوڈ کے ساتھ نہیں بتائیں گے "میرا مطلب بالکل نہیں ہے۔" ٹیسٹ، جب صحیح لکھا جاتا ہے، یا تو پاس ہوتا ہے یا فیل ہوتا ہے۔ ٹیسٹ واضح طور پر بتاتے ہیں کہ مخصوص حالات میں کیا ہونا چاہیے۔ اس طرح، TDD کا مقصد ہمیں اس بات کی مکمل تفہیم فراہم کرنا ہے کہ ہم اس پر عمل درآمد شروع کرنے سے پہلے ہمیں کیا نافذ کرنے کی ضرورت ہے۔ اگر آپ TDD کے ساتھ شروعات کر رہے ہیں اور یہ نہیں جان سکتے کہ ٹیسٹ میں کیا ٹیسٹ ہونا ہے، تو آپ کو مزید سوالات کرنے کی ضرورت ہے۔ TDD کا ایک اور اہم کردار کوڈ کو محفوظ کرنا اور بہتر بنانا ہے۔ کوڈ کی دیکھ بھال مہنگی ہے۔ میں اکثر مذاق کرتا ہوں کہ بہترین پروگرامر وہ ہے جو سب سے جامع کوڈ لکھتا ہے جو کسی مسئلے کو حل کرتا ہے۔ یا وہ بھی جو ثابت کرتا ہے کہ اس مسئلے کو حل کرنے کی ضرورت نہیں ہے، اور اس طرح کوڈ کو مکمل طور پر ہٹا دیتا ہے، کیونکہ یہی پروگرامر تھا جس نے غلطیوں کی تعداد کو کم کرنے اور ایپلی کیشن کو برقرار رکھنے کی لاگت کو کم کرنے کا صحیح طریقہ تلاش کیا۔ TDD استعمال کر کے، آپ اس بات کا یقین کر سکتے ہیں کہ آپ کوئی غیر ضروری کوڈ نہیں لکھ رہے ہیں، کیونکہ آپ صرف ٹیسٹ پاس کرنے کے لیے کوڈ لکھ رہے ہوں گے۔ سافٹ ویئر ڈویلپمنٹ کا ایک اصول ہے جسے YAGNI کہتے ہیں (آپ کو اس کی ضرورت نہیں ہوگی)۔ TDD YAGNI کو روکتا ہے۔

عام ٹیسٹ سے چلنے والی ترقی (TDD) ورک فلو

TDD کے معنی کو خالصتاً علمی نقطہ نظر سے سمجھنا مشکل ہے۔ تو آئیے TDD سیشن کی ایک مثال دیکھتے ہیں۔ تصور کریں کہ اپنی میز پر بیٹھیں اور جلدی سے خاکہ بنائیں کہ آپ کے خیال میں اس خصوصیت کے لیے اعلیٰ سطح کا ڈیزائن کیا ہوگا جو صارف کو کسی ایپلیکیشن میں لاگ ان کرنے اور اپنا پاس ورڈ بھول جانے کی صورت میں تبدیل کرنے کی اجازت دیتا ہے۔ آپ فیصلہ کرتے ہیں کہ آپ لاگ ان فنکشن کے پہلے نفاذ کے ساتھ شروع کریں گے، ایک کلاس بنائیں گے جو لاگ ان کے عمل کے لیے تمام منطق کو سنبھالے گی۔ آپ اپنا پسندیدہ ایڈیٹر کھولتے ہیں اور "خالی لاگ ان صارف کو لاگ ان کرنے سے روکتا ہے" نامی یونٹ ٹیسٹ بناتے ہیں۔ آپ یونٹ ٹیسٹ کوڈ لکھتے ہیں جو سب سے پہلے لاگ ان کلاس کی ایک مثال بناتا ہے (جو آپ نے ابھی تک نہیں بنایا ہے)۔ اس کے بعد آپ لاگ ان کلاس میں ایک ایسے طریقہ کو کال کرنے کے لیے کوڈ لکھتے ہیں جو ایک خالی صارف نام اور پاس ورڈ پاس کرتا ہے۔ آخر میں، آپ متوقع نتیجہ کے خلاف ایک چیک لکھتے ہیں، یہ چیک کرتے ہوئے کہ خالی لاگ ان والا صارف درحقیقت لاگ ان نہیں ہے۔ آپ ایک ٹیسٹ چلانے کی کوشش کر رہے ہیں، لیکن یہ مرتب بھی نہیں ہوتا کیونکہ آپ کے پاس لاگ ان کلاس نہیں ہے۔ آپ اس صورتحال کو ٹھیک کرتے ہیں اور لاگ ان کرنے کے لیے اس کلاس میں ایک طریقہ کے ساتھ ایک لاگ ان کلاس بناتے ہیں اور دوسرا صارف کی حیثیت کو چیک کرنے کے لیے کہ وہ لاگ ان ہیں یا نہیں۔ ابھی تک آپ نے اس کلاس کی فعالیت اور ہمیں درکار طریقہ کو نافذ نہیں کیا ہے۔ آپ اس وقت ٹیسٹ چلاتے ہیں۔ اب یہ مرتب کرتا ہے، لیکن فوری طور پر ناکام ہوجاتا ہے۔ اب آپ کوڈ پر واپس جائیں اور ٹیسٹ پاس کرنے کے لیے فعالیت کو نافذ کریں۔ ہمارے معاملے میں، اس کا مطلب ہے کہ ہمیں نتیجہ ملنا چاہیے: "صارف لاگ ان نہیں ہے۔" آپ دوبارہ امتحان چلاتے ہیں اور اب یہ پاس ہو جاتا ہے۔ آئیے اگلے ٹیسٹ کی طرف چلتے ہیں۔ اب آئیے تصور کریں کہ آپ کو ایک ٹیسٹ لکھنے کی ضرورت ہے جسے "صارف لاگ ان ہے اگر اس نے درست صارف نام اور پاس ورڈ درج کیا ہے۔" آپ ایک یونٹ ٹیسٹ لکھتے ہیں جو لاگ ان کلاس کو تیز کرتا ہے اور صارف نام اور پاس ورڈ کے ساتھ لاگ ان کرنے کی کوشش کرتا ہے۔ یونٹ ٹیسٹ میں، آپ ایک بیان لکھتے ہیں کہ لاگ ان کلاس کو اس سوال کا جواب ہاں میں دینا چاہیے کہ آیا صارف لاگ ان ہے یا نہیں۔ آپ یہ نیا ٹیسٹ چلاتے ہیں اور یقیناً یہ ناکام ہوجاتا ہے کیونکہ آپ کی لاگ ان کلاس ہمیشہ واپس آتی ہے کہ صارف لاگ ان نہیں ہے۔ آپ اپنی لاگ ان کلاس میں واپس آتے ہیں اور صارف کے لاگ ان ہونے کی تصدیق کے لیے کچھ کوڈ لاگو کرتے ہیں۔ اس صورت میں، آپ کو یہ معلوم کرنا پڑے گا کہ اس ماڈیول کو کیسے الگ کرنا ہے۔ ابھی کے لیے، ایسا کرنے کا سب سے آسان طریقہ یہ ہے کہ آپ اپنے ٹیسٹ میں استعمال کیے گئے صارف نام اور پاس ورڈ کو ہارڈ کوڈ کریں، اور اگر وہ مماثل ہوں، تو نتیجہ واپس کریں "صارف لاگ ان ہے۔" آپ یہ تبدیلی کرتے ہیں، دونوں ٹیسٹ چلاتے ہیں، اور وہ دونوں پاس ہوتے ہیں۔ آئیے آخری مرحلے پر چلتے ہیں: آپ تیار کردہ کوڈ کو دیکھیں، اور اسے دوبارہ ترتیب دینے اور آسان بنانے کا طریقہ تلاش کریں۔ تو TDD الگورتھم یہ ہے:

1. ایک ٹیسٹ بنایا۔
2. ہم نے اس ٹیسٹ کے لیے کوڈ لکھا۔
3. کوڈ کو ری فیکٹر کیا۔

نتائج

اس مرحلے پر میں آپ کو یونٹ ٹیسٹنگ اور TDD کے بارے میں بس اتنا ہی بتانا چاہتا ہوں۔ درحقیقت، کوڈ ماڈیولز کو الگ تھلگ کرنے کی کوشش میں بہت سی مشکلات وابستہ ہیں، کیونکہ کوڈ بہت پیچیدہ اور الجھا ہوا ہو سکتا ہے۔ بہت کم کلاسیں مکمل تنہائی میں موجود ہیں۔ اس کے بجائے، ان میں انحصار ہے، اور ان انحصاروں میں انحصار ہے، وغیرہ۔ ایسے حالات سے نمٹنے کے لیے، TDD تجربہ کار طنز کا استعمال کرتا ہے، جو انحصار ماڈیولز میں اشیاء کی جگہ لے کر انفرادی کلاسوں کو الگ کرنے میں مدد کرتا ہے۔ یہ مضمون صرف ایک جائزہ ہے اور یونٹ ٹیسٹنگ اور TDD کا کچھ حد تک آسان تعارف ہے، ہم ڈمی ماڈیولز اور دیگر TDD تکنیکوں کے بارے میں تفصیل میں نہیں جائیں گے۔ خیال یہ ہے کہ آپ کو TDD اور یونٹ ٹیسٹنگ کے بنیادی تصورات اور اصول بتائے جائیں جو امید ہے کہ اب آپ کے پاس ہیں۔ اصل - https://simpleprogrammer.com/2017/01/30/tdd-unit-testing/