ٹیسٹ پر مبنی ترقی کیا ہے، نقطہ نظر اور فوائد

ٹیسٹ ڈرائیون ڈیولپمنٹ (TDD) ایک سافٹ ویئر ڈویلپمنٹ اپروچ ہے جہاں کوڈ کیا کرے گا اس کی وضاحت اور توثیق کرنے کے لیے ٹیسٹ کیسز تیار کیے جاتے ہیں۔

سافٹ ویئر کے جاری ہونے سے پہلے ہر خصوصیت کے لیے عملی طور پر ٹیسٹ کیسز بنائے جاتے ہیں اور ٹیسٹ کیے جاتے ہیں، اور اگر ٹیسٹ ناکام ہو جاتا ہے، تو ٹیسٹ پاس کرنے اور کوڈ کو سادہ اور بگ سے پاک بنانے کے لیے نیا کوڈ لکھا جاتا ہے (یا دوبارہ لکھا جاتا ہے یا پیچ کیا جاتا ہے)۔

ٹیسٹ ڈرائیون ڈیولپمنٹ (TDD) ایپلی کیشن میں ہر چھوٹی خصوصیت کے لیے ٹیسٹ ڈیزائن اور تیار کرنے کے ساتھ شروع ہوتا ہے۔ TDD فریم ورک ڈویلپرز کو صرف اس صورت میں نیا کوڈ لکھنے کی ہدایت کرتا ہے جب کوئی خودکار ٹیسٹ ناکام ہو جائے۔ یہ نقطہ نظر کوڈ کی نقل سے بچتا ہے۔ مکمل TDD ماڈیول ٹیسٹ پر مبنی ترقی ہے۔

ٹیسٹ ڈریوین ڈویلپمنٹ (TDD) کی ابتدا ایک بڑے سافٹ ویئر ڈیزائن پیراڈیم کے حصے کے طور پر ہوئی جسے Extreme Programming (XP) کہا جاتا ہے، جو کہ Agile سافٹ ویئر ڈویلپمنٹ طریقہ کار کا حصہ ہے۔

TDD کا آسان تصور یہ ہے کہ نیا کوڈ لکھنے سے پہلے (ترقی سے پہلے) ناکام ٹیسٹ لکھنا اور درست کرنا ہے۔ اس سے کوڈ کی نقل سے بچنے میں مدد ملتی ہے کیونکہ ہم ٹیسٹ پاس کرنے کے لیے ایک وقت میں تھوڑی مقدار میں کوڈ لکھتے ہیں۔ (ٹیسٹ ضرورت کی شرائط سے زیادہ کچھ نہیں ہیں جن کو پورا کرنے کے لیے ہمیں ٹیسٹ کرنا پڑتا ہے)۔

ٹیسٹ سے چلنے والی ترقی ایپلی کیشن کی اصل ترقی سے پہلے خودکار ٹیسٹ تیار کرنے اور چلانے کا عمل ہے۔ لہذا، TDD کو بعض اوقات ٹیسٹ فرسٹ ڈویلپمنٹ بھی کہا جاتا ہے۔

TDD نقطہ نظر کے مراحل

اس سے پہلے کہ کوئی نیا کوڈ لکھا جائے، پروگرامر کو سب سے پہلے ایک ناکام یونٹ ٹیسٹ بنانا ہوگا۔ پھر، پروگرامر - یا جوڑے، یا ہجوم - اس ضرورت کو پورا کرنے کے لیے کافی کوڈ بناتا ہے۔ ٹیسٹ پاس ہونے کے بعد، پروگرامر رویے کو تبدیل کیے بغیر بہتری لاتے ہوئے پروجیکٹ کو ری ایکٹر کر سکتا ہے۔

جب کہ TDD یونٹ کی سطح کے پروگرامر کے تعاملات پر توجہ مرکوز کرتا ہے، اس کے علاوہ دیگر مقبول طریقے ہیں، جیسے قبولیت ٹیسٹ سے چلنے والی ترقی (ATDD) یا برتاؤ سے چلنے والی ترقی (BDD)، جو ایسے ٹیسٹوں پر توجہ مرکوز کرتے ہیں جنہیں صارفین سمجھ سکتے ہیں۔

ان طریقوں میں کوڈنگ سے پہلے انجینئرنگ کے عملے اور گاہک کے درمیان باہمی تعاون کے ٹیسٹ کے طور پر حقیقی دنیا کی مثالیں بنانا، اور پھر کوڈنگ کے بعد ٹیسٹ چلانا یہ ظاہر کرنے کے لیے کہ کوڈ کو نافذ کیا گیا ہے۔ پہلے سے معلوم ہونے والے ٹیسٹ ہونے سے پہلی بار کا معیار بہتر ہوتا ہے۔ ATDD اور BDD کو ڈیولپرز، ٹیسٹرز اور کاروباری فریق کو کوڈ بننے سے پہلے سافٹ ویئر اور اس کے مضمرات کا تصور کرنے اور ان پر بحث کرنے کے لیے مل کر کام کرنے کی ضرورت ہوتی ہے۔

TDD کے فوائد

ٹیسٹ پر مبنی ترقی پرانے طریقوں سے کم وقت میں اعلیٰ معیار کی ایپلی کیشنز تیار کر سکتی ہے۔ TDD کے کامیاب نفاذ کے لیے ڈویلپرز اور ٹیسٹرز کو درست طریقے سے اندازہ لگانے کی ضرورت ہوتی ہے کہ ایپلیکیشن اور اس کی فعالیت کو حقیقی دنیا میں کس طرح استعمال کیا جائے گا۔

TDD ایک ضمنی اثر کے طور پر ایک ریگریشن ٹیسٹ سوٹ بناتا ہے جو انسانی دستی جانچ کو کم کر سکتا ہے، مسائل کو پہلے تلاش کر سکتا ہے، جس سے تیز تر حل نکلتے ہیں۔ TDD کی طریقہ کار کلاسک فیزڈ کوڈ سائیکل > test > fix > retest کے مقابلے میں پہلی بار کی کوریج اور معیار کو یقینی بناتی ہے۔ چونکہ ٹیسٹنگ ڈیزائن سائیکل کے اوائل میں کی جاتی ہے، اس لیے بعد میں ڈیبگ کرنے پر خرچ ہونے والے وقت اور رقم کو کم سے کم کیا جاتا ہے۔

متوقع فوائد:

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

TDD کے نقصانات

TDD کو کامیاب ہونے کے لیے کافی مہارت کی ضرورت ہوتی ہے، خاص طور پر یونٹ کی سطح پر۔ بہت سے میراثی نظام صرف یونٹ ٹیسٹنگ کو ذہن میں رکھ کر نہیں بنائے گئے ہیں، جس سے جانچ کے لیے اجزاء کو الگ کرنا ناممکن ہو جاتا ہے۔

اس کے علاوہ، بہت سے پروگرامرز کو الگ تھلگ کرنے اور صاف کوڈ بنانے کی مہارت کی کمی ہے۔ ٹیم کے تمام اراکین کو یونٹ ٹیسٹ بنانا اور برقرار رکھنا چاہیے ورنہ وہ جلد ہی متروک ہو جائیں گے۔ اور TDD پر نظر رکھنے والی تنظیم کو وقت لگانا پڑے گا، بعد میں تیزی سے جانے کے لیے ابھی تھوڑا سا سست ہونا پڑے گا۔

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

عام غلطیاں:

• بار بار ٹیسٹ چلانا بھول جاتے ہیں۔
• ایک ساتھ بہت سارے ٹیسٹ لکھیں۔
• ایسے ٹیسٹ لکھیں جو بہت بڑے یا ناقص ہوں۔
• حد سے زیادہ معمولی ٹیسٹ لکھنا، جیسے دعوے کو چھوڑنا
• معمولی کوڈ کے لیے ٹیسٹ لکھیں۔
• جزوی اپنانا: ورکنگ گروپ میں صرف چند ڈویلپرز TDD استعمال کرتے ہیں۔
• ناقص ٹیسٹ سویٹ کی دیکھ بھال، عام طور پر ایک ممنوعہ طویل وقت کے ساتھ ٹیسٹ سوٹ کی طرف جاتا ہے
• ٹیسٹ سویٹ ترک کر دیا گیا (یعنی شاذ و نادر ہی یا کبھی نہیں چلتا) - کبھی ناقص دیکھ بھال کی وجہ سے، کبھی ٹیم ٹرن اوور کی وجہ سے

TDD فلسفہ

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

ٹیسٹ پر مبنی ترقی کے چکر میں شامل مختلف مراحل یہ ہیں:

• ایک ٹیسٹ شامل کریں: TDD میں ہر نئی خصوصیت ایک ٹیسٹ کے ساتھ شروع ہوتی ہے جسے ناکام ہونا ضروری ہے کیونکہ اسے کسی بھی خصوصیت کے لاگو ہونے سے پہلے رکھا جاتا ہے۔ فیچر کو لاگو کرنے سے پہلے ٹیسٹ لکھنے کی شرط ڈیولپر کی طرف سے ضرورت کی واضح سمجھ ہے۔ یہ صارف کی کہانیوں اور استعمال کے معاملات کے ذریعے حاصل کیا جاتا ہے۔ لہذا ایک ڈویلپر پروگرام کوڈ لکھنے سے پہلے ضرورت کو سمجھتا ہے۔
• تمام ٹیسٹ چلائیں اور چیک کریں کہ آیا نیا کوڈ ناکام ہوتا ہے: یہ یقینی بناتا ہے کہ ٹیسٹ ہارنس صحیح طریقے سے کام کرتا ہے اور یہ کہ نیا ٹیسٹ بغیر کسی نئے کوڈ کے ناکام نہیں ہوتا ہے۔ یہ مرحلہ ٹیسٹ کی تصدیق بھی کرتا ہے اور اس امکان کو ختم کرتا ہے کہ نیا ٹیسٹ ہمیشہ پاس ہو جائے گا۔
• کوڈ لکھیں: اگلا مرحلہ جو اس کے بعد ہے وہ کوڈ لکھنا ہے جو ٹیسٹ کو صاف کرتا ہے۔ نیا کوڈ کامل نہیں ہے لیکن بعد میں ضروریات کے مطابق اس میں ترمیم کی جاتی ہے۔ یہ محض جانچ کے لیے ڈیزائن کیا گیا ہے اور اس میں کوئی دوسری خصوصیات نہیں ہیں۔
• خودکار ٹیسٹ چلائیں: اگر تیار کردہ ہر ٹیسٹ کیس آسانی سے ٹیسٹ پاس کرتا ہے، تو اس کا مطلب ہے کہ کوڈ تمام مطلوبہ تصریحات کو پورا کرتا ہے۔ پھر سائیکل کا آخری مرحلہ شروع کیا جا سکتا ہے۔
• ریفیکٹرنگ کوڈ: یہ نقل کو ہٹانے کے مترادف ہے۔ ری فیکٹرنگ کسی بھی موجودہ فعالیت کو نہیں توڑتی ہے اور پروڈکشن اور ٹیسٹ کوڈ کے درمیان نقل کو دور کرنے میں مدد کرتی ہے۔ کوڈ کو اب ضرورت کے مطابق صاف کر دیا گیا ہے۔
• دہرائیں: سائیکل ایک نئے ٹیسٹ کے ساتھ پچھلے معاملات کی طرح دہرایا جاتا ہے۔ ضروری ضرورت یہ ہے کہ قدم کا سائز چھوٹا ہو، ہر ٹیسٹ کے درمیان تقریباً 1-10 تبدیلیاں ہوتی ہیں۔ اگر نیا کوڈ ایک نئے ٹیسٹ میں ناکام ہوجاتا ہے، تو پروگرامر کو مزید ڈیبگنگ کرنی چاہیے۔ مسلسل انضمام الٹ جانے والی چوکیاں فراہم کرتا ہے۔

Ercole Palmeri