ಇದು ಒಂದು Slack ಸಂದೇಶದೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಬಿಲ್ಡ್ ಕೆಂಪಗಿದೆ (red). ನೀವು ವಿಫಲತೆಗಳನ್ನು (failures) ಸ್ಕ್ರೋಲ್ ಮಾಡಿ, ಮುಖ ಸೊ ಇರಿಸಿಕೊಂಡು, ಅದೇ ಪರೀಕ್ಷೆಯನ್ನು ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಮತ್ತೆ ರನ್ ಮಾಡ್ತೀರಾ. ಅದು ಪಾಸಾಗುತ್ತದೆ (Green). ನೀವು CI ಕೆಲಸವನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತೀರಿ. ಬಹುಶಃ ಅದು ಒಂದು ಸಣ್ಣ ತಪ್ಪು ಇರಬಹುದು ಎಂದು ಅಂದುಕೊಳ್ಳುತ್ತೀರಿ. ಆದರೆ ವಿಫಲತೆಯು ಮತ್ತೆ ಬರುತ್ತದೆ, ಅದು ಸರ್ವರ್‌ನಲ್ಲಿ ಹಠಾತ್ತಾಗಿ ಮತ್ತು ಪದೇ ಪದೇ ಸಂಭವಿಸುತ್ತದೆ, ಆದರೆ ನಿಮಗೆ ಕಾಣಿಸುವುದಿಲ್ಲ.

CI ನಲ್ಲಿ ವಿಫಲವಾಗಿ, ಸ್ಥಳೀಯವಾಗಿ (locally) ಪಾಸಾಗುವ ಬ್ರೌಸರ್ ಪರೀಕ್ಷೆಯು ಕೇವಲ ಕಿರಿಕಿರಿ ಮಾತ್ರವಲ್ಲ. ಇದು ಅಪನಂಬಿಕೆಯನ್ನು ಬೆಳೆಸುತ್ತದೆ. ತಂಡಗಳು ಸಮಯದ (timing) ಮೇಲೆ ದೂಷಣೆ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಅವರು ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರಗಳನ್ನು (temporary fixes) ಅಳವಡಿಸುತ್ತಾರೆ, ಅವು ಎಂದಿಗೂ ಹೋಗುವುದಿಲ್ಲ. ಇಲ್ಲಿ ಒಂದು setTimeout, ಅಲ್ಲಿ ಒಂದು .wait(5000). ಇದರಿಂದ ಪರೀಕ್ಷಾ ಸ್ಯೂಟ್ (test suite) ನಿಧಾನವಾಗುತ್ತದೆ. ವಿಫಲತೆಗಳು ಮತ್ತೆ ಮತ್ತೆ ಬರುತ್ತವೆ. ಆ flaky ಪರೀಕ್ಷೆಗಳು ಶಾಶ್ವತವಾಗಿ ಉಳಿಯುತ್ತವೆ, ಮತ್ತು ಅಂತಿಮವಾಗಿ ಎಲ್ಲರೂ ಕೆಂಪು ಪೈಪ್‌ಲೈನ್ ಅನ್ನು (red pipeline) ಕೇವಲ ಹಿನ್ನೆಲೆಯ ಶಬ್ದದಂತೆ (background noise) ಪರಿಗಣಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.

ಅದು ಅಪಾಯಕಾರಿ. ಸುಳ್ಳು ಎಚ್ಚರಿಕೆ ನೀಡುವ (cries wolf) ಪರೀಕ್ಷಾ ಸ್ಯೂಟ್ ನಿಮಗೆ ಬೇಡ.

CI ಹಾಳಾಗಿಲ್ಲ; ಅದು ಕೇವಲ ವಿಭಿನ್ನವಾಗಿದೆ

CI ಪರಿಸರಗಳು (environments) ಯಾದೃಚ್ಛಿಕವಾಗಿಲ್ಲ (random). ಅವು ನಿರ್ಧಾರಿತವಾಗಿವೆ (deterministic). ಸಮಸ್ಯೆ ಏನೆಂದರೆ, ಅವು ನಿಮ್ಮ MacBook ಅಥವಾ Linux ವರ್ಕ್‌ಸ್ಟೇಷನ್ ಅಲ್ಲದ ಒಂದು ವ್ಯವಸ್ಥೆಯ ಬಗ್ಗೆ ನಿರ್ಧಾರಿತವಾಗಿವೆ. ನಿಮ್ಮ ಸ್ಥಳೀಯ ಸೆಟಪ್ ಕೆಲವು ವ್ಯತ್ಯಾಸಗಳನ್ನು ಮರೆಮಾಚುತ್ತದೆ, ಆದರೆ ಸ್ವಚ್ಛವಾದ CI ರನ್ನರ್ (runner) ಅವುಗಳನ್ನು ತಕ್ಷಣವೇ ಎತ್ತಿ ತೋರಿಸುತ್ತದೆ.

ಎಷ್ಟು ಭಾಗಗಳು ವಿಭಿನ್ನವಾಗಿರುತ್ತವೆ ಎಂದು ಯೋಚಿಸಿ. ನಿಮ್ಮ ಸ್ಥಳೀಯ ಯಂತ್ರವು hot module reloading ನೊಂದಿಗೆ ಡೆವಲಪ್‌ಮೆಂಟ್ ಸರ್ವರ್ ಅನ್ನು ರನ್ ಮಾಡಬಹುದು, ಆದರೆ CI tree shaking ಮತ್ತು minification ನೊಂದಿಗೆ ಪ್ರೊಡಕ್ಷನ್ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಅನ್ನು (production artifact) ನಿರ್ಮಿಸುತ್ತದೆ. ಇದು ಕೇವಲ ಕೋಡ್ ಪಥಗಳನ್ನು (code paths) ತೆಗೆದುಹಾಕಬಹುದು ಅಥವಾ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಕ್ರಮವನ್ನು (execution order) ಬದಲಾಯಿಸಬಹುದು. ಡಿಪೆಂಡೆನ್ಸಿ ಟ್ರೀಗಳು (Dependency trees) ಬದಲಾಗುತ್ತವೆ. ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಆವೃತ್ತಿಯು ಕೇವಲ ಒಂದು ಸಣ್ಣ ಬದಲಾವಣೆಯಿದ್ದರೂ, ಒಂದೇ ರೀತಿಯ ಕಾಣುವ lockfile ವಿಭಿನ್ನವಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದು. ನೆಟ್‌ವರ್ಕ್ ಅನುಕ್ರಮಗಳು (sequences) ಬದಲಾಗುತ್ತವೆ. ನಿಮ್ಮ ಕಚೇರಿಯ Wi-Fi ಒಂದು ಹಂತದಲ್ಲಿ staging API ಅನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು; ಆದರೆ CI ರನ್ನರ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನ ಹಿಂದಿರುವ ಬೇರೆ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು, ಇದು ನೀವು ಎಂದಿಗೂ ನೋಡದ ವಿಳಂಬವನ್ನು (latency) ಉಂಟುಮಾಡಬಹುದು.

ಬ್ರೌಸರ್‌ಗಳೇ ವಿವಿಧ ಪರಿಸರಗಳಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತವೆ. ನಿಮ್ಮ ಸ್ಥಳೀಯ Chrome ನಲ್ಲಿ ಎಕ್ಸ್‌ಟೆನ್ಶನ್‌ಗಳು, ಕ್ಯಾಶ್ ಮಾಡಿದ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳು, ಪರ್ಸಿಸ್ಟೆಂಟ್ ಲೋಕಲ್ ಸ್ಟೋರೇಜ್ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್ ಆಕ್ಸಿಲರೇಶನ್ ಹೊಂದಿರುವ GPU ಇರುತ್ತದೆ. CI ಪ್ರತಿ ಬಾರಿ ರನ್ ಆಗುವಾಗಲೂ ಖಾಲಿ ಪ್ರೊಫೈಲ್‌ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಬ್ರೌಸರ್ ಲೈಫ್‌ಸೈಕಲ್‌ಗಳು ವಿಭಿನ್ನವಾಗಿರುತ್ತವೆ. ರೆಂಡರಿಂಗ್ ಪಥಗಳು (Rendering paths) ವಿಭಿನ್ನವಾಗಿರುತ್ತವೆ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿರುವ ಫಾಂಟ್‌ಗಳು CI ನಲ್ಲಿ ಬದಲಾಗಬಹುದು. ವ್ಯೂಪೋರ್ಟ್ ಸೈಸಿಂಗ್ (Viewport sizing) ಮತ್ತು ಡಿವೈಸ್ ಪಿಕ್ಸೆಲ್ ರೇಶಿಯೋಗಳು ಬದಲಾಗುತ್ತವೆ, ಇದು ರೆಸ್ಪಾನ್ಸಿವ್ ಬ್ರೇಕ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು (responsive breakpoints) ಬದಲಾಯಿಸಬಹುದು ಅಥವಾ lazy-loading ನ ವರ್ತನೆಯನ್ನು ಬದಲಿಸಬಹುದು.

ಈ ಅಂತರಗಳು ನಿಜವಾದವು. ಅವು ಯಾಂತ್ರಿಕವಾಗಿವೆ. ಅವು ಯಾದೃಚ್ಛಿಕ ಎಂದು ನಂಬುವುದು ಅವುಗಳನ್ನು ಹೋಗಲಾಡಿಸುವುದಿಲ್ಲ.

ಪ್ರಿವ್ಯೂ ಎನ್ವಿರಾನ್‌ಮೆಂಟ್‌ಗಳು ಸುಳ್ಳು ಹೇಳುತ್ತವೆ

ಪ್ರಿವ್ಯೂ ಎನ್ವಿರಾನ್‌ಮೆಂಟ್‌ಗಳು ಸಮಸ್ಯೆಯನ್ನು ಮತ್ತಷ್ಟು ಹೆಚ್ಚಿಸುತ್ತವೆ. ಅವು ಮಾನವ ವಿಮರ್ಶೆಗೆ ಉಪಯುಕ್ತವಾಗಿವೆ, ಆದರೆ ಅವು ಪ್ರೊಡಕ್ಷನ್ ಅಲ್ಲ. ಅವು ಹೆಚ್ಚಾಗಿ ನೈಜ API ಹೋಸ್ಟ್ ಬದಲಿಗೆ api-staging ಅನ್ನು ಬಳಸುತ್ತವೆ. ಫೀಚರ್ ಫ್ಲಾಗ್‌ಗಳು (Feature flags) ಪ್ರತಿಯೊಂದು ಪ್ರಯೋಗಕ್ಕೂ 'true' ಎಂದು ಪರಿಗಣಿಸಲ್ಪಡುತ್ತವೆ, ಇದು ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಕಂಡೀಷನಲ್ ಲಾಜಿಕ್ ಅನ್ನು ಮರೆಮಾಚುತ್ತದೆ. ಅಥೆಂಟಿಕೇಶನ್ (Authentication) ಒಂದು ಹಂತವನ್ನು ಬಿಡಬಹುದು ಅಥವಾ ಮಾಕ್ ಟೋಕನ್ ಅನ್ನು ಬಳಸಬಹುದು. ಕುಕೀಗಳು (Cookies) ಸಡಿಲವಾದ ನೀತಿಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಡೇಟಾಸೆಟ್ ಕೇವಲ ಹತ್ತು ಸಾಲುಗಳಾಗಿರಬಹುದು, ಹತ್ತು ಸಾವಿರದ ಬದಲಿಗೆ, ಇದರರ್ಥ ಪೇಜಿನೇಶನ್ (pagination), ಸರ್ಚ್ ರ್ಯಾಂಕಿಂಗ್ ಅಥವಾ ವರ್ಚುವಲೈಸೇಶನ್ ಲಾಜಿಕ್ ಎಂದಿಗೂ ಪರೀಕ್ಷಿಸಲ್ಪಡುವುದಿಲ್ಲ.

ನಿಮ್ಮ ಪರೀಕ್ಷೆಯು ಪ್ರಿವ್ಯೂ URL ನಲ್ಲಿ ಪಾಸಾಗಿ, ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಫೇಲ್ ಆದರೆ, ಅಥವಾ ಅದರ ವಿರುದ್ಧವಾದರೂ, ದೋಷವು ಪರೀಕ್ಷೆಯಲ್ಲಲ್ಲ, ಬದಲಿಗೆ ಎನ್ವಿರಾನ್‌ಮೆಂಟ್‌ನಲ್ಲಿದೆ.

ಊಹಿಸುವ ಮೊದಲು ಲಾಗ್ ಮಾಡಿ

ವಿಫಲತೆಯು ಮೊದಲ ಬಾರಿಗೆ ಕಾಣಿಸಿಕೊಂಡಾಗ, ಪರೀಕ್ಷೆಯನ್ನು ಬದಲಾಯಿಸಿ (tweak) ಯಶಸ್ವಿಯಾಗಬಹುದು ಎಂದು ಆಶಿಸುವ ಪ್ರವೃತ್ತಿಯನ್ನು ತಡೆಯಿರಿ. ಊಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಪಾಸಾದ ರನ್ ಅನ್ನು ಫೇಲ್ ಆದ ರನ್ ಜೊತೆಗೆ ಹೋಲಿಸಲು ನೀವು ಸಂದರ್ಭವನ್ನು (context) ಸ್ಥಿರಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ.

ಸ್ಪಷ್ಟವಾಗಿರುವ ಸಂಶಯಾಸ್ಪದ ಅಂಶಗಳನ್ನು ಲಾಗ್ ಮಾಡಿ. ವಿಫಲತೆಯ ಕ್ಷಣದಲ್ಲಿನ ಪೇಜ್ URL, ಬಿಲ್ಡ್ ID ಮತ್ತು commit SHA ಅನ್ನು ದಾಖಲಿಸಿ. ಸಕ್ರಿಯವಾಗಿರುವ ಫೀಚರ್ ಫ್ಲಾಗ್‌ಗಳನ್ನು ಗಮನಿಸಿ. API ಹೋಸ್ಟ್, ನಿಖರವಾದ ಬ್ರೌಸರ್ ಆವೃತ್ತಿ ಮತ್ತು ವ್ಯೂಪೋರ್ಟ್ ಗಾತ್ರವನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ. ಈ ವಿವರಗಳು ನಿಗೂಢ ವಿಫಲತೆಯನ್ನು ಪುನರಾವರ್ತಿಸಬಹುದಾದ ಸ್ಥಿತಿಯಾಗಿ (reproducible condition) ಬದಲಾಯಿಸುತ್ತವೆ.

ಕೇವಲ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಬೇಡಿ. ಎರಡು ಪೇಜ್‌ಗಳು ನೋಡಲು ಒಂದೇ ರೀತಿ ಕಾಣಬಹುದು, ಆದರೆ ಅವು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ JavaScript ಅನ್ನು ರನ್ ಮಾಡಬಹುದು. CI ಬಂಡಲ್‌ನಲ್ಲಿ ಹೆಚ್ಚುವರಿ polyfill ಸೇರ್ಪಡೆಯಾಗಿದೆ ಅಥವಾ ನಿಮ್ಮ ಬ್ರೌಸರ್ ಕ್ಯಾಶ್‌ನಲ್ಲಿ ಇರುವುದರಿಂದ ಲೋಕಲ್ ಬಂಡಲ್ ಒಂದು ಚಂಕ್ ಅನ್ನು ಬಿಟ್ಟುಹೋಗಿದೆ ಎಂಬ ವಿಷಯವನ್ನು ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ನಿಮಗೆ ತಿಳಿಸುವುದಿಲ್ಲ.

ಅಲ್ಲದೆ, DevTools ತೆರೆಯುವುದು ಸಮಯದ (timing) ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. DevTools ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್ ಅನ್ನು ವಿಳಂಬ ಮಾಡಬಹುದು, ನೆಟ್‌ವರ್ಕ್ ಆದ್ಯತೆಯನ್ನು ಬದಲಾಯಿಸಬಹುದು ಮತ್ತು ಕೆಲವು ರೆಂಡರಿಂಗ್ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು. ನೀವು DOM ಅನ್ನು ಪರಿಶೀಲಿಸುವಾಗ ಪಾಸಾಗುವ ಪರೀಕ್ಷೆಯು, ನೀವು ಪ್ಯಾನಲ್ ಅನ್ನು ಮುಚ್ಚಿ ಹೆಡ್‌ಲೆಸ್ (headless) ಆಗಿ ರನ್ ಮಾಡಿದ ತಕ್ಷಣ ಫೇಲ್ ಆಗಬಹುದು. ಡೆಬಗ್ಗರ್ (debugger) ಒಂದು ಉಪಯುಕ್ತ ಸಾಧನವಾಗಿದೆ, ಆದರೆ ಅದು ತಟಸ್ಥ ವೀಕ್ಷಕನಲ್ಲ.

ಅಪರಾಧದ ಸ್ಥಳವನ್ನು ಮರುಸೃಷ್ಟಿಸಿ

ನೀವು ವಿಫಲತೆಯನ್ನು ನಿಖರವಾಗಿ ಪುನರಾವರ್ತಿಸಲು ಬಯಸಿದರೆ, ಕೇವಲ ನಿಮ್ಮ ಸ್ಥಳೀಯ ಡೆವಲಪ್‌ಮೆಂಟ್ ಸರ್ವರ್ ಅನ್ನು ರನ್ ಮಾಡಿ ಯಶಸ್ಸನ್ನು ನಿರೀಕ್ಷಿಸುವಂತಿಲ್ಲ. ನೀವು CI ನ ನಿಖರವಾದ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸಬೇಕಾಗುತ್ತದೆ.

CI ಉತ್ಪಾದಿಸಿದ ನಿಖರವಾದ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಬೇಕಿದ್ದರೆ ಅದನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ. Vite ಅಥವಾ Webpack ડેವ್ ಮಿಡ್ಲ್‌ವೇರ್ ಬಳಸದೆ, ಒಂದು ಸರಳವಾದ ಸ್ಟ್ಯಾಟಿಕ್ ಫೈಲ್ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಆ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಅನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಸರ್ವ್ ಮಾಡಿ. CI ಇಂಜೆಕ್ಟ್ ಮಾಡಿದ ಅದೇ ಎನ್ವಿರಾನ್ಮೆಂಟ್ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಬಳಸಿ. ಬ್ರೌಸರ್ ವರ್ಷನ್ ಅನ್ನು ನಿಖರವಾಗಿ ಹೊಂದಿಸಿ. ಅದನ್ನು ಅದೇ ಮೋಡ್‌ನಲ್ಲಿ, headed ಅಥವಾ headless ಆಗಿ ರನ್ ಮಾಡಿ, ಏಕೆಂದರೆ ಫೋಕಸ್ ಇವೆಂಟ್‌ಗಳು, ಮೀಡಿಯಾ ಕ್ವೇರಿಗಳು ಮತ್ತು ಆಟೋಪ್ಲೇ ನೀತಿಗಳು ಇವೆರಡರ ನಡುವೆ ಸೂಕ್ಷ್ಮವಾಗಿ ವ್ಯತ್ಯಾಸವಿರುತ್ತವೆ. ನಿಮ್ಮ CI ಡಾಕರ್ ಕಂಟೇನರ್ ಬಳಸುತ್ತಿದ್ದರೆ, ಅದೇ ಇಮೇಜ್ ಅನ್ನು ಸ್ಥಳೀಯವಾಗಿ ರನ್ ಮಾಡಿ. ನಿಮ್ಮ ವೈಯಕ್ತಿಕ ಬ್ರೌಸರ್ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕಿ.

ಸ್ಥಳೀಯ ಪುನರಾವರ್ತನೆ (reproduction) ಅಂತಿಮವಾಗಿ ವಿಫಲವಾದಾಗ, ನಿಮ್ಮ ಬಳಿ ನಿಜವಾದ ಡಿಬಗ್ಗಿಂಗ್ ಸೆಷನ್ ಇರುತ್ತದೆ. ಅಲ್ಲಿಯವರೆಗೆ, ನೀವು ಕೇವಲ ನೆರಳುಗಳ ಬೆನ್ನಟ್ಟುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ.

ಮಲಗುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಕಾಯುವುದನ್ನು ಪ್ರಾರಂಭಿಸಿ

ಫ್ಲೇಕಿ (flaky) ಬ್ರೌಸರ್ ಟೆಸ್ಟ್‌ಗೆ ನೀಡುವ ಸಾಮಾನ್ಯ ಪ್ರತಿಕ್ರಿಯೆ ಎಂದರೆ ವಿಳಂಬವನ್ನು (delay) ಸೇರಿಸುವುದು. ಐದು ಸೆಕೆಂಡ್ ಕಾಯಿರಿ. ಹತ್ತು ಸೆಕೆಂಡ್ ಕಾಯಿರಿ. ಇದು ಪರಿಹಾರವಲ್ಲ. ಇದು ಶರಣಾಗುವಿಕೆಯಾಗಿದೆ. ಅನಗತ್ಯ ವಿಳಂಬಗಳು ನಿಮ್ಮ ಟೆಸ್ಟ್ ಸೂಟ್ ಅನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತವೆ, ಸುಳ್ಳು ಆತ್ಮವಿಶ್ವಾಸವನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಏರುಪೇರಾದಾಗ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ.

ಬದಲಾಗಿ, ಸ್ಥಿತಿಯ (state) ಪುರಾವೆಗಾಗಿ ಕಾಯಿರಿ. ಫಾರ್ಮ್ ಸಬ್ಮಿಷನ್ ನಂತರ ನೋಟಿಫಿಕೇಶನ್ ಕಾಣಿಸಿಕೊಳ್ಳಬೇಕಾದರೆ, ಸಮಯ ಕಳೆಯುವವರೆಗೆ ಕಾಯಬೇಡಿ. DOM ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ನೋಟಿಫಿಕೇಶನ್ ID ಇರುವುದಕ್ಕಾಗಿ ಕಾಯಿರಿ. ಕೌಂಟರ್ ಹೆಚ್ಚಾಗಬೇಕಾದರೆ, ಪಠ್ಯವು ಮೌಲ್ಯಗಳನ್ನು ಬದಲಾಯಿಸುವವರೆಗೆ ಕಾಯಿರಿ. ಲೋಡಿಂಗ್ ಸ್ಟೇಟ್ ಇಂಟರಾಕ್ಷನ್ ಅನ್ನು ತಡೆಯುತ್ತಿದ್ದರೆ, ಲೋಡಿಂಗ್ ಮಾರ್ಕರ್ ಮಾಯವಾಗುವವರೆಗೆ ಕಾಯಿರಿ. ನೀವು WebSocket ಅಥವಾ server-sent events ಬಳಸುತ್ತಿದ್ದರೆ, ನೆಟ್‌ವರ್ಕ್ ಸ್ಟ್ರೀಮ್ ನಿರ್ದಿಷ್ಟ ಇವೆಂಟ್ ಅನ್ನು ಉತ್ಪಾದಿಸುವವರೆಗೆ ಕಾಯಿರಿ.

ಎಕ್ಸ್‌ಪ್ಲಿಸಿಟ್ ವೇಟ್ಸ್ (Explicit waits) ನಿಮ್ಮ ಟೆಸ್ಟ್ ಅನ್ನು ಕೇವಲ ಊಹೆಯ ಆಟದಿಂದ ಒಂದು ಒಪ್ಪಂದವನ್ನಾಗಿ ಬದಲಾಯಿಸುತ್ತವೆ. ಟೆಸ್ಟ್ ಹೀಗೆ ಹೇಳುತ್ತದೆ: "ಅಪ್ಲಿಕೇಶನ್ ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಂಡ ನಂತರ ನಾನು ಮುಂದುವರಿಯುತ್ತೇನೆ." ಇದು "ಸಾಕಷ್ಟು ಸೆಕೆಂಡುಗಳು ಕಳೆದ ನಂತರ ನಾನು ಮುಂದುವರಿಯುತ್ತೇನೆ" ಎಂದು ಹೇಳುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಲಶಾಲಿಯಾಗಿದೆ.

ಹೈಡ್ರೇಶನ್ ಮತ್ತು ಮಾಯವಾಗುವ ಬಟನ್

ಆಧುನಿಕ React ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ, ಹೈಡ್ರೇಶನ್ (hydration) ಒಂದು ನಿರ್ದಿಷ್ಟ ರೀತಿಯ ವೈಫಲ್ಯಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಇದನ್ನು ಸ್ಥಳೀಯ ಡೆವ್ ಸರ್ವರ್‌ಗಳು ಹೆಚ್ಚಾಗಿ ಮರೆಮಾಚುತ್ತವೆ. ಸರ್ವರ್ HTML ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಬ್ರೌಸರ್‌ನಲ್ಲಿ React ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಇವೆಂಟ್ ಲಿಸನರ್‌ಗಳನ್ನು ಲಗತ್ತಿಸುತ್ತದೆ. ಆ ಸಮಯದಲ್ಲಿ, ನಿಮ್ಮ ಟೆಸ್ಟ್ ಒಂದು ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಬಹುದು. ನಂತರ ಹೈಡ್ರೇಶನ್ ಸಮಯದಲ್ಲಿ React ಆ DOM ನೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಅಥವಾ ಮರುರಚಿಸುತ್ತದೆ. ನಿಮ್ಮ ಟೆಸ್ಟ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ಹಿಡಿದಿದ್ದ ಎಲಿಮೆಂಟ್ ಹ್ಯಾಂಡಲ್ ಈಗ ಡಿಟ್ಯಾಚ್ಡ್ (detached) ನೋಡ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು ನೀವು ತೆಗೆದುಹಾಕಲಾದ ಎಲಿಮೆಂಟ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ಬಗ್ಗೆ ದೋಷವನ್ನು ಪಡೆಯುತ್ತೀರಿ.

ಪರಿಹಾರವೆಂದರೆ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀನಲ್ಲಿ ಆಳವಾಗಿ ಹುಡುಕುವ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಸೆಲೆಕ್ಟರ್ ಅನ್ನು ಬರೆಯುವುದಲ್ಲ. ಪರಿಹಾರವೆಂದರೆ ಸಿದ್ಧತೆಯ ಸಂಕೇತಗಳನ್ನು (readiness signals) ಹುಡುಕುವುದು. ರೂಟ್ ಎಲಿಮೆಂಟ್ ಹೈಡ್ರೇಟೆಡ್ ಅಟ್ರಿಬ್ಯೂಟ್ ಅಥವಾ ತಿಳಿದಿರುವ ಡೇಟಾ ಪ್ರಾಪರ್ಟಿಯನ್ನು ಪಡೆಯುವವರೆಗೆ ಕಾಯಿರಿ. ಸ್ಕೆಲೆಟನ್ ಲೋಡರ್ ಮಾಯವಾಗುವವರೆಗೆ ಕಾಯಿರಿ. ಕ್ಲೈಂಟ್-ಸೈಡ್ ಇವೆಂಟ್ ಹ್ಯಾಂಡ್ಲರ್ ಸಕ್ರಿಯವಾಗುವವರೆಗೆ ಕಾಯಿರಿ. ನೀವು ಕ್ಲಿಕ್‌ಗಳನ್ನು ಮಾಡುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ ಅದು ಸ್ಥಿರವಾಗಿದೆ ಎಂದು ಘೋಷಿಸಲು ಬಿಡಿ.

ಗುಪ್ತ ಅಪರಾಧಿಗಳು: ಡಿಪೆಂಡೆನ್ಸಿಗಳು ಮತ್ತು ಥರ್ಡ್-ಪಾರ್ಟಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು

ಕೆಲವೊಮ್ಮೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಬದಲಾಗದಿದ್ದರೂ ಪರಿಸರವು ಬದಲಾಗಬಹುದು. ನಿಮ್ಮ node_modules ನಲ್ಲಿ ಮೂರು ಹಂತಗಳ ಆಳದಲ್ಲಿರುವ ಸಣ್ಣ ಯುಟಿಲಿಟಿ ಲೈಬ್ರರಿಯ ಟ್ರಾನ್ಸಿಟಿವ್ ಅಪ್‌ಡೇಟ್, ಬ್ರೌಸರ್ ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸಬಹುದು. ಇದು ಪ್ರಾಮಿಸಸ್ ಹೇಗೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ, ಸ್ಟೈಲ್‌ಗಳು ಹೇಗೆ ಇಂಜೆಕ್ಟ್ ಆಗುತ್ತವೆ ಅಥವಾ ಮಾಕ್‌ಗಳು ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ಅಡ್ಡಿಪಡಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸಬಹುದು. ದಿನನಿತ್ಯದ ಡಿಪೆಂಡೆನ್ಸಿ ಅಪ್‌ಡೇಟ್ ನಂತರ ಟೆಸ್ಟ್‌ಗಳು ವಿಫಲವಾಗಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನಿಮ್ಮ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ವರ್ಷ ಮತ್ತು ಲಾಕ್‌ಫೈಲ್ ಚೆಕ್‌ಸಮ್ ಅನ್ನು ದಾಖಲಿಸಿ. ನೀವು ಕಳೆದ ವಾರ ನೋಡಿದ ಅದೇ ಟ್ರೀ ಅನ್ನು ನೋಡುತ್ತಿದ್ದೀರಾ ಅಥವಾ ಇಲ್ಲ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿದಿರಬೇಕು.

ಥರ್ಡ್-ಪಾರ್ಟಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಮತ್ತೊಂದು ಸಾಮಾನ್ಯ ಅಡ್ಡಿಪಡಿಸುವ ಅಂಶಗಳು. ಅನಾಲಿಟಿಕ್ಸ್ ಟ್ರ್ಯಾಕರ್‌ಗಳು, ಪೇಮೆಂಟ್ SDKಗಳು ಮತ್ತು ಚಾಟ್ ವಿಜೆಟ್‌ಗಳು ಅಸಿಂಕ್ರೋನಸ್ ಆಗಿ ಲೋಡ್ ಆಗುತ್ತವೆ. ಅವು ಇಫ್ರೇಮ್‌ಗಳನ್ನು ಇಂಜೆಕ್ಟ್ ಮಾಡುತ್ತವೆ, ಲೇಔಟ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ ಅಥವಾ ನಿಮ್ಮ ಟೆಸ್ಟ್ ನಿರೀಕ್ಷಿಸದ ಕ್ಷಣಗಳಲ್ಲಿ ಫೋಕಸ್ ಅನ್ನು ಕದಿಯುತ್ತವೆ. CI ಯಲ್ಲಿ, ಈ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ನಿಧಾನವಾಗಿ ಲೋಡ್ ಆಗಬಹುದು ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ನಿರ್ಬಂಧಗಳಿಂದಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಲೋಡ್ ಆಗಲು ವಿಫಲವಾಗಬಹುದು, ಇದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ವಿಭಿನ್ನ ಎರರ್-ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಹಾದಿಯನ್ನು ಅನುಸರಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ಯಾವ ಥರ್ಡ್-ಪಾರ್ಟಿ ಸಂಪನ್ಮೂಲಗಳು ಲೋಡ್ ಆದವು ಮತ್ತು ಅವುಗಳ HTTP ಸ್ಟೇಟಸ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಿ. ಪೇಮೆಂಟ್ ಇಫ್ರೇಮ್ CI ಯಲ್ಲಿ ಮೌಂಟ್ ಆಗಲು ಮೂರು ಸೆಕೆಂಡ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಆದರೆ ನಿಮ್ಮ ವೇಗದ ಸ್ಥಳೀಯ ಸಂಪರ್ಕದಲ್ಲಿ ತಕ್ಷಣವೇ ಲೋಡ್ ಆಗುತ್ತದೆ ಎಂದಾದರೆ, ನಿಮ್ಮ "element not clickable" ದೋಷಕ್ಕೆ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಸ್ಪಷ್ಟ ಕಾರಣ ಸಿಗುತ್ತದೆ.

ಮತ್ತು "element not clickable" ಎಂಬುದು ಎಂದಿಗೂ ರೋಗನಿರ್ಣಯವಲ್ಲ. ಅದು ಕೇವಲ ಒಂದು ಲಕ್ಷಣ. ಮೂಲ ಕಾರಣವನ್ನು ಸರಿಪಡಿಸಿ.

ಎವಿಡೆನ್ಸ್ ಕಿಟ್ ನಿರ್ಮಿಸಿ

ಪ್ರತಿ CI ವೈಫಲ್ಯವು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದಂತಿರಬೇಕು (actionable). ಕೇವಲ ಸ್ಟ್ಯಾಕ್ ಟ್ರೇಸ್ ಸಾಕಾಗುವುದಿಲ್ಲ. ಇನ್ನೊಬ್ಬ ಎಂಜಿನಿಯರ್ ಅಥವಾ ಮುಂದಿನ ತಿಂಗಳು ನೀವೇ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಮರುನಿರ್ಮಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುವ ಎವಿಡೆನ್ಸ್ ಕಿಟ್ ನಿಮಗೆ ಬೇಕು.

ವಿಫಲವಾದ ರನ್‌ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳು ಮತ್ತು ವಿಡಿಯೋ ರೆಕಾರ್ಡಿಂಗ್‌ಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. ಬ್ರೌಸರ್ ಕನ್ಸೋಲ್ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಪೂರ್ಣವಾಗಿ ಕ್ಯಾಪ್ಚರ್ ಮಾಡಿ, ಕೇವಲ ದೋಷಗಳಲ್ಲದೆ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಕೂಡ ತೆಗೆದುಕೊಳ್ಳಿ. 404ಗಳು, CORS ತಿರಸ್ಕಾರಗಳು ಮತ್ತು ಡ್ರಾಪ್ಡ್ ಕನೆಕ್ಷನ್‌ಗಳು ಸೇರಿದಂತೆ ನೆಟ್‌ವರ್ಕ್ ವೈಫಲ್ಯಗಳನ್ನು ಲಾಗ್ ಮಾಡಿ. ಸಕ್ರಿಯವಾಗಿದ್ದ ಬಿಲ್ಡ್ ಐಡಿಗಳು ಮತ್ತು ಫೀಚರ್ ಫ್ಲಾಗ್‌ಗಳನ್ನು ಸಂರಕ್ಷಿಸಿ. ಅಸರ್‌ಷನ್ ವಿಫಲವಾದ ನಿಖರ ಕ್ಷಣದಲ್ಲಿ DOM ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ತೆಗೆದುಕೊಳ್ಳಿ. ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ನಿಮಗೆ ಘಟನೆ ನಡೆದ ನಂತರ HTML ರಚನೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಬದಲಾಗಿ