എന്റെ "പൂർത്തിയായ" MERN-stack Zerodha ക്ലോണിന് നേരെ Specmatic-ന്റെ കോൺട്രാക്ട് ടെസ്റ്റുകൾ നടത്തുമ്പോൾ തന്നെ, എന്റെ മാനുവൽ പരിശോധനകളിൽ ഒരിക്കലും കണ്ടെത്താത്ത അഞ്ച് യഥാർത്ഥ പിഴവുകൾ ആ ടൂൾ കണ്ടെത്തി. 178 ടെസ്റ്റ് കേസുകളിൽ നിന്ന്, യഥാർത്ഥ ഉപയോക്താക്കളെ ബാധിക്കുമായിരുന്ന രീതിയിൽ API-യിൽ തകരാറുകൾ ഉണ്ടായതായി അത് കാണിച്ചു—തെറ്റായ ഡാറ്റാ ടൈപ്പുകൾ, തെറ്റായ ക്രെഡൻഷ്യലുകൾ നൽകിയാൽ ഉണ്ടാകുന്ന ക്രാഷുകൾ, ഡാറ്റാ തകരാറുകൾ, നോൺ-ഐഡെംപോറ്റന്റ് സൈൻ-അപ്പുകൾ, കൂടാതെ CI ഗേറ്റിനെ തടസ്സപ്പെടുത്തിയ ഒരു ബ്രേക്കിംഗ് കോൺട്രാക്ട് മാറ്റം എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു.

മാനുവൽ ടെസ്റ്റിംഗിലൂടെ എങ്ങനെയാണ് ഈ ബഗുകൾ രക്ഷപ്പെട്ടത്

ഈ പ്രോജക്റ്റിൽ ഒരു Node.js ബാക്കെൻഡ്, ഒരു React ഫ്രണ്ട്-എൻഡ്, MongoDB സ്റ്റോറേജ്, പേയ്‌മെന്റുകൾക്കായി Razorpay എന്നിവ സംയോജിപ്പിച്ചിരുന്നു. ഞാൻ സൈൻഅപ്പ്, പേയ്‌മെന്റ് ഫ്ലോകൾ മാനുവലായി പരിശോധിച്ചു, എല്ലാം ശരിയായി പ്രവർത്തിക്കുന്നതായി തോന്നി. എന്നാൽ, മാനുവൽ ടെസ്റ്റിംഗ് "ഹാപ്പി പാത്ത്" (happy path) മാത്രമേ പരിശോധിക്കുന്നുള്ളൂ: ഉപയോക്താക്കൾ ഉദ്ദേശിച്ച ഘട്ടങ്ങൾ പിന്തുടരുമ്പോൾ കോഡ് ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടെന്ന് അത് സ്ഥിരീകരിക്കുന്നു. എന്നാൽ തെറ്റായ രീതിയിലുള്ള റിക്വസ്റ്റുകളോ (malformed requests) അപ്രതീക്ഷിത ഉപയോക്തൃ പെരുമാറ്റങ്ങളോ നേരിടുമ്പോൾ സർവീസ് അതിജീവിക്കുമോ എന്ന് അത് തെളിയിക്കുന്നില്ല.

ഞാൻ നിലവിലുള്ള കോഡിലേക്ക് Specmatic ഉപയോഗിച്ചപ്പോൾ, ഓരോ എൻഡ്പോയിന്റുകളുടെയും റിക്വസ്റ്റ്, റെസ്പോൺസ് രൂപങ്ങളെക്കുറിച്ചുള്ള വ്യക്തമായ വിവരണമായ കോൺട്രാക്ട് (contract)—ഒരു സർവീസിന്റെ സ്രോതസ്സ് (source of truth) ആയി പ്രവർത്തിച്ചു. തുടർന്ന്, ടൂൾ പോസിറ്റീവ്, നെഗറ്റീവ് സാഹചര്യങ്ങളുടെ ഒരു വലിയ മാട്രിക്സ് ഓട്ടോമാറ്റിക്കായി നിർമ്മിച്ചു, ഇതിൽ പലതും ഒരു മാനുവൽ ടെസ്റ്റർ ഒരിക്കലും ചിന്തിക്കാത്തവയായിരുന്നു.

കണ്ടെത്തിയ അഞ്ച് പിഴവുകൾ

  • ഇൻപുട്ട് വാലിഡേഷൻ വിടവുകൾ (Input validation gaps) – കോൺട്രാക്ട് പ്രകാരം quantity ഫീൽഡിന് ഒരു ഇന്റീജർ (integer) ആവശ്യമാണെങ്കിലും, /newOrder എൻഡ്പോയിന്റ് ഡെസിമൽ നമ്പറുകളും സ്ട്രിംഗുകളും സ്വീകരിച്ചിരുന്നു. തെറ്റായ ടൈപ്പുകൾ അയച്ച ടെസ്റ്റുകൾ API-യുടെ പ്രവർത്തനത്തെ തെറ്റായി ബാധിച്ചു.
  • കൈകാര്യം ചെയ്യാത്ത ലോഗിൻ പിഴവുകൾ (Unhandled login errors) – ഓതന്റിക്കേഷൻ റൂട്ടിലേക്ക് തെറ്റായ രീതിയിലുള്ള ക്രെഡൻഷ്യലുകൾ നൽകിയപ്പോൾ, കോഡിൽ ടൈപ്പ് ചെക്കുകൾ ഇല്ലാത്തതിനാൽ റൺടൈം എക്സെപ്ഷൻ (runtime exception) ഉണ്ടായി.
  • നിശബ്ദമായ പേയ്‌മെന്റ് തകരാറുകൾ (Silent payment corruption) – /verify-payment എൻഡ്പോയിന്റ് amount-ന് ബൂലിയൻ (boolean) മൂല്യങ്ങൾ അനുവദിച്ചു. ഒരു true മൂല്യം വന്നപ്പോൾ, ഡാറ്റാബേസ് പൂജ്യം മൂല്യത്തോടെ ഒരു വിജയകരമായ പേയ്‌മെന്റ് രേഖപ്പെടുത്തി, ഇത് വരുമാന കണക്കുകളിൽ തെറ്റായ വർദ്ധനവ് ഉണ്ടാക്കി.
  • ഐഡെംപോറ്റൻസി ഇല്ലായ്മ (Missing idempotency) – ടെസ്റ്റ് സ്യൂട്ടിൽ സൈൻഅപ്പ് ഫ്ലോ രണ്ടാമത് പ്രവർത്തിപ്പിച്ചപ്പോൾ പരാജയപ്പെട്ടു, കാരണം ഡ്യൂപ്ലിക്കേറ്റ് യൂസറെ കൃത്യമായി കൈകാര്യം ചെയ്യുന്നതിന് പകരം നിലവിലുള്ള ഒരു യൂസറെ വീണ്ടും നിർമ്മിക്കാൻ എൻഡ്പോയിന്റ് ശ്രമിച്ചു.
  • കണ്ടെത്തിയ ബ്രേക്കിംഗ് കോൺട്രാക്ട് മാറ്റം (Breaking contract change caught) – ഞാൻ മനഃപൂർവ്വം കോൺട്രാക്റ്റിലെ ഒരു ഡാറ്റാ ടൈപ്പ് മാറ്റി. CI പൈപ്പ്‌ലൈൻ ആ മാറ്റം ഉടൻ തന്നെ നിരസിച്ചു, ഇത് ഒരു ബ്രേക്കിംഗ് റിലീസ് തടഞ്ഞു.

CI പൈപ്പ്‌ലൈനുകൾക്ക് കോൺട്രാക്ട് ടെസ്റ്റിംഗ് എന്തിനാണ് പ്രസക്തമാകുന്നത്

  • വലിയ തോതിലുള്ള നെഗറ്റീവ് ടെസ്റ്റിംഗ് (Negative testing at scale) – 178 കേസുകളിൽ ഭൂരിഭാഗവും എഡ്ജ്-കേസ് (edge-case) ഇൻപുട്ടുകളായിരുന്നു. അവ കൈകൊണ്ട് എഴുതുന്നത് വളരെയധികം സമയമെടുക്കുന്ന കാര്യമാണ്.
  • തേർഡ് പാർട്ടി ക്ലയന്റുകൾക്കുള്ള സുരക്ഷ (Safety for third-party clients) – ഒരു സർവീസ് പുറത്തുള്ള ഉപഭോക്താക്കൾക്ക് എന്ത് വാഗ്ദാനം ചെയ്യുന്നു എന്ന് കോൺട്രാക്റ്റുകൾ നിർവചിക്കുന്നു. ഇംപ്ലിമെന്റേഷനിൽ മാറ്റം വന്നാൽ കോൺട്രാക്ട് ടെസ്റ്റ് പരാജയപ്പെടുകയും, ഇത് ഡൗൺസ്ട്രീം ആപ്പുകളെ സംരക്ഷിക്കുകയും ചെയ്യുന്നു.
  • വേഗത്തിലുള്ള ഫീഡ്‌ബാക്ക് ലൂപ്പ് (Fast feedback loop) – ഒരു ബ്രേക്കിംഗ് മാറ്റം മെർജ് ചെയ്യുന്നതിന് മുമ്പ് തന്നെ CI ഗേറ്റ് അത് തടഞ്ഞു, ഇത് ടീമിനെ വലിയൊരു റോൾബാക്ക് (rollback) ഒഴിവാക്കാൻ സഹായിച്ചു.
  • മെച്ചപ്പെട്ട കോഡ് നിലവാരം (Improved code quality) – കോൺട്രാക്ട് ടെസ്റ്റ് ചെയ്യാൻ സാധിക്കുന്ന രീതിയിൽ മാറ്റങ്ങൾ വരുത്താൻ ഒരു ആക്ചുവേറ്റർ എൻഡ്പോയിന്റ് ചേർക്കുന്നതും സൈൻഅപ്പ് ഫ്ലോ ഐഡെംപോറ്റന്റ് ആക്കുന്നതും ആവശ്യമായ ഘട്ടങ്ങളായിരുന്നു, ഇത് സർവീസിനെ കൂടുതൽ ശക്തമാക്കി.

ഡെവലപ്പർമാർ പരിഗണിക്കേണ്ട ഗുണദോഷങ്ങൾ

കോൺട്രാക്ട് ടെസ്റ്റിംഗ് പരിപാലന ഭാരം (maintenance overhead) വർദ്ധിപ്പിക്കുന്നു. സ്പെസിഫിക്കേഷൻ കോഡുമായി ഒത്തുപോകണം, കൂടാതെ ടെസ്റ്റ് ജനറേഷൻ പ്രക്രിയ ബിൽഡ് സമയം വർദ്ധിപ്പിക്കാം. മാനുവൽ ടെസ്റ്റിംഗ് മതിയാകും എന്ന് തോന്നുന്ന ചെറിയ പ്രോജക്റ്റുകളിൽ, ഈ അധിക സുരക്ഷയ്ക്കായി കൂടുതൽ പരിശ്രമം ആവശ്യമാണോ എന്ന് ടീമുകൾ തീരുമാനിക്കേണ്ടതുണ്ട്.

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

  • വിപുലമായ CI സ്വീകാര്യത (Broader CI adoption) – കൂടുതൽ ടീമുകൾ കോൺട്രാക്ട് സ്യൂട്ടുകൾ അവരുടെ പൈപ്പ്‌ലൈനുകളിൽ സംയോജിപ്പിക്കുമ്പോൾ, ടൂളുകൾ കൂടുതൽ വേഗതയുള്ളതും കോൺഫിഗറബിൾ ആയതുമായി മാറും.
  • സ്റ്റാൻഡേർഡൈസ്ഡ് കോൺട്രാക്ട് ഫോർമാറ്റുകൾ (Standardized contract formats) – പുതിയ സ്പെസിഫിക്കേഷനുകൾ സർവീസുകൾക്കും ടീമുകൾക്കും ഇടയിൽ കോൺട്രാക്റ്റുകൾ പങ്കിടുന്നത് എളുപ്പമാക്കിയേക്കാം.
  • സ്പെക് അപ്‌ഡേറ്റുകളുടെ ഓട്ടോമേഷൻ (Automation of spec updates) – കോഡ് മാറ്റങ്ങളിൽ നിന്ന് കോൺട്രാക്റ്റുകൾ കണ്ടെത്താൻ കഴിയുന്ന ടൂളുകൾ മാനുവൽ പരിപാലന ഭാരം കുറച്ചേക്കാം.

നിങ്ങളുടെ UI സുഗമമായി പ്രവർത്തിക്കുന്നു എന്നതുകൊണ്ട് മാത്രം നിങ്ങളുടെ API സുരക്ഷിതമാണെന്ന് കരുതരുത്, ഒരു കോൺട്രാക്ട് ടെസ്റ്റ് മാനുവൽ പരിശോധനകളിൽ വിട്ടുപോയ മറഞ്ഞിരിക്കുന്ന പിഴവുകൾ വെളിപ്പെടുത്തിയേക്കാം. നിങ്ങളുടെ CI പൈപ്പ്‌ലൈനിൽ ഒരു എക്സിക്യൂട്ടബിൾ കോൺട്രാക്ട് ചേർക്കുന്നത് "നന്നായിട്ടുണ്ട്" എന്നതിനെ "സുരക്ഷിതമാണെന്ന് തെളിയിക്കപ്പെട്ടത്" എന്നതാക്കി മാറ്റുന്നു.

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