CI ಇಮೇಲ್ ಪರೀಕ್ಷೆಗಳಿಗೆ ವೈಫಲ್ಯದ ಲೆಡ್ಜರ್ ಅಗತ್ಯವಿದೆ

ಇಮೇಲ್ ಪರಿಶೀಲನಾ ಪರೀಕ್ಷೆಗಳು ಕಂಟಿನ್ಯೂಯಸ್ ಇಂಟಿಗ್ರೇಷನ್ (CI) ಪೈಪ್‌ಲೈನ್‌ಗಳ ಸಾಮಾನ್ಯ ಭಾಗವಾಗಿವೆ. ಈ ಪರೀಕ್ಷೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸರಳವಾದ ಹಸಿರು ಅಥವಾ ಕೆಂಪು ಪರಿಶೀಲನೆಯೊಂದಿಗೆ ಮುಕ್ತಾಯಗೊಳ್ಳುತ್ತವೆ. ಇದು ಸಹಾಯಕವಾಗಿದ್ದರೂ, ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಏನಾಯಿತು ಎಂಬುದರ ಕುರಿತು ಸಾಕಷ್ಟು ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ. ದೃಢವಾದ CI ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಈ ವೈಫಲ್ಯಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ.

ಕೇವಲ ಪಾಸ್ ಅಥವಾ ಫೇಲ್ ಫಲಿತಾಂಶ ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ

ಇಮೇಲ್ ಪರೀಕ್ಷೆಗಳು ಹಲವಾರು ಕಾರಣಗಳಿಗಾಗಿ ವಿಫಲವಾಗಬಹುದು:

• ಅಪ್ಲಿಕೇಶನ್ ಸಂದೇಶವನ್ನು ಎಂದಿಗೂ ಕಳುಹಿಸಲಿಲ್ಲ.
• ಪರೀಕ್ಷೆಯ ಗಡುವು ಮುಗಿದ ನಂತರ ಸಂದೇಶವು ತಲುಪಿತು.
• ಪರೀಕ್ಷೆಯು ಬೇರೊಂದು ರನ್‌ನಿಂದ ಬಂದ ಸಂದೇಶವನ್ನು ಓದಿದೆ.
• ಇನ್‌ಬಾಕ್ಸ್ ಪ್ರೊವೈಡರ್ ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸಿದೆ.
• ಕ್ಲೀನಪ್ ಮಾಡುವ ಮೊದಲೇ ರನ್ನರ್ ರದ್ದುಗೊಂಡಿದೆ.

ಈ ಪ್ರತಿಯೊಂದು ವೈಫಲ್ಯಕ್ಕೂ ವಿಭಿನ್ನ ಪರಿಹಾರಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಒಂದೇ ಒಂದು ವಿಫಲವಾದ ಅಸರ್ಶನ್ (assertion) ಸಾಮಾನ್ಯವಾಗಿ ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಸಾಮಾನ್ಯ ಕೆಂಪು ಗುರುತಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಇದು ಗೊಂದಲಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು ಮತ್ತು ಡೀಬಗ್ ಮಾಡುವುದನ್ನು ಕಷ್ಟಕರವಾಗಿಸಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಮರುಪ್ರಯತ್ನವನ್ನು ಬಳಸಿದರೆ, ಅದು ಮೂಲ ಸಮಸ್ಯೆಯನ್ನು ಮರೆಮಾಚಿ, ಅದನ್ನು ಫ್ಲೇಕಿ (flaky) ಪರೀಕ್ಷೆಯಂತೆ ಕಾಣುವಂತೆ ಮಾಡಬಹುದು.

ಇಮೇಲ್ ಫಿಕ್ಸ್‌ಚರ್ ಅನ್ನು ರನ್-ಮಾಲೀಕತ್ವದ ಸಂಪನ್ಮೂಲವಾಗಿ ರೂಪಿಸಿ

ಸ್ಪಷ್ಟತೆಯನ್ನು ಸುಧಾರಿಸಲು, ಪ್ರತಿ ಪರೀಕ್ಷಾ ಇನ್‌ಬಾಕ್ಸ್ ಅನ್ನು ಸಣ್ಣ, ಸ್ವಾಮ್ಯದ ಸಂಪನ್ಮೂಲವಾಗಿ ಪರಿಗಣಿಸುವುದು ಪ್ರಯೋಜನಕಾರಿಯಾಗಿದೆ. ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ಅನನ್ಯ ಗುರುತಿಸುವಿಕೆಗಳು ಮತ್ತು ಸಂಬಂಧಿತ ವಿವರಗಳೊಂದಿಗೆ ಫಿಕ್ಸ್‌ಚರ್ ದಾಖಲೆಯನ್ನು ರಚಿಸಿ. ಈ ದಾಖಲೆಯು ಹೇಗೆ ಕಾಣಿಸಬಹುದು ಎಂಬುದಕ್ಕೆ ಇಲ್ಲೊಂದು ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ:

{  
  "fixture_id": "ef_01J9ZQ4N8M",  
  "run_id": "build-1842-shard-2",  
  "purpose": "signup-verification",  
  "created_at": "2026-11-08T22:10:00Z",  
  "expires_at": "2026-11-08T22:25:00Z",  
  "expected_message": "verify-account",  
  "status": "active"  
}

ಈ ದಾಖಲೆಯು ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ಅಥವಾ ಟೋಕನ್‌ಗಳಂತಹ ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರಬಾರದು. ಬದಲಾಗಿ, ಇದು ಮಾಲೀಕತ್ವ ಮತ್ತು ಪರೀಕ್ಷೆಯ ನಿರೀಕ್ಷಿತ ಹರಿವಿನ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಬೇಕು.

ಸಣ್ಣ ವೈಫಲ್ಯದ ಲೆಡ್ಜರ್ ಬರೆಯಿರಿ

ವೈಫಲ್ಯದ ಲೆಡ್ಜರ್ ಎಂಬುದು ಈವೆಂಟ್‌ಗಳ ಸರಳ, ಕೇವಲ-ಸೇರ್ಪಡೆ (append-only) ಪಟ್ಟಿಯಾಗಿದ್ದು, ಬಿಲ್ಡ್ ಅನ್ನು ತಕ್ಷಣವೇ ಮರುಉತ್ಪಾದಿಸುವ ಅಗತ್ಯವಿಲ್ಲದೆ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಈ ಲೆಡ್ಜರ್‌ನ ಉದಾಹರಣೆ ಹೀಗಿರಬಹುದು:

{  
  "fixture_id": "ef_01J9ZQ4N8M",  
  "events": [  
    { "at": "22:10:03Z", "type": "allocated" },  
    { "at": "22:10:09Z", "type": "verification_requested" },  
    { "at": "22:10:39Z", "type": "wait_expired", "observed": 0 }  
  ],  
  "final_status": "failed",  
  "cleanup_status": "pending"  
}

ಈ ಲೆಡ್ಜರ್ ಈವೆಂಟ್ ಹೆಸರುಗಳನ್ನು ಚಿಕ್ಕದಾಗಿ ಮತ್ತು ಊಹಿಸಬಹುದಾದಂತೆ ಇರಿಸಬೇಕು. ಉದಾಹರಣೆಗೆ, wait_expired ದೀರ್ಘ ವಿವರಣೆಗಿಂತ ಹೆಚ್ಚು ಉಪಯುಕ್ತವಾಗಿದೆ. ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯು ಪೂರ್ಣಗೊಳ್ಳದಿದ್ದಾಗಲೂ ಇಮೇಲ್ ಫಿಕ್ಸ್‌ಚರ್‌ಗಳು ಕ್ಲೀನಪ್ ಗಡುವನ್ನು ಹೊಂದಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವಂತಹ ಸಾಮಾನ್ಯ ದೋಷಗಳನ್ನು ಗುರುತಿಸಲು ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಮತ್ತೊಂದು ಮರುಪ್ರಯತ್ನದ ಬದಲಿಗೆ ಪುರಾವೆಗಳನ್ನು ಬಳಸಿ

ತಾತ್ಕಾಲಿಕ ದೋಷಗಳಿಗೆ ಮರುಪ್ರಯತ್ನಗಳು ಸಹಾಯಕವಾಗಬಹುದು, ಆದರೆ ಖಾಲಿ ಇನ್‌ಬಾಕ್ಸ್‌ಗೆ ಅವು ಡೀಫಾಲ್ಟ್ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿರಬಾರದು. ಬದಲಾಗಿ, ಮರುಪ್ರಯತ್ನಿಸುವ ಮೊದಲು ಪುರಾವೆಗಳನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ. ಇದು ಒಳಗೊಂಡಿರುತ್ತದೆ:

• ಅಪ್ಲಿಕೇಶನ್ ಯಶಸ್ವಿ ಕಳುಹಿಸುವಿಕೆಯ ವಿನಂತಿಯನ್ನು ಲಾಗ್ ಮಾಡಿದೆಯೇ?
• ಪ್ರೊವೈಡರ್ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿ ID ಯನ್ನು ಹಿಂತಿರುಗಿಸಿದೆಯೇ?
• ಪರೀಕ್ಷೆಯು ಸರಿಯಾದ ಇನ್‌ಬಾಕ್ಸ್ ಅನ್ನು ಕ್ವೆರಿ ಮಾಡುತ್ತಿದೆಯೇ?
• ಸಂದೇಶದ ಗಡುವು ಮುಗಿದಿದೆಯೇ?
• ರನ್ನರ್ ರದ್ದತಿಯನ್ನು ವರದಿ ಮಾಡಿದೆಯೇ?

ಕೇವಲ ಕುರುಡಾಗಿ ಮರುಪ್ರಯತ್ನಿಸುವ ಬದಲು ವೈಫಲ್ಯದ ಕಾರಣದ ಬಗ್ಗೆ ಸ್ಪಷ್ಟ ತಿಳುವಳಿಕೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಈ ವಿಧಾನವು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕ ಆಟೊಮೇಷನ್ ಲೂಪ್

ಉತ್ತಮವಾಗಿ ರಚನಾತ್ಮಕವಾದ ವರ್ಕ್‌ಫ್ಲೋ ಸ್ಪಷ್ಟತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ:

1. ಫಿಕ್ಸ್‌ಚರ್ ಅನ್ನು ನಿಯೋಜಿಸಿ.
2. ನಿಯೋಜಿಸಲಾದ ಈವೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ.
3. ಪರಿಶೀಲನಾ ಹರಿವನ್ನು ಚಲಾಯಿಸಿ.
4. ಕಳುಹಿಸುವಿಕೆ ಮತ್ತು ಓದುವಿಕೆ ಈವೆಂಟ್‌ಗಳನ್ನು ಸೇರಿಸಿ.
5. ಪಾಸ್ ಅಥವಾ ವೈಫಲ್ಯವನ್ನು ವರ್ಗೀಕರಿಸಿ.
6. ಕ್ಲೀನಪ್ ಗಡುವನ್ನು ನಿಗದಿಪಡಿಸಿ.
7. ಸಾರಾಂಶ ಮತ್ತು ಅಪಾರದರ್ಶಕ ಪುರಾವೆ ID ಗಳನ್ನು ಪ್ರಕಟಿಸಿ.

ಕ್ಲೀನಪ್ ಗಡುವು ಪರೀಕ್ಷಾ ಟೈಮ್‌ಔಟ್‌ನಿಂದ ಸ್ವತಂತ್ರವಾಗಿರಬೇಕು. ಇದರರ್ಥ ಪರೀಕ್ಷೆಯು ನಿರ್ದಿಷ್ಟ ಸಮಯದ ನಂತರ ನಿಲ್ಲಬಹುದು, ಆದರೆ ಫಿಕ್ಸ್‌ಚರ್ ದೀರ್ಘಾವಧಿಯ ರೋಗನಿರ್ಣಯದ ಅವಧಿಗೆ ಲಭ್ಯವಿರುತ್ತದೆ. ಈ ಅವಧಿಯ ನಂತರ, ಅದನ್ನು ಅಳಿಸಬಹುದು ಅಥವಾ ಹಸ್ತಚಾಲಿತ ಪರಿಶೀಲನೆಗಾಗಿ ಗುರುತಿಸಬಹುದು.

CI ಇಮೇಲ್ ಪರೀಕ್ಷೆಗಳ ಪರಿಶೀಲನಾಪಟ್ಟಿ

• ಪ್ರತಿಯೊಂದು ಫಿಕ್ಸ್‌ಚರ್ ರನ್ ID, ಶಾರ್ಡ್, ಮಾಲೀಕರು ಮತ್ತು ಮುಕ್ತಾಯ ದಿನಾಂಕವನ್ನು ಹೊಂದಿದೆಯೇ?
• ನಿರೀಕ್ಷಿತ ಸ್ವೀಕೃತದಾರರು ಪ್ರೊವೈಡರ್ ವಿಳಾಸದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿದ್ದಾರೆಯೇ?
• ಕಳುಹಿಸುವಿಕೆ, ಸ್ವೀಕರಿಸುವಿಕೆ, ಟೈಮ್‌ಔಟ್ ಮತ್ತು ಕ್ಲೀನಪ್ ಈವೆಂಟ್‌ಗಳನ್ನು ದಾಖಲಿಸಲಾಗಿದೆಯೇ?
• ಪ್ರೊವೈಡರ್ ದೋಷಗಳಿಗಾಗಿ ಬೌಂಡೆಡ್ ಮರುಪ್ರಯತ್ನ ನೀತಿ ಇದೆಯೇ?
• ರನ್ನರ್ ರದ್ದುಗೊಂಡ ನಂತರ ನಂತರದ ವರ್ಕರ್ ಕ್ಲೀನಪ್ ಮಾಡಬಹುದೇ?
• ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಲಾಗ್‌ಗಳಿಂದ ಹೊರಗಿಡಲಾಗಿದೆಯೇ?
• ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸದೆಯೇ ಡೆವಲಪರ್‌ಗಳು ಪುರಾವೆಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದೇ?
• ಹಳೆಯ ಫಿಕ್ಸ್‌ಚರ್‌ಗಳು ವಯಸ್ಸು ಮತ್ತು ಅಂತಿಮ ಸ್ಥಿತಿಯ ಪ್ರಕಾರ ಗೋಚರಿಸುತ್ತವೆಯೇ?

ತೀರ್ಮಾನ

CI ಇಮೇಲ್ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ವೈಫಲ್ಯದ ಲೆಡ್ಜರ್ ಅನ್ನು ಅಳವಡಿಸುವುದು ಡೀಬಗ್ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚಿಸುತ್ತದೆ. ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಏನಾಯಿತು ಎಂಬುದರ ವಿವರವಾದ ವಿವರಣೆಯನ್ನು ಒದಗಿಸುವ ಮೂಲಕ, ಡೆವಲಪರ್‌ಗಳು ಸಮಸ್ಯೆಗಳನ್ನು ಹೆಚ್ಚು ಸುಲಭವಾಗಿ ಗುರುತಿಸಬಹುದು ಮತ್ತು ಸರಿಪಡಿಸಬಹುದು.

ಪ್ರಯೋಜನಗಳು

• ಪ್ರತಿ ಪರೀಕ್ಷಾ ರನ್‌ನ ಸ್ಪಷ್ಟ ದಾಖಲೆಯನ್ನು ನೀಡುತ್ತದೆ.
• ವಿವಿಧ ರೀತಿಯ ವೈಫಲ್ಯಗಳ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಗುರುತಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
• ತಂಡದ ಸದಸ್ಯರ ನಡುವೆ ಉತ್ತಮ ಸಂವಹನಕ್ಕೆ ಅನುಕೂಲ ಮಾಡಿಕೊಡುತ್ತದೆ.

ಅನಾನುಕೂಲಗಳು

• ಹೆಚ್ಚುವರಿ ಸೆಟಪ್ ಮತ್ತು ನಿರ್ವಹಣೆಯ ಅಗತ್ಯವಿರಬಹುದು.
• ಸರಳ ಪರೀಕ್ಷೆಗಳಿಗೆ ಇದು ಮಿತಿಮೀರಿದ ಪ್ರಯತ್ನವೆಂದು ಪರಿಗಣಿಸಬಹುದು.

ಎಚ್ಚರಿಕೆ

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

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• ವೈಫಲ್ಯದ ಲೆಡ್ಜರ್ ಎಂದರೇನು? — ವೈಫಲ್ಯದ ಲೆಡ್ಜರ್ ಎಂಬುದು ಪರೀಕ್ಷಾ ರನ್ ಸಮಯದಲ್ಲಿ ನಡೆಯುವ ಈವೆಂಟ್‌ಗಳ ವಿವರವಾದ ದಾಖಲೆಯಾಗಿದ್ದು, ಬಿಲ್ಡ್ ಅನ್ನು ಮರುಉತ್ಪಾದಿಸುವ ಅಗತ್ಯವಿಲ್ಲದೆ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
• ಸರಳ ಪಾಸ್ ಅಥವಾ ಫೇಲ್ ಫಲಿತಾಂಶಗಳು ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ? — ಅವು ವೈಫಲ್ಯದ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಸಂದರ್ಭವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ, ಇದು ಡೀಬಗ್ ಮಾಡುವುದನ್ನು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ.
• ಇಮೇಲ್ ಫಿಕ್ಸ್‌ಚರ್ ಅನ್ನು ನಾನು ಹೇಗೆ ರೂಪಿಸಬಹುದು? — ಅನನ್ಯ ಗುರುತಿಸುವಿಕೆಗಳು ಮತ್ತು ಸಂಬಂಧಿತ ವಿವರಗಳೊಂದಿಗೆ ಅದನ್ನು ರನ್-ಮಾಲೀಕತ್ವದ ಸಂಪನ್ಮೂಲವಾಗಿ ಪರಿಗಣಿಸಿ.
• ವೈಫಲ್ಯದ ಲೆಡ್ಜರ್‌ನಲ್ಲಿ ಏನನ್ನು ಸೇರಿಸಬೇಕು? — ಇದು ಈವೆಂಟ್ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳು, ಪ್ರಕಾರಗಳು ಮತ್ತು ಪರೀಕ್ಷೆಯ ಅಂತಿಮ ಸ್ಥಿತಿಯನ್ನು ಒಳಗೊಂಡಿರಬೇಕು.
• ನಿಖರವಾದ ಪುರಾವೆ ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು ನಾನು ಹೇಗೆ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು? — ಪರೀಕ್ಷೆಯನ್ನು ಮರುಪ್ರಯತ್ನಿಸುವ ಮೊದಲು ಪ್ರಮುಖ ಈವೆಂಟ್‌ಗಳು ಮತ್ತು ಷರತ್ತುಗಳನ್ನು ದಾಖಲಿಸಿ.
• ರಚನಾತ್ಮಕ ವರ್ಕ್‌ಫ್ಲೋನ ಪ್ರಯೋಜನವೇನು? — ಇದು ಸಂಪೂರ್ಣ ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯ ಉದ್ದಕ್ಕೂ ಸ್ಪಷ್ಟತೆ ಮತ್ತು ಸಂಘಟನೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಟ್ಯಾಗ್‌ಗಳು

#automation #devtools #testing #cicd #emailtests #failures #devops #debugging #CI