எனது "முடிக்கப்பட்ட" MERN-stack Zerodha குளோனை (clone) வைத்து Specmatic-ன் ஒப்பந்தச் சோதனைகளை (contract tests) நடத்திய அந்தத் தருணமே, எனது கைமுறைச் சோதனைகளில் (manual checks) கண்டறிய முடியாத ஐந்து உண்மையான குறைபாடுகளை அந்தத் கருவி சுட்டிக்காட்டியது. உருவாக்கப்பட்ட 178 சோதனைத் தொகுதிகளில் (test cases), உண்மையான பயனர்களைப் பாதிக்கும் விதமாக அந்தத் தொகுதியானது API-ஐச் சிதைத்தது—தவறான தரவு வகைகள் (invalid data types), தவறான சான்றுகளால் (malformed credentials) ஏற்படும் செயலிழப்புகள், அமைதியான தரவுச் சிதைவு (silent data corruption), ஐடெம்போடென்ட் அல்லாத (non-idempotent) சப்ஸ்கிரிப்ஷன்கள் மற்றும் CI கேட்டைத் (CI gate) தடுத்து நிறுத்திய ஒரு ஒப்பந்த மாற்றம் (breaking contract change) எனப் பலவற்றைச் செய்தது.

கைமுறைச் சோதனைகளில் பிழைகள் எவ்வாறு தப்பிச் சென்றன

இந்தத் திட்டம் Node.js backend, React front-end, MongoDB storage மற்றும் Razorpay போன்றவற்றை ஒருங்கிணைத்தது. நான் சப்ஸ்கிரைப்ஷன் மற்றும் பணம் செலுத்தும் முறைகளை (signup and payment flows) கைமுறையாகச் சோதித்தபோது அனைத்தும் சரியாக வேலை செய்வது போல் தோன்றியது. இருப்பினும், கைமுறைச் சோதனை என்பது "ஹேப்பி பாத்" (happy path) முறையை மட்டுமே சோதிக்கிறது: அதாவது பயனர்கள் திட்டமிட்டபடி செயல்படும்போது குறியீடு (code) எவ்வாறு செயல்படுகிறது என்பதை மட்டுமே அது உறுதி செய்கிறது. தவறான கோரிக்கைகள் (malformed requests) அல்லது எதிர்பாராத பயனர் நடத்தைகளைச் சமாளிக்க இந்தச் சேவைக்குத் திறன் உள்ளதா என்பதை அது நிரூபிப்பதில்லை.

நான் Specmatic-ஐ ஏற்கனவே உள்ள குறியீட்டில் பயன்படுத்தியபோது, ஒப்பந்தம் (contract)—அதாவது ஒவ்வொரு எண்ட்பாயிண்டின் (endpoint) கோரிக்கை மற்றும் பதில்களின் (request and response) தெளிவான விளக்கம்—உண்மையின் ஆதாரமாக (source of truth) செயல்பட்டது. பின்னர் அந்தத் கருவி, நேர்மறை மற்றும் எதிர்மறைச் சூழல்களின் (positive and negative scenarios) ஒரு மிகப்பெரிய தொகுப்பைத் தானாகவே உருவாக்கியது, இதில் பலவற்றை ஒரு மனிதச் சோதகர் (human tester) யோசித்துக் கூட எழுத wouldn't (would never think to write).

கண்டறியப்பட்ட ஐந்து குறைபாடுகள்

  • உள்ளீடு சரிபார்ப்பு இடைவெளிகள் (Input validation gaps) – ஒப்பந்தம் ஒரு முழு எண்ணை (integer) எதிர்பார்த்த போதிலும், /newOrder எண்ட்பாயிண்ட் quantity புலத்திற்குத் தசம எண்கள் (decimal numbers) மற்றும் சரங்களை (strings) ஏற்றுக் கொண்டது. தவறான தரவு வகைகளை அனுப்பிய சோதனைத் தொகுதிகள் API தவறாகச் செயல்படக் காரணமாயின.
  • கையாளுக்கப்படாத லாகின் பிழைகள் (Unhandled login errors) – அங்கீகாரப் பாதையில் (authentication route) தவறான சான்றுகளை (malformed credentials) வழங்கியபோது, குறியீட்டில் தரவு வகைச் சரிபார்ப்புகள் (type checks) இல்லாததால் ரன்டைம் விதிவிலக்கு (runtime exception) ஏற்பட்டது.
  • அமைதியான கட்டணச் சிதைவு (Silent payment corruption) – /verify-payment எண்ட்பாயிண்ட் amount-க்கு பூலியன் (boolean) மதிப்புகளை அனுமதித்தது. ஒரு true மதிப்பு உள்ளே நுழைந்தபோது, தரவுத்தளம் (database) பூஜ்ஜிய மதிப்பைக் கொண்டு வெற்றிகரமான கட்டணத்தைப் பதிவு செய்தது, இது வருவாய் புள்ளிவிவரங்களை அமைதியாகத் தவறாக உயர்த்தியது.
  • ஐடெம்போடென்சி இல்லாமை (Missing idempotency) – சோதனைத் தொகுப்பில் சப்ஸ்கிரைப்ஷன் முறையை இரண்டாவது முறை இயக்கியபோது அது தோல்வியடைந்தது, ஏனெனில் அந்த எண்ட்பாயிண்ட் ஏற்கனவே உள்ள பயனரைத் திரும்பத் திரும்ப உருவாக்க முயன்றதே தவிர, நகல்களைச் சரியாகக் கையாளவில்லை.
  • தடுக்கப்பட்ட ஒப்பந்த மாற்றம் (Breaking contract change caught) – நான் வேண்டுமென்றே ஒப்பந்தத்தில் ஒரு தரவு வகையை மாற்றினேன். CI பைப்லைன் (pipeline) அந்த மாற்றத்தை உடனடியாக நிராகரித்தது, இதன் மூலம் ஒரு தவறான வெளியீட்டைத் (breaking release) தடுத்தது.

CI பைப்லைன்களுக்கு ஒப்பந்தச் சோதனை ஏன் முக்கியமானது

  • பெரிய அளவில் எதிர்மறைச் சோதனை (Negative testing at scale) – 178 நிகழ்வுகளில் பெரும்பாலானவை விளிம்புநிலை உள்ளீடுகளாக (edge-case inputs) இருந்தன. அவற்றை ஒவ்வொன்றாகக் கைமுறையாக எழுதுவது அதிக நேரத்தை எடுத்துக்கொள்ளும்.
  • மூன்றாம் தரப்பு வாடிக்கையாளர்களுக்கான பாதுகாப்பு (Safety for third-party clients) – ஒரு சேவை வெளிப்புறப் பயனர்களுக்கு என்ன வாக்குறுதி அளிக்கிறது என்பதை ஒப்பந்தங்கள் வரையறுக்கின்றன. செயல்படுத்தல் (implementation) மாறினால், ஒப்பந்தச் சோதனை தோல்வியடையும், இது அடுத்தடுத்த பயன்பாடுகளைப் (downstream apps) பாதுகாக்கிறது.
  • வேகமான பின்னூட்டச் சுழற்சி (Fast feedback loop) – ஒரு தவறான மாற்றம் இணைக்கப்படுவதற்கு (merge) முன்பே CI கேட் அதைத் தடுத்தது, இதனால் குழுவினர் செலவு மிகுந்த ரோல்பேக் (rollback) செய்வதிலிருந்து தப்பினார்கள்.
  • மேம்படுத்தப்பட்ட குறியீட்டுத் தரம் (Improved code quality) – ஒப்பந்தத்தைச் சோதனை செய்யக்கூடியதாக மாற்ற, ஒரு actuator எண்ட்பாயிண்ட்டைச் சேர்ப்பதும் சப்ஸ்கிரைப்ஷன் முறையை ஐடெம்போடென்ட் (idempotent) ஆக்குவதும் அவசியமான படிகளாக இருந்தன, இது அந்தச் சேவையை மேலும் வலுப்படுத்தியது.

டெவலப்பர்கள் கவனிக்க வேண்டிய சமநிலை (trade-off)

ஒப்பந்தச் சோதனை பராமரிப்புச் சுமையை (maintenance overhead) அதிகரிக்கிறது. விவரக்குறிப்பு (specification) குறியீட்டுடன் ஒத்துப்போக வேண்டும், மேலும் சோதனை உருவாக்கும் செயல்முறை பில்ட் நேரத்தை (build times) அதிகரிக்கக்கூடும். குறிப்பாக கைமுறைச் சோதனை போதுமானதாகத் தோன்றும் சிறிய திட்டங்களுக்கு, இந்த கூடுதல் பாதுகாப்பு கூடுதல் முயற்சியைத் தகுதியாக்குமா என்பதைத் टीमें தீர்மானிக்க வேண்டும்.

அடுத்து கவனிக்க வேண்டியவை

  • பரந்த அளவிலான CI பயன்பாடு (Broader CI adoption) – அதிகப்படியான குழுக்கள் தங்கள் பைப்லைன்களில் ஒப்பந்தத் தொகுப்புகளை ஒருங்கிணைக்கும்போது, கருவிகள் வேகமாகவும் மற்றும் அதிக மாற்றியமைக்கக்கூடியதாகவும் (configurable) மாறும்.
  • தரப்படுத்தப்பட்ட ஒப்பந்த வடிவங்கள் (Standardized contract formats) – உருவாகி வரும் விவரக்குறிப்புகள், சேவைகள் மற்றும் குழுக்களிடையே ஒப்பந்தங்களைப் பகிர்ந்து கொள்வதை எளிதாக்கக்கூடும்.
  • விவரக்குறிப்பு புதுப்பிப்புகளின் தானியங்கி முறை (Automation of spec updates) – குறியீடு மாற்றங்களிலிருந்து ஒப்பந்தங்களைக் கண்டறியும் கருவிகள், கைமுறைப் பராமரிப்புச் சுமையைக் குறைக்கக்கூடும்.

UI சீராக இயங்குவதால் உங்கள் API வலுவாக இருப்பதாக நீங்கள் கருதினால், ஒரு ஒப்பந்தச் சோதனை மறைந்திருக்கும் பிழைகளை வெளிச்சம் போட்டுக் காட்டும். உங்கள் CI பைப்லைனில் செயல்படுத்தக்கூடிய ஒப்பந்தத்தைச் சேர்ப்பது, "பார்க்க நன்றாக இருக்கிறது" என்பதை "பாதுகாப்பானது என்று நிரூபிக்கப்பட்டது" என மாற்றும்.

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