જે ક્ષણે મેં મારા "પૂર્ણ થયેલ" MERN-stack Zerodha ક્લોન સામે Specmatic ના contract tests ચલાવ્યા, ત્યારે આ ટૂલે પાંચ વાસ્તવિક ખામીઓ (defects) શોધી કાઢી જે મારા manual checks માં ક્યારેય પકડાઈ નહોતી. 178 જનરેટ થયેલા test cases માંથી, આ suite એ API ને એવી રીતે તોડી નાખ્યું જે વાસ્તવિક વપરાશકર્તાઓને અસર કરી શકત—અમાન્ય data types, malformed credentials પર crashes, silent data corruption, non-idempotent sign-ups અને એક breaking contract change જેણે CI gate ને તરત જ રોકી દીધું.

મેન્યુઅલ ટેસ્ટિંગમાંથી બગ્સ કેવી રીતે છટકી ગયા

આ પ્રોજેક્ટમાં Node.js backend, React front-end, MongoDB storage અને payments માટે Razorpay નો ઉપયોગ કરવામાં આવ્યો હતો. મેં signup અને payment flows ને મેન્યુઅલી ચલાવી જોયા અને બધું બરાબર કામ કરતું દેખાતું હતું. જોકે, manual testing ફક્ત 'happy path' ને જ તપાસે છે: તે ફક્ત એ જ કન્ફર્મ કરે છે કે જ્યારે વપરાશકર્તાઓ નિર્ધારિત સ્ટેપ્સ અનુસરે છે ત્યારે કોડ યોગ્ય રીતે કામ કરે છે. તે એ સાબિત નથી કરતું કે સર્વિસ malformed requests અથવા અણધારી client behavior સામે ટકી શકશે.

જ્યારે મેં Specmatic ને હાલના કોડ પર લાગુ કર્યું, ત્યારે contract—જે દરેક endpoint ના request અને response shapes નું સ્પષ્ટ વર્ણન છે—તે 'source of truth' તરીકે કામ કરી. ત્યારબાદ આ ટૂલે positive અને negative scenarios નું એક વિશાળ matrix auto-generate કર્યું, જેમાંથી ઘણા કિસ્સાઓ તો કોઈ માનવ ટેસ્ટર ક્યારેય વિચાર પણ ન શકે.

શોધાયેલી પાંચ ખામીઓ (defects)

  • Input validation gaps – /newOrder endpoint quantity ફિલ્ડ માટે decimal numbers અને strings સ્વીકારતું હતું, જ્યારે contract માં integer ની જરૂર હતી. ખોટા types મોકલતા જનરેટ થયેલા tests ને કારણે API ખોટી રીતે વર્તવા લાગ્યું.
  • Unhandled login errors – authentication route માં malformed credentials આપવાથી runtime exception આવી, કારણ કે કોડમાં type checks નો અભાવ હતો.
  • Silent payment corruption – /verify-payment endpoint amount માટે boolean values ની મંજૂરી આપતું હતું. જ્યારે true કિંમત પસાર થઈ, ત્યારે database એ શૂન્ય કિંમત સાથે સફળ payment નોંધ્યું, જેનાથી આવકના આંકડાઓ (revenue figures) ચુપચાપ વધી ગયા.
  • Missing idempotency – test suite માં signup flow બીજી વાર ચલાવતા તે નિષ્ફળ ગયો, કારણ કે endpoint એ duplicate user ને યોગ્ય રીતે હેન્ડલ કરવાને બદલે અસ્તિત્વ ધરાવતા યુઝરને ફરીથી બનાવવાનો પ્રયાસ કર્યો.
  • Breaking contract change caught – મેં જાણીજોઈને contract માં એક data type બદલ્યો. CI pipeline એ તરત જ આ ફેરફારને નકારી દીધો, જેનાથી એક breaking release અટકી ગઈ.

CI pipelines માટે contract testing શા માટે મહત્વનું છે

  • Negative testing at scale – 178 કિસ્સાઓમાંથી મોટાભાગના edge-case inputs હતા. તેને હાથથી લખવા અત્યંત સમય માંગી લે તેવું કામ હોત.
  • Safety for third-party clients – Contracts એ વ્યાખ્યાયિત કરે છે કે સર્વિસ બાહ્ય વપરાશકર્તાઓ (external consumers) ને શું વચન આપે છે. જો implementation બદલાય, તો contract test નિષ્ફળ જાય છે, જે downstream apps ને સુરક્ષિત રાખે છે.
  • Fast feedback loop – CI gate એ breaking change ને merge થતા પહેલા જ રોકી દીધું, જેનાથી ટીમ મોંઘા rollback થી બચી ગઈ.
  • Improved code quality – contract ને testable બનાવવા માટે એક actuator endpoint ઉમેરવો અને signup flow ને idempotent બનાવવો જરૂરી પગલાં હતા, જેનાથી સર્વિસ વધુ મજબૂત બની.

ડેવલપર્સે ધ્યાનમાં લેવા જેવો trade-off

Contract testing થી maintenance overhead વધે છે. specification ને કોડ સાથે સિંક (sync) રાખવું પડે છે, અને test generation પ્રક્રિયા build times વધારી શકે છે. ટીમોએ નક્કી કરવું પડશે કે વધારાની સુરક્ષા વધારાના પ્રયત્નોને યોગ્ય ઠેરવે છે કે નહીં, ખાસ કરીને નાના પ્રોજેક્ટ્સ માટે જ્યાં manual testing પૂરતી લાગે છે.

આગળ શું જોવું

  • Broader CI adoption – જેમ જેમ વધુ ટીમો તેમના pipelines માં contract suites ને integrate કરશે, તેમ તેમ tooling સંભવતઃ વધુ ઝડપી અને વધુ configurable બનશે.
  • Standardized contract formats – ઉભરતી specifications સર્વિસ અને ટીમો વચ્ચે contracts શેર કરવાનું સરળ બનાવી શકે છે.
  • Automation of spec updates – કોડ ફેરફારો પરથી contracts નો અંદાજ લગાવતા (infer કરતા) ટૂલ્સ મેન્યુઅલ જાળવણીનો બોજ ઘટાડી શકે છે.

જો તમે એમ માનો છો કે તમારો API મજબૂત છે કારણ કે UI સરળતાથી ચાલે છે, તો contract test ચલાવવાથી એવી છુપાયેલી ખામીઓ બહાર આવી શકે છે જે manual checks માં રહી ગઈ હોય. તમારા CI pipeline માં એક executable contract ઉમેરવાથી "looks good" એ "proven safe" માં બદલાઈ જાય છે.

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