ನಾನು ನನ್ನ 'ಸಿದ್ಧಗೊಂಡ' MERN-stack Zerodha ಕ್ಲೋನ್ ವಿರುದ್ಧ Specmatic ನ ಕಾಂಟ್ರಾಕ್ಟ್ ಪರೀಕ್ಷೆಗಳನ್ನು (contract tests) ನಡೆಸಿದ ಕ್ಷಣದಲ್ಲೇ, ನನ್ನ ಮ್ಯಾನುಯಲ್ ಚೆಕ್‌ಗಳು ಎಂದಿಗೂ ಪತ್ತೆಹಚ್ಚದ ಐದು ನೈಜ ದೋಷಗಳನ್ನು ಈ ಟೂಲ್ ಗುರುತಿಸಿತು. ಜನರೇಟ್ ಮಾಡಲಾದ 178 ಟೆಸ್ಟ್ ಕೇಸ್‌ಗಳಲ್ಲಿ, ಈ ಸೂಟ್ API ಅನ್ನು ಅಂತಹ ರೀತಿಯಲ್ಲಿ ಹಾಳುಮಾಡಿತು, ಅದು ನಿಜವಾದ ಬಳಕೆದಾರರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತಿತ್ತು—ಅಂದರೆ ಅಮಾನ್ಯ ಡೇಟಾ ಪ್ರಕಾರಗಳು (invalid data types), ತಪ್ಪಾದ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳಿಂದ ಆಗುವ ಕ್ರ್ಯಾಶ್‌ಗಳು, ಮೌನ ಡೇಟಾ ದೋಷ (silent data corruption), ಅ-ಐಡೆಂಪೊಟೆಂಟ್ (non-idempotent) ಸೈನ್-ಅಪ್‌ಗಳು ಮತ್ತು CI ಗೇಟ್ ಅನ್ನು ತಕ್ಷಣವೇ ತಡೆದ ಕಾಂಟ್ರಾಕ್ಟ್ ಬದಲಾವಣೆ.

ಮ್ಯಾನುಯಲ್ ಟೆಸ್ಟಿಂಗ್ ಮೂಲಕ ಬಗ್‌ಗಳು ಹೇಗೆ ತಪ್ಪಿಸಿಕೊಂಡವು

ಈ ಯೋಜನೆಯು Node.js ಬ್ಯಾಕೆಂಡ್, React ಫ್ರಂಟ್-ಎಂಡ್, MongoDB ಸ್ಟೋರೇಜ್ ಮತ್ತು ಪಾವತಿಗಳಿಗಾಗಿ Razorpay ಅನ್ನು ಒಳಗೊಂಡಿತ್ತು. ನಾನು ಸೈನ್-ಅಪ್ ಮತ್ತು ಪಾವತಿ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ಪರೀಕ್ಷಿಸಿದೆ ಮತ್ತು ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಂತೆ ಕಂಡಿತು. ಆದರೆ, ಮ್ಯಾನುಯಲ್ ಟೆಸ್ಟಿಂಗ್ ಕೇವಲ 'ಹ್ಯಾಪಿ ಪಾತ್' (happy path) ಅನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸುತ್ತದೆ: ಬಳಕೆದಾರರು ಉದ್ದೇಶಿತ ಹಂತಗಳನ್ನು ಅನುಸರಿಸಿದಾಗ ಕೋಡ್ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಆದರೆ ಮೌಲ್ಯಯುತವಲ್ಲದ ವಿನಂತಿಗಳು (malformed requests) ಅಥವಾ ಅನಿರೀಕ್ಷಿತ ಕ್ಲೈಂಟ್ ವರ್ತನೆಯನ್ನು ಸೇವೆ ಹೇಗೆ ಎದುರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಇದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ನಾನು Specmatic ಅನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋಡ್ ಮೇಲೆ ಬಳಸಿದಾಗ, ಕಾಂಟ್ರಾಕ್ಟ್—ಅಂದರೆ ಪ್ರತಿ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನ ರಿಕ್ವೆಸ್ಟ್ ಮತ್ತು ರೆಸ್ಪಾನ್ಸ್ ರೂಪಗಳ ಸ್ಪಷ್ಟ ವಿವರಣೆ—ಸತ್ಯದ ಮೂಲವಾಗಿ (source of truth) ಕಾರ್ಯನಿರ್ವಹಿಸಿತು. ನಂತರ ಈ ಟೂಲ್ ಪಾಸಿಟಿವ್ ಮತ್ತು ನೆಗೆಟಿವ್ ಸನ್ನಿವೇಶಗಳ ಬೃಹತ್ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸೃಷ್ಟಿಸಿತು, ಇವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವುಗಳನ್ನು ಒಬ್ಬ ಮಾನವ ಟೆಸ್ಟರ್ ಎಂದಿಗೂ ಯೋಚಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಕಂಡುಬಂದ ಐದು ದೋಷಗಳು

  • ಇನ್‌ಪುಟ್ ವ್ಯಾಲಿಡೇಶನ್ ಕೊರತೆಗಳು/newOrder ಎಂಡ್‌ಪಾಯಿಂಟ್ quantity ಫೀಲ್ಡ್‌ಗಾಗಿ ದಶಮಾಂಶ ಸಂಖ್ಯೆಗಳು ಮತ್ತು ಸ್ಟ್ರಿಂಗ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿತ್ತು, ಆದರೆ ಕಾಂಟ್ರಾಕ್ಟ್‌ನಲ್ಲಿ ಅದು ಪೂರ್ಣಾಂಕ (integer) ಇರಬೇಕೆಂದು ಅಗತ್ಯವಿತ್ತು. ತಪ್ಪು ಪ್ರಕಾರಗಳನ್ನು ಕಳುಹಿಸಿದ ಜನರೇಟೆಡ್ ಟೆಸ್ಟ್‌ಗಳು API ಅಸಮರ್ಪಕವಾಗಿ ವರ್ತಿಸುವಂತೆ ಮಾಡಿದವು.
  • ಅಸಮರ್ಪಕವಾಗಿ ನಿರ್ವಹಿಸಲಾದ ಲಾಗಿನ್ ದೋಷಗಳು – ಅಥೆಂಟಿಕೇಶನ್ ರೂಟ್‌ಗೆ ತಪ್ಪಾದ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳನ್ನು ಒದಗಿಸಿದಾಗ, ಕೋಡ್‌ನಲ್ಲಿ ಟೈಪ್ ಚೆಕ್‌ಗಳ ಕೊರತೆಯಿಂದಾಗಿ ರನ್‌ಟೈಮ್ ಎಕ್ಸೆಪ್ಶನ್ (runtime exception) ಉಂಟಾಯಿತು.
  • ಮೌನ ಪಾವತಿ ದೋಷ/verify-payment ಎಂಡ್‌ಪಾಯಿಂಟ್ amount ಗಾಗಿ ಬೂಲಿಯನ್ (boolean) ಮೌಲ್ಯಗಳನ್ನು ಅನುಮತಿಸಿತು. true ಎಂಬ ಮೌಲ್ಯವು ಒಳಬಂದಾಗ, ಡೇಟಾಬೇಸ್ ಶೂನ್ಯ ಮೌಲ್ಯದೊಂದಿಗೆ ಯಶಸ್ವಿ ಪಾವತಿಯನ್ನು ದಾಖಲಿಸಿತು, ಇದು ಆದಾಯದ ಅಂಕಿಅಂಶಗಳನ್ನು ಮೌನವಾಗಿ ಹೆಚ್ಚಿಸಿತು.
  • ಐಡೆಂಪೊಟೆನ್ಸಿ ಕೊರತೆ – ಟೆಸ್ಟ್ ಸೂಟ್‌ನಲ್ಲಿ ಸೈನ್-ಅಪ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಎರಡನೇ ಬಾರಿಗೆ ನಡೆಸಿದಾಗ ಅದು ವಿಫಲವಾಯಿತು, ಏಕೆಂದರೆ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಬಳಕೆದಾರರನ್ನು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸುವ ಬದಲು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬಳಕೆದಾರರನ್ನು ಮತ್ತೆ ರಚಿಸಲು ಪ್ರಯತ್ನಿಸಿತು.
  • ಕಾಂಟ್ರಾಕ್ಟ್ ಬದಲಾವಣೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲಾಯಿತು – ನಾನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕಾಂಟ್ರಾಕ್ಟ್‌ನಲ್ಲಿ ಡೇಟಾ ಪ್ರಕಾರವನ್ನು ಬದಲಾಯಿಸಿದೆ. CI ಪೈಪ್‌ಲೈನ್ ಈ ಬದಲಾವಣೆಯನ್ನು ತಕ್ಷಣವೇ ತಿರಸ್ಕರಿಸಿತು, ಇದರಿಂದಾಗಿ ತಪ್ಪು ರಿಲೀಸ್ ಆಗುವುದನ್ನು ತಡೆಯಲಾಯಿತು.

CI ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗೆ ಕಾಂಟ್ರಾಕ್ಟ್ ಟೆಸ್ಟಿಂಗ್ ಏಕೆ ಮುಖ್ಯ

  • ಬೃಹತ್ ಪ್ರಮಾಣದ ನೆಗೆಟಿವ್ ಟೆಸ್ಟಿಂಗ್ – 178 ಪ್ರಕರಣಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಎಡ್ಜ್-ಕೇಸ್ (edge-case) ಇನ್‌ಪುಟ್‌ಗಳಾಗಿದ್ದವು. ಅವುಗಳನ್ನು ಕೈಯಿಂದ ಬರೆಯುವುದು ತುಂಬಾ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಕೆಲಸವಾಗಿತ್ತು.
  • ಥರ್ಡ್-ಪಾರ್ಟಿ ಕ್ಲೈಂಟ್‌ಗಳ ಸುರಕ್ಷತೆ – ಕಾಂಟ್ರಾಕ್ಟ್‌ಗಳು ಒಂದು ಸೇವೆ ಬಾಹ್ಯ ಬಳಕೆದಾರರಿಗೆ ನೀಡುವ ಭರವಸೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ. ಅನುಷ್ಠಾನವು (implementation) ಬದಲಾದರೆ, ಕಾಂಟ್ರಾಕ್ಟ್ ಟೆಸ್ಟ್ ವಿಫಲವಾಗುತ್ತದೆ, ಇದು ಮುಂದಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಕ್ಷಿಸುತ್ತದೆ.
  • ವೇಗದ ಫೀಡ್‌ಬ್ಯಾಕ್ ಲೂಪ್ – CI ಗೇಟ್ ತಪ್ಪು ಬದಲಾವಣೆಯು ಮರ್ಜ್ ಆಗುವ ಮೊದಲೇ ಅದನ್ನು ತಡೆಹಿಡಿಯಿತು, ಇದರಿಂದ ತಂಡವು ದುಬಾರಿ ರೋಲ್‌ಬ್ಯಾಕ್‌ನಿಂದ ಪಾರಾಯಿತು.
  • ಸುಧಾರಿತ ಕೋಡ್ ಗುಣಮಟ್ಟ – ಕಾಂಟ್ರಾಕ್ಟ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಬಹುದಾಗಿಸಲು (testable) ಆಕ್ಟಿವೇಟರ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಸೇರಿಸುವುದು ಮತ್ತು ಸೈನ್-ಅಪ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಐಡೆಂಪೊಟೆಂಟ್ ಮಾಡುವುದು ಅಗತ್ಯ ಕ್ರಮಗಳಾಗಿದ್ದವು, ಇದು ಸೇವೆಯನ್ನು ಮತ್ತಷ್ಟು ಬಲಪಡಿಸಿತು.

ಡೆವಲಪರ್‌ಗಳು ಪರಿಗಣಿಸಬೇಕಾದ ಸಮತೋಲನ (trade-off)

ಕಾಂಟ್ರಾಕ್ಟ್ ಟೆಸ್ಟಿಂಗ್ ನಿರ್ವಹಣಾ ಹೊರೆಯನ್ನು (maintenance overhead) ಹೆಚ್ಚಿಸುತ್ತದೆ. ಸ್ಪೆಸಿಫಿಕೇಶನ್ ಕೋಡ್‌ನೊಂದಿಗೆ ಸಮಕಾಲೀನವಾಗಿರಬೇಕು ಮತ್ತು ಟೆಸ್ಟ್ ಜನರೇಟ್ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯು ಬಿಲ್ಡ್ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸಬಹುದು. ಮ್ಯಾನುಯಲ್ ಟೆಸ್ಟಿಂಗ್ ಸಾಕಾಗುತ್ತದೆ ಎಂದು ಅನಿಸುವ ಸಣ್ಣ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಿಗೆ, ಈ ಹೆಚ್ಚುವರಿ ಸುರಕ್ಷತೆಯು ಹೆಚ್ಚುವರಿ ಪ್ರಯತ್ನವನ್ನು ಸಮರ್ಥಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ತಂಡಗಳು ನಿರ್ಧರಿಸಬೇಕಾಗುತ್ತದೆ.

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು

  • ವ್ಯಾಪಕವಾದ CI ಅಳವಡಿಕೆ – ಹೆಚ್ಚಿನ ತಂಡಗಳು ತಮ್ಮ ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗೆ ಕಾಂಟ್ರಾಕ್ಟ್ ಸೂಟ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತಿದ್ದಂತೆ, ಟೂಲಿಂಗ್ ಹೆಚ್ಚು ವೇಗವಾಗಿ ಮತ್ತು ಹೆಚ್ಚು ಕಾನ್ಫಿಗರಬಲ್ ಆಗುವ ಸಾಧ್ಯತೆಯಿದೆ.
  • ಪ್ರಮಾಣೀಕೃತ ಕಾಂಟ್ರಾಕ್ಟ್ ಫಾರ್ಮ್ಯಾಟ್‌ಗಳು – ಉದಯೋನ್ಮುಖ ಸ್ಪೆಸಿಫಿಕೇಶನ್‌ಗಳು ಸೇವೆಗಳು ಮತ್ತು ತಂಡಗಳ ನಡುವೆ ಕಾಂಟ್ರಾಕ್ಟ್‌ಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದನ್ನು ಸುಲಭಗೊಳಿಸಬಹುದು.
  • ಸ್ಪೆಕ್ ಅಪ್‌ಡೇಟ್‌ಗಳ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವಿಕೆ – ಕೋಡ್ ಬದಲಾವಣೆಗಳಿಂದ ಕಾಂಟ್ರಾಕ್ಟ್‌ಗಳನ್ನು ಅಂದಾಜಿಸುವ (infer) ಟೂಲ್‌ಗಳು ಮ್ಯಾನುಯಲ್ ನಿರ್ವಹಣೆಯ ಹೊರೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.

ನಿಮ್ಮ UI ಸುಗಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ನೀವು ನಿಮ್ಮ API ಸದೃಢವಾಗಿದೆ ಎಂದು ಭಾವಿಸಿದರೆ, ಕಾಂಟ್ರಾಕ್ಟ್ ಟೆಸ್ಟ್ ಮ್ಯಾನುಯಲ್ ಚೆಕ್‌ಗಳು ತಪ್ಪಿಸಿಕೊಳ್ಳುವ ಗುಪ್ತ ದೋಷಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು. ನಿಮ್ಮ CI ಪೈಪ್‌ಲೈನ್‌ಗೆ ಎಕ್ಸಿಕ್ಯೂಟಬಲ್ ಕಾಂಟ್ರಾಕ್ಟ್ ಅನ್ನು ಸೇರಿಸುವುದು 'ನೋಡಲು ಚೆನ್ನಾಗಿದೆ' ಎಂಬುದನ್ನು 'ಪರೀಕ್ಷಿಸಿದ ಸುರಕ್ಷಿತವಾಗಿದೆ' ಎಂಬದಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ.

ರಿಪೊಸಿಟರಿ: https://github.com/priya3054/zerodha-specmatic