جیسے ہی میں نے اپنے "مکمل" MERN-stack Zerodha کلون پر Specmatic کے contract tests چلائے، اس ٹول نے پانچ ایسے حقیقی نقائص (defects) کی نشاندہی کی جو میرے دستی معائنے (manual checks) میں کبھی نہیں پکڑے گئے۔ 178 تیار کردہ ٹیسٹ کیسز میں سے، اس سوٹ (suite) نے API کو ان طریقوں سے خراب کیا جو حقیقی صارفین کو متاثر کر سکتے تھے—غلط ڈیٹا ٹائپس، غلط فارمیٹ والے کزیڈینشلز (credentials) پر کریش، خاموش ڈیٹا کرپشن (silent data corruption)، غیر آئیڈیمپوٹنٹ (non-idempotent) سائن اپس، اور ایک ایسا بریکنگ کنٹریکٹ چینج جس نے CI گیٹ کو روک دیا۔

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

اس پروجیکٹ میں Node.js بیک اینڈ، React فرنٹ اینڈ، MongoDB اسٹوریج اور ادائیگیوں کے لیے Razorpay کا استعمال کیا گیا تھا۔ میں نے سائن اپ اور پیمنٹ کے بہاؤ (flows) کا دستی طور پر جائزہ لیا اور سب کچھ ٹھیک معلوم ہوا۔ تاہم، دستی ٹیسٹنگ صرف "ہیپی پاتھ" (happy path) کا تجربہ کرتی ہے: یہ اس بات کی تصدیق کرتی ہے کہ جب صارفین مطلوبہ اقدامات پر عمل کرتے ہیں تو کوڈ صحیح کام کرتا ہے۔ یہ اس بات کا ثبوت نہیں دیتی کہ سروس غلط فارمیٹ والی درخواستوں (malformed requests) یا غیر متوقع کلائنٹ رویے کا مقابلہ کر سکے گی۔

جب میں نے Specmatic کو موجودہ کوڈ پر استعمال کیا، تو کنٹریکٹ—جو کہ ہر اینڈ پوائنٹ (endpoint) کی ریکویسٹ اور ریسپانس کی شکلوں کی واضح وضاحت ہے—حقیقت کے ماخذ (source of truth) کے طور پر کام آیا۔ اس کے بعد ٹول نے مثبت اور منفی منظرناموں (scenarios) کا ایک وسیع میٹرکس خودکار طور پر تیار کیا، جن میں سے بہت سے ایسے تھے جن کے بارے میں ایک انسانی ٹیسٹر کبھی نہیں سوچتا۔

سامنے آنے والے پانچ نقائص

  • ان پٹ ویلیڈیشن کے خلا (Input validation gaps) – /newOrder اینڈ پوائنٹ نے quantity فیلڈ کے لیے ڈیسیمل نمبرز اور اسٹرنگز کو قبول کر لیا، حالانکہ کنٹریکٹ کے مطابق اس کے لیے انٹیجر (integer) ہونا ضروری تھا۔ غلط ٹائپس بھیجنے والے تیار کردہ ٹیسٹ کے نتیجے میں API نے غلط طریقے سے کام کرنا شروع کر دیا۔
  • غیر ہینڈل شدہ لاگ ان ایررز – آتھنٹیکیشن روٹ (authentication route) کو غلط فارمیٹ والے کزیڈینشلز فراہم کرنے سے رن ٹائم ایکسیپشن (runtime exception) پیدا ہوئی کیونکہ کوڈ میں ٹائپ چیکس کی کمی تھی۔
  • خاموش پیمنٹ کرپشن – /verify-payment اینڈ پوائنٹ نے amount کے لیے بولین (boolean) ویلیوز کی اجازت دی۔ جب ایک true گزر گیا، تو ڈیٹا بیس نے صفر ویلیو کے ساتھ کامیاب ادائیگی ریکارڈ کر لی، جس سے خاموشی سے ریونیو کے اعداد و شمار بڑھ گئے۔
  • آئیڈیمپوٹینسی (Idempotency) کی کمی – ٹیسٹ سوٹ میں سائن اپ فلو کو دوسری بار چلانے پر ناکامی ہوئی، کیونکہ اینڈ پوائنٹ نے ڈپلیکیٹ کو بہتر طریقے سے ہینڈل کرنے کے بجائے ایک موجودہ صارف کو دوبارہ بنانے کی کوشش کی۔
  • بریکنگ کنٹریکٹ چینج کا پکڑا جانا – میں نے جان بوجھ کر کنٹریکٹ میں ایک ڈیٹا ٹائپ تبدیل کی۔ CI پائپ لائن نے فوری طور پر اس تبدیلی کو مسترد کر دیا، جس سے ایک بریکنگ ریلیز سے بچا جا سکا۔

CI پائپ لائنز کے لیے کنٹریکٹ ٹیسٹنگ کیوں اہم ہے

  • بڑے پیمانے پر نیگیٹو ٹیسٹنگ – 178 کیسز میں سے زیادہ تر ایج کیس (edge-case) ان پٹس تھے۔ انہیں ہاتھ سے لکھنا انتہائی وقت طلب کام ہوتا۔
  • تھرڈ پارٹی کلائنٹس کے لیے تحفظ – کنٹریکٹس یہ طے کرتے ہیں کہ ایک سروس بیرونی صارفین سے کیا وعدہ کرتی ہے۔ اگر امپلیمنٹیشن میں تبدیلی آتی ہے، تو کنٹریکٹ ٹیسٹ فیل ہو جاتا ہے، جو ڈاؤن اسٹریم ایپس (downstream apps) کی حفاظت کرتا ہے۔
  • تیز فیڈ بیک لوپ – CI گیٹ نے بریکنگ چینج کو مرج ہونے سے پہلے ہی روک دیا، جس سے ٹیم کو مہنگے رول بیک (rollback) سے بچا لیا گیا۔
  • بہتر کوڈ کوالٹی – کنٹریکٹ کو ٹیسٹ کے قابل بنانے کے لیے ایک ایکچوایٹر (actuator) اینڈ پوائنٹ شامل کرنا اور سائن اپ فلو کو آئیڈیمپوٹنٹ بنانا ضروری اقدامات تھے، جس نے بدلے میں سروس کو مزید مضبوط بنا دیا۔

وہ توازن (trade-off) جس پر ڈویلپرز کو غور کرنا چاہیے

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

آگے کیا دیکھنا ہے

  • وسیع تر CI اپناؤ – جیسے جیسے مزید ٹیمیں اپنے پائپ لائنز میں کنٹریکٹ سوٹس کو شامل کریں گی، ٹولنگ غالباً تیز تر اور زیادہ کنفیگر ایبل ہو جائے گی۔
  • معیاری کنٹریکٹ فارمیٹس – ابھرتی ہوئی سپیسیفیکیشنز سروسز اور ٹیموں کے درمیان کنٹریکٹس شیئر کرنا آسان بنا سکتی ہیں۔
  • سپیسیفیکیشن اپ ڈیٹس کی آٹومیشن – وہ ٹولز جو کوڈ کی تبدیلیوں سے کنٹریکٹس کا اندازہ لگاتے ہیں، دستی دیکھ بھال کے بوجھ کو کم کر سکتے ہیں۔

اگر آپ یہ فرض کرتے ہیں کہ آپ کی API مضبوط ہے کیونکہ UI ہموار چل رہا ہے، تو کنٹریکٹ ٹیسٹ کا ایک رن ان پوشیدہ خامیوں کو ظاہر کر سکتا ہے جنہیں دستی معائنے نہیں پکڑ پاتے۔ اپنی CI پائپ لائن میں ایک قابلِ عمل (executable) کنٹریکٹ شامل کرنا "ٹھیک لگ رہا ہے" کو "ثابت شدہ محفوظ" میں بدل دیتا ہے۔

Repository: https://github.com/priya3054/zerodha-specmatic