Mara tu nilipofanya majaribio ya mkataba (contract tests) ya Specmatic kwenye nakala yangu ya "iliyokamilika" ya MERN-stack Zerodha, zana hiyo ilionyesha kasoro tano halisi ambazo ukaguzi wangu wa kawaida haukuwahi kuzigundua. Kati ya kesi 178 za majaribio zilizozalishwa, mfululizo huo uliharibu API kwa njia ambazo zingewapata watumiaji halisi—aina zisizo sahihi za data, kujiangusha (crashes) kutokana na taarifa zisizofaa, uharibifu wa data usioonekana, usajili usio na idempotency, na mabadiliko ya mkataba yanayovunja mfumo ambayo yaliizuia CI gate mara moja.

Jinsi wadudu (bugs) walivyopita kwenye majaribio ya kawaida

Mradi huo uliunganisha Node.js backend, React front-end, hifadhi ya MongoDB, na Razorpay kwa malipo. Nilipitia michakato ya usajili na malipo kwa mkono na kila kitu kilionekana kufanya kazi. Hata hivyo, majaribio ya kawaida hujaribu tu njia iliyokusudiwa (happy path): yanathibitisha kuwa kodi inafanya kazi wakati watumiaji wanafuata hatua zilizokusudiwa. Hayathibitishi kuwa huduma inaweza kuhimili maombi yaliyoharibika (malformed requests) au tabia zisizotarajiwa za mteja.

Nilipoelekeza Specmatic kwenye kodi iliyopo, mkataba—maelezo ya wazi ya umbo la ombi (request) na jibu (response) la kila endpoint—ulitumika kama chanzo cha ukweli. Kisha zana hiyo ilizalisha kiotomatiki matrix kubwa ya matukio chanya na hasi, ambayo mengi yake mjaribu wa kibinadamu asingewahi kufikiria kuandika.

Kasoro tano zilizogunduliwa

  • Mapungufu ya uhakiki wa data (Input validation gaps) – Endpoint ya /newOrder ilikubali namba za desimali na maandishi (strings) kwa ajili ya uwanja wa quantity, ingawa mkataba ulihitaji namba nzima (integer). Majaribio yaliyozalishwa yaliyotuma aina zisizo sahihi yalisababisha API isifanye kazi ipasavyo.
  • Makosa ya kuingia yasiyoshughulikiwa – Kutoa taarifa zisizofaa kwenye njia ya uthibitishaji (authentication route) kulisababisha hitilafu ya wakati wa utendaji (runtime exception) kwa sababu kodi ilikosa uhakiki wa aina (type checks).
  • Uharibifu wa malipo usioonekana – Endpoint ya /verify-payment iliruhusu thamani za boolean kwa ajili ya amount. Wakati true ilipopita, hifadhidata ilirekodi malipo yaliyofanikiwa yenye thamani ya sifuri, ikiongeza takwimu za mapato kwa siri.
  • Ukosefu wa idempotency – Kuendesha mchakato wa usajili mara ya pili katika mfululizo wa majaribio kulishindikana, kwani endpoint ilijaribu kutengeneza tena mtumiaji aliyekuwepo badala ya kushughulikia nakala hiyo kwa ufasaha.
  • Mabadiliko ya mkataba yanayovunja mfumo yaliyokamatwa – Nilibadilisha aina ya data kwenye mkataba kwa makusudi. Pipeline ya CI ilikataa mabadiliko hayo mara moja, ikizuia toleo linaloweza kuharibu mfumo.

Kwa nini majaribio ya mkataba ni muhimu kwa pipeline za CI

  • Majaribio hasi kwa kiwango kikubwa – Sehemu kubwa ya kesi hizo 178 zilikuwa ingizo za hali ya juu (edge-case inputs). Kuandika hizo kwa mkono kungechukua muda mwingi sana.
  • Usalama kwa wateja wa tatu – Mikataba huainisha kile ambacho huduma inaahidi kwa watumiaji wa nje. Ikiwa utekelezaji utabadilika, jaribio la mkataba litashindwa, hivyo kulinda programu zinazotegemea huduma hiyo.
  • Mzunguko wa mrejesho wa haraka – CI gate ilizuia mabadiliko yanayovunja mfumo kabla hayajajumuishwa, ikiwaokoa timu kutokana na kurudisha nyuma mfumo (rollback) kwa gharama kubwa.
  • Ubora wa kodi ulioimarishwa – Kuongeza actuator endpoint na kufanya mchakato wa usajili kuwa idempotent zilikuwa hatua muhimu za kufanya mkataba uweze kufanyiwa majaribio, jambo ambalo kwa upande wake liliimarisha huduma.

Makubaliano ya kutoa na kupokea (trade-off) ambayo watengenezaji wanapaswa kuyazingatia

Majaribio ya mkataba huongeza mzigo wa matengenezo. Maelezo (specification) lazima yaende sambamba na kodi, na mchakato wa kuzalisha majaribio unaweza kuongeza muda wa ujenzi (build times). Timu zinahitaji kuamua ikiwa usalama unaoongezwa unahalalisha juhudi za ziada, hasa kwa miradi midogo ambapo majaribio ya kawaida yanaonekana kutosha.

Nini cha kufuatilia baadaye

  • Utekelezaji mpana wa CI – Kadiri timu nyingi zinavyounganisha mfululizo wa mikataba kwenye pipeline zao, zana zitakuwa haraka zaidi na zenye uwezo mkubwa wa kurekebishika.
  • Miundo ya mkataba iliyosanifishwa – Maelezo yanayochipuka yanaweza kurahisisha ushirikiano wa mikataba kati ya huduma na timu mbalimbali.
  • Uotomatishaji wa sasisho za maelezo (spec updates) – Zana zinazotambua mikataba kutokana na mabadiliko ya kodi zinaweza kupunguza mzigo wa matengenezo ya kawaida.

Ikiwa unadhani API yako ni imara kwa sababu UI inafanya kazi vizuri, kuendesha jaribio la mkataba kunaweza kufichua hitilafu zilizojificha ambazo ukaguzi wa kawaida unazikosa. Kuongeza mkataba unaoweza kutekelezwa kwenye pipeline yako ya CI kunabadilisha "inaonekana vizuri" kuwa "imethibitishwa kuwa salama."

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