जेव्हा मी माझ्या "पूर्ण झालेल्या" MERN-stack Zerodha क्लोनवर Specmatic चे contract tests चालवले, तेव्हा या टूलने पाच वास्तविक दोष (defects) शोधून काढले जे माझ्या मॅन्युअल तपासणीत कधीच सापडले नव्हते. १७८ जनरेट केलेल्या टेस्ट केसेसपैकी, या सुईटने (suite) API मध्ये अशा प्रकारे त्रुटी निर्माण केल्या ज्याचा परिणाम प्रत्यक्ष वापरकर्त्यांवर झाला असता—जसे की अवैध डेटा प्रकार (invalid data types), चुकीच्या क्रेडेंशियल्समुळे होणारे क्रॅश, सायलेंट डेटा करप्शन, नॉन-आयडेम्पोटेंट (non-idempotent) साइन-अप्स आणि एक ब्रेकिंग कॉन्ट्रॅक्ट बदल ज्याने CI गेटला थांबवले.

मॅन्युअल टेस्टिंगमध्ये हे बग्स कसे सुटले

या प्रोजेक्टमध्ये Node.js बॅकएंड, React फ्रंट-एंड, MongoDB स्टोरेज आणि पेमेंटसाठी Razorpay यांचा समावेश होता. मी साइनअप आणि पेमेंट फ्लो मॅन्युअली तपासून पाहिले आणि सर्व काही व्यवस्थित काम करत असल्याचे दिसले. मात्र, मॅन्युअल टेस्टिंग फक्त 'हॅपी पाथ' (happy path) तपासते: म्हणजेच वापरकर्ते ठरवलेल्या पायऱ्यांचे पालन करतात तेव्हा कोड व्यवस्थित काम करतो की नाही, हे ती तपासते. परंतु, सेवा (service) चुकीच्या विनंत्या (malformed requests) किंवा अनपेक्षित क्लायंट वर्तनामध्ये टिकून राहू शकते, हे ती सिद्ध करत नाही.

जेव्हा मी Specmatic ला अस्तित्वात असलेल्या कोडवर लागू केले, तेव्हा 'कॉन्ट्रॅक्ट'—जे प्रत्येक एंडपॉइंटच्या रिक्वेस्ट आणि रिस्पॉन्सच्या स्वरूपाचे स्पष्ट वर्णन असते—ने 'सोर्स ऑफ ट्रुथ' (source of truth) म्हणून काम केले. त्यानंतर या टूलने पॉझिटिव्ह आणि निगेटिव्ह सिनेरिओजचा एक मोठा मॅट्रिक्स ऑटो-जनरेट केला, ज्यातील अनेक गोष्टींचा विचार एखादा मानवी टेस्टर कधीच करणार नाही.

शोधले गेलेले पाच दोष

  • Input validation gaps – /newOrder एंडपॉइंट quantity फील्डसाठी डेसिमल नंबर्स आणि स्ट्रिंग्स स्वीकारत होता, जरी कॉन्ट्रॅक्टमध्ये पूर्णांक (integer) आवश्यक होता. चुकीचे प्रकार पाठवणाऱ्या जनरेट केलेल्या टेस्ट्समुळे API मध्ये त्रुटी निर्माण झाल्या.
  • Unhandled login errors – ऑथेंटिकेशन रूटला चुकीचे क्रेडेंशियल्स पुरवल्यामुळे रनटाइम एक्सेप्शन (runtime exception) आले, कारण कोडमध्ये टाइप चेक्सचा अभाव होता.
  • Silent payment corruption – /verify-payment एंडपॉइंटने amount साठी बुलियन (boolean) व्हॅल्यूजना परवानगी दिली. जेव्हा true व्हॅल्यू पाठवली गेली, तेव्हा डेटाबेसने शून्य मूल्यासह यशस्वी पेमेंट रेकॉर्ड केले, ज्यामुळे महसुलाच्या आकड्यांमध्ये (revenue figures) नकळत वाढ झाली.
  • Missing idempotency – टेस्ट सुईटमध्ये साइनअप फ्लो दुसऱ्यांदा चालवल्यास तो अयशस्वी झाला, कारण एंडपॉइंटने डुप्लिकेट युजरला व्यवस्थित हाताळण्याऐवजी अस्तित्वात असलेल्या युजरला पुन्हा तयार करण्याचा प्रयत्न केला.
  • Breaking contract change caught – मी मुद्दाम कॉन्ट्रॅक्टमध्ये डेटा टाइप बदलला. CI पाइपलाइनने तो बदल त्वरित नाकारला, ज्यामुळे एक ब्रेकिंग रिलीज रोखला गेला.

CI पाइपलाइन्ससाठी कॉन्ट्रॅक्ट टेस्टिंग का महत्त्वाचे आहे

  • Negative testing at scale – १७८ पैकी बहुतेक केसेस या 'एज-केस' (edge-case) इनपुट्स होत्या. त्या हाताने लिहिणे अत्यंत वेळखाऊ ठरले असते.
  • Safety for third-party clients – कॉन्ट्रॅक्ट्स हे एखादी सेवा बाह्य ग्राहकांना (external consumers) काय वचन देते हे परिभाषित करतात. जर अंमलबजावणीमध्ये (implementation) बदल झाला, तर कॉन्ट्रॅक्ट टेस्ट फेल होते, ज्यामुळे डाउनस्ट्रीम ॲप्स सुरक्षित राहतात.
  • Fast feedback loop – CI गेटने एखादा ब्रेकिंग बदल मर्ज होण्यापूर्वीच थांबवला, ज्यामुळे टीमला खर्चिक रोलबॅकपासून वाचवले.
  • Improved code quality – कॉन्ट्रॅक्ट टेस्ट करण्यायोग्य बनवण्यासाठी ॲक्च्युएटर एंडपॉइंट (actuator endpoint) जोडणे आणि साइनअप फ्लो आयडेम्पोटेंट (idempotent) करणे आवश्यक पावले होती, ज्यामुळे सेवा अधिक मजबूत झाली.

डेव्हलपर्सनी विचारात घ्यायचे फायदे आणि तोटे (Trade-off)

कॉन्ट्रॅक्ट टेस्टिंगमुळे मेंटेनन्सचा भार (maintenance overhead) वाढतो. स्पेसिफिकेशन कोडसोबत सुसंगत असणे आवश्यक आहे आणि टेस्ट जनरेशन प्रक्रियेमुळे बिल्ड वेळ वाढू शकतो. विशेषतः लहान प्रोजेक्ट्ससाठी, जिथे मॅन्युअल टेस्टिंग पुरेसे वाटते, तिथे वाढीव सुरक्षा या अतिरिक्त प्रयत्नांना पात्र आहे का, याचा निर्णय टीमला घ्यावा लागेल.

पुढे काय पाहायचे

  • Broader CI adoption – जसे अधिक टीम्स त्यांच्या पाइपलाइन्समध्ये कॉन्ट्रॅक्ट सुईट्स समाविष्ट करतील, तसे टूलिंग अधिक वेगवान आणि कॉन्फिगर करण्यायोग्य होईल.
  • Standardized contract formats – उदयोन्मुख स्पेसिफिकेशन्समुळे विविध सेवा आणि टीम्समध्ये कॉन्ट्रॅक्ट्स शेअर करणे सोपे होऊ शकते.
  • Automation of spec updates – कोडमधील बदलांवरून कॉन्ट्रॅक्ट्सचा अंदाज घेणारी (infer) टूल्स मॅन्युअल देखभालीचा भार कमी करू शकतात.

जर तुम्हाला असे वाटत असेल की UI व्यवस्थित चालत असल्यामुळे तुमचा API भक्कम आहे, तर कॉन्ट्रॅक्ट टेस्ट रन केल्यास मॅन्युअल तपासणीत सुटलेले छुपे दोष समोर येऊ शकतात. तुमच्या CI पाइपलाइनमध्ये एक्झिक्युटेबल कॉन्ट्रॅक्ट जोडल्यामुळे "looks good" चे रूपांतर "proven safe" मध्ये होते.

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