ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ಟೆಸ್ಟ್-ಡ್ರಿವನ್ ಡೆವಲಪ್‌ಮೆಂಟ್: ಜಾಗತಿಕ ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ಒಂದು ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿ

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

TDD ಕೇವಲ ಒಂದು ಪರೀಕ್ಷಾ ತಂತ್ರವಲ್ಲ; ಇದು ಸಾಫ್ಟ್‌ವೇರ್ ವಿನ್ಯಾಸ ಮತ್ತು ಅಭಿವೃದ್ಧಿಗೆ ಒಂದು ಶಿಸ್ತುಬದ್ಧ ವಿಧಾನವಾಗಿದೆ. ಇದು ಸಾಂಪ್ರದಾಯಿಕ "ಕೋಡ್ ಬರೆಯಿರಿ, ನಂತರ ಪರೀಕ್ಷಿಸಿ" ಮಾದರಿಯನ್ನು ತಿರುಗಿಸುತ್ತದೆ. TDD ಯೊಂದಿಗೆ, ನೀವು ಪ್ರೊಡಕ್ಷನ್ ಕೋಡ್ ಬರೆಯುವ ಮೊದಲು ವಿಫಲವಾಗುವ ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯುತ್ತೀರಿ. ಈ ಸರಳವಾದ ತಿರುವು ಕೋಡ್‌ನ ಗುಣಮಟ್ಟ, ವಿನ್ಯಾಸ ಮತ್ತು ನಿರ್ವಹಣೆಯ ಮೇಲೆ ಆಳವಾದ ಪರಿಣಾಮಗಳನ್ನು ಬೀರುತ್ತದೆ. ಈ ಮಾರ್ಗದರ್ಶಿಯು ವೃತ್ತಿಪರ ಡೆವಲಪರ್‌ಗಳ ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ, ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ TDD ಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಗ್ರ, ಪ್ರಾಯೋಗಿಕ ನೋಟವನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಟೆಸ್ಟ್-ಡ್ರಿವನ್ ಡೆವಲಪ್‌ಮೆಂಟ್ (TDD) ಎಂದರೇನು?

ಮೂಲಭೂತವಾಗಿ, ಟೆಸ್ಟ್-ಡ್ರಿವನ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಎನ್ನುವುದು ಅತ್ಯಂತ ಚಿಕ್ಕ ಅಭಿವೃದ್ಧಿ ಚಕ್ರದ ಪುನರಾವರ್ತನೆಯನ್ನು ಅವಲಂಬಿಸಿರುವ ಒಂದು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬರೆದು ನಂತರ ಅವುಗಳನ್ನು ಪರೀಕ್ಷಿಸುವ ಬದಲು, TDD ಮೊದಲು ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯಬೇಕೆಂದು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಈ ಪರೀಕ್ಷೆಯು ಅನಿವಾರ್ಯವಾಗಿ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ ಏಕೆಂದರೆ ವೈಶಿಷ್ಟ್ಯವು ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಆಗ ಡೆವಲಪರ್‌ನ ಕೆಲಸವೆಂದರೆ ಆ ನಿರ್ದಿಷ್ಟ ಪರೀಕ್ಷೆಯನ್ನು ಪಾಸ್ ಮಾಡಲು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾದ ಕೋಡ್ ಅನ್ನು ಬರೆಯುವುದು. ಒಮ್ಮೆ ಅದು ಪಾಸ್ ಆದ ನಂತರ, ಕೋಡ್ ಅನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಿ ಸುಧಾರಿಸಲಾಗುತ್ತದೆ. ಈ ಮೂಲಭೂತ ಲೂಪ್ ಅನ್ನು "ರೆಡ್-ಗ್ರೀನ್-ರಿಫ್ಯಾಕ್ಟರ್" ಚಕ್ರ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

TDD ಯ ಲಯ: ರೆಡ್-ಗ್ರೀನ್-ರಿಫ್ಯಾಕ್ಟರ್

ಈ ಮೂರು-ಹಂತದ ಚಕ್ರವು TDD ಯ ಹೃದಯ ಬಡಿತವಾಗಿದೆ. ಈ ಲಯವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮತ್ತು ಅಭ್ಯಾಸ ಮಾಡುವುದು ಈ ತಂತ್ರವನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳಲು ಮೂಲಭೂತವಾಗಿದೆ.

• 🔴 ರೆಡ್ — ವಿಫಲವಾಗುವ ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯಿರಿ: ನೀವು ಹೊಸ ಕಾರ್ಯಚಟುವಟಿಕೆಗಾಗಿ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯುವುದರೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ. ಈ ಪರೀಕ್ಷೆಯು ನೀವು ಕೋಡ್ ಏನು ಮಾಡಬೇಕು ಎಂದು ಬಯಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬೇಕು. ನೀವು ಇನ್ನೂ ಯಾವುದೇ ಅನುಷ್ಠಾನ ಕೋಡ್ ಬರೆಯದ ಕಾರಣ, ಈ ಪರೀಕ್ಷೆಯು ವಿಫಲಗೊಳ್ಳುವುದು ಖಚಿತ. ವಿಫಲವಾದ ಪರೀಕ್ಷೆಯು ಸಮಸ್ಯೆಯಲ್ಲ; ಅದು ಪ್ರಗತಿ. ಇದು ಪರೀಕ್ಷೆಯು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ (ಅದು ವಿಫಲವಾಗಬಹುದು) ಮತ್ತು ಮುಂದಿನ ಹಂತಕ್ಕೆ ಸ್ಪಷ್ಟ, ನಿಖರವಾದ ಗುರಿಯನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ.
• 🟢 ಗ್ರೀನ್ — ಪಾಸ್ ಮಾಡಲು ಸರಳವಾದ ಕೋಡ್ ಬರೆಯಿರಿ: ನಿಮ್ಮ ಗುರಿ ಈಗ ಏಕೈಕವಾಗಿದೆ: ಪರೀಕ್ಷೆಯನ್ನು ಪಾಸ್ ಮಾಡುವುದು. ಪರೀಕ್ಷೆಯನ್ನು ರೆಡ್‌ನಿಂದ ಗ್ರೀನ್‌ಗೆ ತಿರುಗಿಸಲು ಅಗತ್ಯವಿರುವ ಕನಿಷ್ಠ ಪ್ರಮಾಣದ ಪ್ರೊಡಕ್ಷನ್ ಕೋಡ್ ಅನ್ನು ನೀವು ಬರೆಯಬೇಕು. ಇದು ವಿರೋಧಾಭಾಸವೆಂದು ಅನಿಸಬಹುದು; ಕೋಡ್ ಸೊಗಸಾಗಿ ಅಥವಾ ದಕ್ಷವಾಗಿ ಇಲ್ಲದಿರಬಹುದು. ಅದು ಸರಿ. ಇಲ್ಲಿ ಕೇವಲ ಪರೀಕ್ಷೆಯಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಅವಶ್ಯಕತೆಯನ್ನು ಪೂರೈಸುವುದರ ಮೇಲೆ ಗಮನ ಕೇಂದ್ರೀಕರಿಸಲಾಗಿದೆ.
• 🔵 ರಿಫ್ಯಾಕ್ಟರ್ — ಕೋಡ್ ಅನ್ನು ಸುಧಾರಿಸಿ: ಈಗ ನೀವು ಪಾಸ್ ಆಗುವ ಪರೀಕ್ಷೆಯನ್ನು ಹೊಂದಿದ್ದೀರಿ, ನಿಮ್ಮ ಬಳಿ ಸುರಕ್ಷತಾ ಜಾಲವಿದೆ. ಕಾರ್ಯಚಟುವಟಿಕೆಯನ್ನು ಮುರಿಯುವ ಭಯವಿಲ್ಲದೆ ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ನೀವು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಸ್ವಚ್ಛಗೊಳಿಸಬಹುದು ಮತ್ತು ಸುಧಾರಿಸಬಹುದು. ಇಲ್ಲಿ ನೀವು ಕೋಡ್ ಸ್ಮೆಲ್‌ಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತೀರಿ, ನಕಲುಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತೀರಿ, ಸ್ಪಷ್ಟತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತೀರಿ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸುತ್ತೀರಿ. ನೀವು ಯಾವುದೇ ಹಿನ್ನಡೆಗಳನ್ನು ಪರಿಚಯಿಸಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಸಮಯದಲ್ಲಿ ಯಾವುದೇ ಹಂತದಲ್ಲಿ ನಿಮ್ಮ ಟೆಸ್ಟ್ ಸೂಟ್ ಅನ್ನು ಚಲಾಯಿಸಬಹುದು. ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ನಂತರ, ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳು ಇನ್ನೂ ಗ್ರೀನ್ ಆಗಿರಬೇಕು.

ಒಂದು ಸಣ್ಣ ಕಾರ್ಯಚಟುವಟಿಕೆಗಾಗಿ ಚಕ್ರವು ಪೂರ್ಣಗೊಂಡ ನಂತರ, ನೀವು ಮುಂದಿನ ಭಾಗಕ್ಕಾಗಿ ಹೊಸ ವಿಫಲ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಮತ್ತೆ ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ.

TDD ಯ ಮೂರು ನಿಯಮಗಳು

ರಾಬರ್ಟ್ ಸಿ. ಮಾರ್ಟಿನ್ (ಸಾಮಾನ್ಯವಾಗಿ "ಅಂಕಲ್ ಬಾಬ್" ಎಂದು ಕರೆಯುತ್ತಾರೆ), ಅಗೈಲ್ ಸಾಫ್ಟ್‌ವೇರ್ ಚಳುವಳಿಯ ಪ್ರಮುಖ ವ್ಯಕ್ತಿ, TDD ಶಿಸ್ತನ್ನು ಕ್ರೋಡೀಕರಿಸುವ ಮೂರು ಸರಳ ನಿಯಮಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿದ್ದಾರೆ:

1. ವಿಫಲವಾದ ಯೂನಿಟ್ ಪರೀಕ್ಷೆಯನ್ನು ಪಾಸ್ ಮಾಡಲು ಹೊರತುಪಡಿಸಿ, ನೀವು ಯಾವುದೇ ಪ್ರೊಡಕ್ಷನ್ ಕೋಡ್ ಬರೆಯುವಂತಿಲ್ಲ.
2. ವಿಫಲಗೊಳ್ಳಲು ಸಾಕಾಗುವಷ್ಟು ಯೂನಿಟ್ ಪರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ನೀವು ಬರೆಯುವಂತಿಲ್ಲ; ಮತ್ತು ಕಂಪೈಲೇಶನ್ ವೈಫಲ್ಯಗಳೂ ವೈಫಲ್ಯಗಳೇ.
3. ಒಂದು ವಿಫಲವಾದ ಯೂನಿಟ್ ಪರೀಕ್ಷೆಯನ್ನು ಪಾಸ್ ಮಾಡಲು ಸಾಕಾಗುವಷ್ಟು ಪ್ರೊಡಕ್ಷನ್ ಕೋಡ್‌ಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ನೀವು ಬರೆಯುವಂತಿಲ್ಲ.

ಈ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸುವುದರಿಂದ ನೀವು ರೆಡ್-ಗ್ರೀನ್-ರಿಫ್ಯಾಕ್ಟರ್ ಚಕ್ರಕ್ಕೆ ಬಲವಂತವಾಗಿ ಪ್ರವೇಶಿಸುತ್ತೀರಿ ಮತ್ತು ನಿಮ್ಮ 100% ಪ್ರೊಡಕ್ಷನ್ ಕೋಡ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟ, ಪರೀಕ್ಷಿತ ಅವಶ್ಯಕತೆಯನ್ನು ಪೂರೈಸಲು ಬರೆಯಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ನೀವು TDD ಯನ್ನು ಏಕೆ ಅಳವಡಿಸಿಕೊಳ್ಳಬೇಕು? ಜಾಗತಿಕ ವ್ಯವಹಾರದ ಪ್ರಕರಣ

TDD ವೈಯಕ್ತಿಕ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅಪಾರ ಪ್ರಯೋಜನಗಳನ್ನು ನೀಡುತ್ತದೆಯಾದರೂ, ಅದರ ನಿಜವಾದ ಶಕ್ತಿಯು ತಂಡ ಮತ್ತು ವ್ಯವಹಾರ ಮಟ್ಟದಲ್ಲಿ, ವಿಶೇಷವಾಗಿ ಜಾಗತಿಕವಾಗಿ ವಿತರಿಸಲಾದ ಪರಿಸರದಲ್ಲಿ ಅರಿತುಕೊಳ್ಳಲ್ಪಡುತ್ತದೆ.

• ಹೆಚ್ಚಿದ ಆತ್ಮವಿಶ್ವಾಸ ಮತ್ತು ವೇಗ: ಒಂದು ಸಮಗ್ರ ಟೆಸ್ಟ್ ಸೂಟ್ ಸುರಕ್ಷತಾ ಜಾಲವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ತಂಡಗಳಿಗೆ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸೇರಿಸಲು ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವವುಗಳನ್ನು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಇದು ಹೆಚ್ಚಿನ ಸಮರ್ಥನೀಯ ಅಭಿವೃದ್ಧಿ ವೇಗಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ನೀವು ಮ್ಯಾನುಯಲ್ ರಿಗ್ರೆಶನ್ ಟೆಸ್ಟಿಂಗ್ ಮತ್ತು ಡೀಬಗ್ಗಿಂಗ್‌ಗೆ ಕಡಿಮೆ ಸಮಯವನ್ನು ವಿನಿಯೋಗಿಸುತ್ತೀರಿ ಮತ್ತು ಮೌಲ್ಯವನ್ನು ತಲುಪಿಸಲು ಹೆಚ್ಚು ಸಮಯವನ್ನು ವಿನಿಯೋಗಿಸುತ್ತೀರಿ.
• ಸುಧಾರಿತ ಕೋಡ್ ವಿನ್ಯಾಸ: ಮೊದಲು ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುವುದು ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಹೇಗೆ ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಯೋಚಿಸಲು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ. ನಿಮ್ಮ ಸ್ವಂತ API ಯ ಮೊದಲ ಗ್ರಾಹಕ ನೀವೇ. ಇದು ಸ್ವಾಭಾವಿಕವಾಗಿ ಸಣ್ಣ, ಹೆಚ್ಚು ಕೇಂದ್ರೀಕೃತ ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಕಾಳಜಿಗಳ ಸ್ಪಷ್ಟ ಪ್ರತ್ಯೇಕತೆಯೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
• ಜೀವಂತ ದಸ್ತಾವೇಜೀಕರಣ: ವಿವಿಧ ಸಮಯ ವಲಯಗಳು ಮತ್ತು ಸಂಸ್ಕೃತಿಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಜಾಗತಿಕ ತಂಡಕ್ಕೆ, ಸ್ಪಷ್ಟವಾದ ದಸ್ತಾವೇಜೀಕರಣವು ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಉತ್ತಮವಾಗಿ ಬರೆಯಲಾದ ಟೆಸ್ಟ್ ಸೂಟ್ ಒಂದು ರೀತಿಯ ಜೀವಂತ, ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ದಸ್ತಾವೇಜೀಕರಣವಾಗಿದೆ. ಹೊಸ ಡೆವಲಪರ್ ಒಂದು ಕೋಡ್ ತುಣುಕು ಏನು ಮಾಡಬೇಕು ಮತ್ತು ವಿವಿಧ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಅದು ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪರೀಕ್ಷೆಗಳನ್ನು ಓದಬಹುದು. ಸಾಂಪ್ರದಾಯಿಕ ದಸ್ತಾವೇಜೀಕರಣದಂತೆ, ಇದು ಎಂದಿಗೂ ಹಳೆಯದಾಗಲು ಸಾಧ್ಯವಿಲ್ಲ.
• ಒಟ್ಟು ಮಾಲೀಕತ್ವದ ವೆಚ್ಚ (TCO) ಕಡಿತ: ಅಭಿವೃದ್ಧಿ ಚಕ್ರದ ಆರಂಭದಲ್ಲಿ ಹಿಡಿದ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುವುದು, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕಂಡುಬರುವ ದೋಷಗಳಿಗಿಂತ ಘಾತೀಯವಾಗಿ ಅಗ್ಗವಾಗಿದೆ. TDD ಕಾಲಾನಂತರದಲ್ಲಿ ನಿರ್ವಹಿಸಲು ಮತ್ತು ವಿಸ್ತರಿಸಲು ಸುಲಭವಾದ ಒಂದು ದೃಢವಾದ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸುತ್ತದೆ, ಸಾಫ್ಟ್‌ವೇರ್‌ನ ದೀರ್ಘಾವಧಿಯ TCO ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ನಿಮ್ಮ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ TDD ಪರಿಸರವನ್ನು ಸ್ಥಾಪಿಸುವುದು

ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ TDD ಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಲು, ನಿಮಗೆ ಕೆಲವು ಉಪಕರಣಗಳು ಬೇಕಾಗುತ್ತವೆ. ಆಧುನಿಕ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯು ಅತ್ಯುತ್ತಮ ಆಯ್ಕೆಗಳನ್ನು ನೀಡುತ್ತದೆ.

ಪರೀಕ್ಷಾ ಸ್ಟಾಕ್‌ನ ಪ್ರಮುಖ ಅಂಶಗಳು

• ಟೆಸ್ಟ್ ರನ್ನರ್: ನಿಮ್ಮ ಪರೀಕ್ಷೆಗಳನ್ನು ಹುಡುಕಿ ಚಲಾಯಿಸುವ ಪ್ರೋಗ್ರಾಂ. ಇದು ರಚನೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ `describe` ಮತ್ತು `it` ಬ್ಲಾಕ್‌ಗಳು) ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಜೆಸ್ಟ್ ಮತ್ತು ಮೋಕಾ ಎರಡು ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಆಯ್ಕೆಗಳಾಗಿವೆ.
• ಅಸರ್ಷನ್ ಲೈಬ್ರರಿ: ನಿಮ್ಮ ಕೋಡ್ ನಿರೀಕ್ಷೆಯಂತೆ ವರ್ತಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಲು ಕಾರ್ಯಗಳನ್ನು ಒದಗಿಸುವ ಸಾಧನ. ಇದು `expect(result).toBe(true)` ನಂತಹ ಹೇಳಿಕೆಗಳನ್ನು ಬರೆಯಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಚಾಯ್ ಒಂದು ಜನಪ್ರಿಯ ಸ್ವತಂತ್ರ ಲೈಬ್ರರಿಯಾಗಿದೆ, ಆದರೆ ಜೆಸ್ಟ್ ತನ್ನದೇ ಆದ ಶಕ್ತಿಯುತ ಅಸರ್ಷನ್ ಲೈಬ್ರರಿಯನ್ನು ಒಳಗೊಂಡಿದೆ.
• ಮಾಕಿಂಗ್ ಲೈಬ್ರರಿ: API ಕರೆಗಳು ಅಥವಾ ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕಗಳಂತಹ ಅವಲಂಬನೆಗಳ "ನಕಲಿಗಳನ್ನು" ರಚಿಸುವ ಸಾಧನ. ಇದು ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಜೆಸ್ಟ್ ಅತ್ಯುತ್ತಮ ಅಂತರ್ನಿರ್ಮಿತ ಮಾಕಿಂಗ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದೆ.

ಅದರ ಸರಳತೆ ಮತ್ತು ಆಲ್-ಇನ್-ಒನ್ ಸ್ವಭಾವಕ್ಕಾಗಿ, ನಾವು ನಮ್ಮ ಉದಾಹರಣೆಗಳಿಗಾಗಿ ಜೆಸ್ಟ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದು "ಶೂನ್ಯ-ಕಾನ್ಫಿಗರೇಶನ್" ಅನುಭವವನ್ನು ಬಯಸುವ ತಂಡಗಳಿಗೆ ಅತ್ಯುತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ.

ಜೆಸ್ಟ್‌ನೊಂದಿಗೆ ಹಂತ-ಹಂತದ ಸ್ಥಾಪನೆ

TDD ಗಾಗಿ ಹೊಸ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸೋಣ.

1. ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿ: ನಿಮ್ಮ ಟರ್ಮಿನಲ್ ತೆರೆಯಿರಿ ಮತ್ತು ಹೊಸ ಪ್ರಾಜೆಕ್ಟ್ ಡೈರೆಕ್ಟರಿಯನ್ನು ರಚಿಸಿ.

mkdir js-tdd-project
cd js-tdd-project
npm init -y

2. ಜೆಸ್ಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ: ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಜೆಸ್ಟ್ ಅನ್ನು ಡೆವಲಪ್‌ಮೆಂಟ್ ಡಿಪೆಂಡೆನ್ಸಿಯಾಗಿ ಸೇರಿಸಿ.

npm install --save-dev jest

3. ಟೆಸ್ಟ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ: ನಿಮ್ಮ `package.json` ಫೈಲ್ ತೆರೆಯಿರಿ. `"scripts"` ವಿಭಾಗವನ್ನು ಹುಡುಕಿ ಮತ್ತು `"test"` ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಮಾರ್ಪಡಿಸಿ. `"test:watch"` ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸೇರಿಸಲು ಸಹ ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ, ಇದು TDD ವರ್ಕ್‌ಫ್ಲೋಗೆ ಅಮೂಲ್ಯವಾಗಿದೆ.

"scripts": {
  "test": "jest",
  "test:watch": "jest --watchAll"
}

`--watchAll` ಫ್ಲ್ಯಾಗ್ ಜೆಸ್ಟ್‌ಗೆ ಫೈಲ್ ಸೇವ್ ಮಾಡಿದಾಗಲೆಲ್ಲಾ ಪರೀಕ್ಷೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮರು-ಚಲಾಯಿಸಲು ಹೇಳುತ್ತದೆ. ಇದು ತ್ವರಿತ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇದು ರೆಡ್-ಗ್ರೀನ್-ರಿಫ್ಯಾಕ್ಟರ್ ಚಕ್ರಕ್ಕೆ ಪರಿಪೂರ್ಣವಾಗಿದೆ.

ಅಷ್ಟೇ! ನಿಮ್ಮ ಪರಿಸರ ಸಿದ್ಧವಾಗಿದೆ. ಜೆಸ್ಟ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ `*.test.js`, `*.spec.js` ಎಂದು ಹೆಸರಿಸಲಾದ ಅಥವಾ `__tests__` ಡೈರೆಕ್ಟರಿಯಲ್ಲಿರುವ ಪರೀಕ್ಷಾ ಫೈಲ್‌ಗಳನ್ನು ಹುಡುಕುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ TDD: `CurrencyConverter` ಮಾಡ್ಯೂಲ್ ನಿರ್ಮಿಸುವುದು

TDD ಚಕ್ರವನ್ನು ಪ್ರಾಯೋಗಿಕ, ಜಾಗತಿಕವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಸಮಸ್ಯೆಗೆ ಅನ್ವಯಿಸೋಣ: ಕರೆನ್ಸಿಗಳ ನಡುವೆ ಹಣವನ್ನು ಪರಿವರ್ತಿಸುವುದು. ನಾವು ಹಂತ ಹಂತವಾಗಿ `CurrencyConverter` ಮಾಡ್ಯೂಲ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ.

ಪುನರಾವರ್ತನೆ 1: ಸರಳ, ಸ್ಥಿರ-ದರ ಪರಿವರ್ತನೆ

🔴 ರೆಡ್: ಮೊದಲ ವಿಫಲ ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯಿರಿ

ನಮ್ಮ ಮೊದಲ ಅವಶ್ಯಕತೆ ಸ್ಥಿರ ದರವನ್ನು ಬಳಸಿಕೊಂಡು ಒಂದು ಕರೆನ್ಸಿಯಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ನಿರ್ದಿಷ್ಟ ಮೊತ್ತವನ್ನು ಪರಿವರ್ತಿಸುವುದು. `CurrencyConverter.test.js` ಎಂಬ ಹೊಸ ಫೈಲ್ ಅನ್ನು ರಚಿಸಿ.

// CurrencyConverter.test.js
const CurrencyConverter = require('./CurrencyConverter');

describe('CurrencyConverter', () => {
  it('should convert an amount from USD to EUR correctly', () => {
    // ಅರೇಂಜ್ (ಸಿದ್ದತೆ)
    const amount = 10; // 10 ಯುಎಸ್‌ಡಿ
    const expected = 9.2; // 1 ಯುಎಸ್‌ಡಿ = 0.92 ಯುರೋ ಎಂಬ ಸ್ಥಿರ ದರವನ್ನು ಊಹಿಸಿ

    // ಆಕ್ಟ್ (ಕಾರ್ಯ)
    const result = CurrencyConverter.convert(amount, 'USD', 'EUR');

    // ಅಸರ್ಟ್ (ದೃಢೀಕರಣ)
    expect(result).toBe(expected);
  });
});

ಈಗ, ನಿಮ್ಮ ಟರ್ಮಿನಲ್‌ನಿಂದ ಟೆಸ್ಟ್ ವಾಚರ್ ಅನ್ನು ಚಲಾಯಿಸಿ:

npm run test:watch

ಪರೀಕ್ಷೆಯು ಅದ್ಭುತವಾಗಿ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ಜೆಸ್ಟ್ `TypeError: Cannot read properties of undefined (reading 'convert')` ರೀತಿಯ ವರದಿಯನ್ನು ನೀಡುತ್ತದೆ. ಇದು ನಮ್ಮ ರೆಡ್ ಸ್ಥಿತಿ. `CurrencyConverter` ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಕಾರಣ ಪರೀಕ್ಷೆಯು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ.

🟢 ಗ್ರೀನ್: ಪಾಸ್ ಮಾಡಲು ಸರಳವಾದ ಕೋಡ್ ಬರೆಯಿರಿ

ಈಗ, ಪರೀಕ್ಷೆಯನ್ನು ಪಾಸ್ ಮಾಡೋಣ. `CurrencyConverter.js` ಅನ್ನು ರಚಿಸಿ.

// CurrencyConverter.js
const rates = {
  USD: {
    EUR: 0.92
  }
};

const CurrencyConverter = {
  convert(amount, from, to) {
    return amount * rates[from][to];
  }
};

module.exports = CurrencyConverter;

ನೀವು ಈ ಫೈಲ್ ಅನ್ನು ಉಳಿಸಿದ ತಕ್ಷಣ, ಜೆಸ್ಟ್ ಪರೀಕ್ಷೆಯನ್ನು ಮರು-ಚಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಗ್ರೀನ್ ಆಗುತ್ತದೆ. ನಾವು ಪರೀಕ್ಷೆಯ ಅವಶ್ಯಕತೆಯನ್ನು ಪೂರೈಸಲು ಸಂಪೂರ್ಣ ಕನಿಷ್ಠ ಕೋಡ್ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ.

🔵 ರಿಫ್ಯಾಕ್ಟರ್: ಕೋಡ್ ಅನ್ನು ಸುಧಾರಿಸಿ

ಕೋಡ್ ಸರಳವಾಗಿದೆ, ಆದರೆ ನಾವು ಈಗಾಗಲೇ ಸುಧಾರಣೆಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಬಹುದು. ನೆಸ್ಟೆಡ್ `rates` ಆಬ್ಜೆಕ್ಟ್ ಸ್ವಲ್ಪ ಕಠಿಣವಾಗಿದೆ. ಸದ್ಯಕ್ಕೆ, ಇದು ಸಾಕಷ್ಟು ಸ್ವಚ್ಛವಾಗಿದೆ. ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ ನಾವು ಪರೀಕ್ಷೆಯಿಂದ ರಕ್ಷಿಸಲ್ಪಟ್ಟ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮುಂದಿನ ಅವಶ್ಯಕತೆಗೆ ಹೋಗೋಣ.

ಪುನರಾವರ್ತನೆ 2: ಅಪರಿಚಿತ ಕರೆನ್ಸಿಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು

🔴 ರೆಡ್: ಅಮಾನ್ಯ ಕರೆನ್ಸಿಗಾಗಿ ಪರೀಕ್ಷೆ ಬರೆಯಿರಿ

ನಮಗೆ ತಿಳಿದಿಲ್ಲದ ಕರೆನ್ಸಿಗೆ ಪರಿವರ್ತಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ ಏನಾಗಬೇಕು? ಅದು ಬಹುಶಃ ದೋಷವನ್ನು ಎಸೆಯಬೇಕು. `CurrencyConverter.test.js` ನಲ್ಲಿ ಹೊಸ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಈ ನಡವಳಿಕೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸೋಣ.

// CurrencyConverter.test.js ನಲ್ಲಿ, describe ಬ್ಲಾಕ್‌ನ ಒಳಗೆ

it('should throw an error for unknown currencies', () => {
  // ಅರೇಂಜ್ (ಸಿದ್ದತೆ)
  const amount = 10;

  // ಆಕ್ಟ್ (ಕಾರ್ಯ) & ಅಸರ್ಟ್ (ದೃಢೀಕರಣ)
  // ಜೆಸ್ಟ್‌ನ toThrow ಕಾರ್ಯನಿರ್ವಹಿಸಲು ನಾವು ಫಂಕ್ಷನ್ ಕರೆಯನ್ನು ಆರೋ ಫಂಕ್ಷನ್‌ನಲ್ಲಿ ಸುತ್ತುತ್ತೇವೆ.
  expect(() => {
    CurrencyConverter.convert(amount, 'USD', 'XYZ');
  }).toThrow('Unknown currency: XYZ');
});

ಫೈಲ್ ಅನ್ನು ಸೇವ್ ಮಾಡಿ. ಟೆಸ್ಟ್ ರನ್ನರ್ ತಕ್ಷಣವೇ ಹೊಸ ವೈಫಲ್ಯವನ್ನು ತೋರಿಸುತ್ತದೆ. ನಮ್ಮ ಕೋಡ್ ದೋಷವನ್ನು ಎಸೆಯದ ಕಾರಣ ಇದು ರೆಡ್ ಆಗಿದೆ; ಇದು `rates['USD']['XYZ']` ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ `TypeError` ಉಂಟಾಗುತ್ತದೆ. ನಮ್ಮ ಹೊಸ ಪರೀಕ್ಷೆಯು ಈ ದೋಷವನ್ನು ಸರಿಯಾಗಿ ಗುರುತಿಸಿದೆ.

🟢 ಗ್ರೀನ್: ಹೊಸ ಪರೀಕ್ಷೆಯನ್ನು ಪಾಸ್ ಮಾಡಿ

ಮೌಲ್ಯೀಕರಣವನ್ನು ಸೇರಿಸಲು `CurrencyConverter.js` ಅನ್ನು ಮಾರ್ಪಡಿಸೋಣ.

// CurrencyConverter.js
const rates = {
  USD: {
    EUR: 0.92,
    GBP: 0.80
  },
  EUR: {
    USD: 1.08
  }
};

const CurrencyConverter = {
  convert(amount, from, to) {
    if (!rates[from] || !rates[from][to]) {
      // ಉತ್ತಮ ದೋಷ ಸಂದೇಶಕ್ಕಾಗಿ ಯಾವ ಕರೆನ್ಸಿ ಅಪರಿಚಿತವಾಗಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿ
      const unknownCurrency = !rates[from] ? from : to;
      throw new Error(`Unknown currency: ${unknownCurrency}`);
    }
    return amount * rates[from][to];
  }
};

module.exports = CurrencyConverter;

ಫೈಲ್ ಅನ್ನು ಸೇವ್ ಮಾಡಿ. ಎರಡೂ ಪರೀಕ್ಷೆಗಳು ಈಗ ಪಾಸ್ ಆಗುತ್ತವೆ. ನಾವು ಗ್ರೀನ್ ಗೆ ಮರಳಿದ್ದೇವೆ.

🔵 ರಿಫ್ಯಾಕ್ಟರ್: ಅದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಿ

ನಮ್ಮ `convert` ಫಂಕ್ಷನ್ ಬೆಳೆಯುತ್ತಿದೆ. ಮೌಲ್ಯೀಕರಣ ತರ್ಕವು ಲೆಕ್ಕಾಚಾರದೊಂದಿಗೆ ಬೆರೆತಿದೆ. ಓದುವಿಕೆಯನ್ನು ಸುಧಾರಿಸಲು ನಾವು ಮೌಲ್ಯೀಕರಣವನ್ನು ಪ್ರತ್ಯೇಕ ಖಾಸಗಿ ಫಂಕ್ಷನ್‌ಗೆ ಹೊರತೆಗೆಯಬಹುದು, ಆದರೆ ಸದ್ಯಕ್ಕೆ, ಇದು ಇನ್ನೂ ನಿರ್ವಹಿಸಬಲ್ಲದು. ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ನಮ್ಮ ಪರೀಕ್ಷೆಗಳು ನಾವು ಏನನ್ನಾದರೂ ಮುರಿದರೆ ನಮಗೆ ತಿಳಿಸುವುದರಿಂದ ಈ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ನಮಗೆ ಸ್ವಾತಂತ್ರ್ಯವಿದೆ.

ಪುನರಾವರ್ತನೆ 3: ಅಸಮಕಾಲಿಕ ದರ ಪಡೆದುಕೊಳ್ಳುವಿಕೆ

ದರಗಳನ್ನು ಹಾರ್ಡ್‌ಕೋಡಿಂಗ್ ಮಾಡುವುದು ವಾಸ್ತವಿಕವಲ್ಲ. (ಮಾಕ್ ಮಾಡಿದ) ಬಾಹ್ಯ API ಯಿಂದ ದರಗಳನ್ನು ಪಡೆಯಲು ನಮ್ಮ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡೋಣ.

🔴 ರೆಡ್: API ಕರೆಯನ್ನು ಮಾಕ್ ಮಾಡುವ ಅಸಿಂಕ್ ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯಿರಿ

ಮೊದಲಿಗೆ, ನಾವು ನಮ್ಮ ಪರಿವರ್ತಕವನ್ನು ಮರುರಚಿಸಬೇಕಾಗಿದೆ. ಇದು ಈಗ ನಾವು ಇನ್‌ಸ್ಟಾನ್ಶಿಯೇಟ್ ಮಾಡಬಹುದಾದ ಕ್ಲಾಸ್ ಆಗಿರಬೇಕು, ಬಹುಶಃ API ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ. ನಾವು `fetch` API ಅನ್ನು ಸಹ ಮಾಕ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಜೆಸ್ಟ್ ಇದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.

ಈ ಹೊಸ, ಅಸಮಕಾಲಿಕ ವಾಸ್ತವಕ್ಕೆ ಅನುಗುಣವಾಗಿ ನಮ್ಮ ಪರೀಕ್ಷಾ ಫೈಲ್ ಅನ್ನು ಪುನಃ ಬರೆಯೋಣ. ನಾವು ಮತ್ತೆ ಹ್ಯಾಪಿ ಪಾತ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವುದರೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ.

// CurrencyConverter.test.js
const CurrencyConverter = require('./CurrencyConverter');

// ಬಾಹ್ಯ ಅವಲಂಬನೆಯನ್ನು ಮಾಕ್ ಮಾಡಿ
global.fetch = jest.fn();

beforeEach(() => {
  // ಪ್ರತಿ ಪರೀಕ್ಷೆಯ ಮೊದಲು ಮಾಕ್ ಹಿಸ್ಟರಿಯನ್ನು ತೆರವುಗೊಳಿಸಿ
  fetch.mockClear();
});

describe('CurrencyConverter', () => {
  it('should fetch rates and convert correctly', async () => {
    // ಅರೇಂಜ್ (ಸಿದ್ದತೆ)
    // ಯಶಸ್ವಿ API ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಮಾಕ್ ಮಾಡಿ
    fetch.mockResolvedValueOnce({
      json: () => Promise.resolve({ rates: { EUR: 0.92 } })
    });

    const converter = new CurrencyConverter('https://api.exchangerates.com');
    const amount = 10; // 10 ಯುಎಸ್‌ಡಿ

    // ಆಕ್ಟ್ (ಕಾರ್ಯ)
    const result = await converter.convert(amount, 'USD', 'EUR');

    // ಅಸರ್ಟ್ (ದೃಢೀಕರಣ)
    expect(result).toBe(9.2);
    expect(fetch).toHaveBeenCalledTimes(1);
    expect(fetch).toHaveBeenCalledWith('https://api.exchangerates.com/latest?base=USD');
  });

  // ನಾವು API ವೈಫಲ್ಯಗಳು ಇತ್ಯಾದಿಗಳಿಗಾಗಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಕೂಡ ಸೇರಿಸುತ್ತೇವೆ.
});

ಇದನ್ನು ಚಲಾಯಿಸುವುದರಿಂದ ರೆಡ್ ನ ಸಮುದ್ರವೇ ಉಂಟಾಗುತ್ತದೆ. ನಮ್ಮ ಹಳೆಯ `CurrencyConverter` ಒಂದು ಕ್ಲಾಸ್ ಅಲ್ಲ, `async` ಮೆಥಡ್ ಹೊಂದಿಲ್ಲ, ಮತ್ತು `fetch` ಅನ್ನು ಬಳಸುವುದಿಲ್ಲ.

🟢 ಗ್ರೀನ್: ಅಸಿಂಕ್ ತರ್ಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ

ಈಗ, ಪರೀಕ್ಷೆಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸಲು `CurrencyConverter.js` ಅನ್ನು ಪುನಃ ಬರೆಯೋಣ.

// CurrencyConverter.js
class CurrencyConverter {
  constructor(apiUrl) {
    this.apiUrl = apiUrl;
  }

  async convert(amount, from, to) {
    const response = await fetch(`${this.apiUrl}/latest?base=${from}`);
    if (!response.ok) {
      throw new Error('Failed to fetch exchange rates.');
    }

    const data = await response.json();
    const rate = data.rates[to];

    if (!rate) {
      throw new Error(`Unknown currency: ${to}`);
    }

    // ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಫ್ಲೋಟಿಂಗ್ ಪಾಯಿಂಟ್ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಲು ಸರಳ ರೌಂಡಿಂಗ್
    const convertedAmount = amount * rate;
    return parseFloat(convertedAmount.toFixed(2));
  }
}

module.exports = CurrencyConverter;

ನೀವು ಉಳಿಸಿದಾಗ, ಪರೀಕ್ಷೆಯು ಗ್ರೀನ್ ಆಗಬೇಕು. ಹಣಕಾಸಿನ ಲೆಕ್ಕಾಚಾರಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಯಾದ ಫ್ಲೋಟಿಂಗ್-ಪಾಯಿಂಟ್ ತಪ್ಪುಗಳನ್ನು ನಿರ್ವಹಿಸಲು ನಾವು ರೌಂಡಿಂಗ್ ತರ್ಕವನ್ನು ಕೂಡ ಸೇರಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.

🔵 ರಿಫ್ಯಾಕ್ಟರ್: ಅಸಿಂಕ್ ಕೋಡ್ ಅನ್ನು ಸುಧಾರಿಸಿ

`convert` ಮೆಥಡ್ ಬಹಳಷ್ಟು ಕೆಲಸ ಮಾಡುತ್ತಿದೆ: ಪಡೆದುಕೊಳ್ಳುವುದು, ದೋಷ ನಿರ್ವಹಣೆ, ಪಾರ್ಸಿಂಗ್, ಮತ್ತು ಲೆಕ್ಕಾಚಾರ. ನಾವು ಇದನ್ನು ಕೇವಲ API ಸಂವಹನಕ್ಕೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಪ್ರತ್ಯೇಕ `RateFetcher` ಕ್ಲಾಸ್ ಅನ್ನು ರಚಿಸುವ ಮೂಲಕ ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಬಹುದು. ನಮ್ಮ `CurrencyConverter` ನಂತರ ಈ ಫೆಚರ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಇದು ಏಕ ಜವಾಬ್ದಾರಿ ತತ್ವವನ್ನು ಅನುಸರಿಸುತ್ತದೆ ಮತ್ತು ಎರಡೂ ಕ್ಲಾಸ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಸುಲಭಗೊಳಿಸುತ್ತದೆ. TDD ನಮ್ಮನ್ನು ಈ ಸ್ವಚ್ಛ ವಿನ್ಯಾಸದತ್ತ ಮಾರ್ಗದರ್ಶಿಸುತ್ತದೆ.

ಸಾಮಾನ್ಯ TDD ಮಾದರಿಗಳು ಮತ್ತು ವಿರೋಧಿ-ಮಾದರಿಗಳು

ನೀವು TDD ಯನ್ನು ಅಭ್ಯಾಸ ಮಾಡುವಾಗ, ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುವ ಮಾದರಿಗಳನ್ನು ಮತ್ತು ಘರ್ಷಣೆಯನ್ನು ಉಂಟುಮಾಡುವ ವಿರೋಧಿ-ಮಾದರಿಗಳನ್ನು ನೀವು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ.

ಅನುಸರಿಸಬೇಕಾದ ಉತ್ತಮ ಮಾದರಿಗಳು

• ಅರೇಂಜ್, ಆಕ್ಟ್, ಅಸರ್ಟ್ (AAA): ನಿಮ್ಮ ಪರೀಕ್ಷೆಗಳನ್ನು ಮೂರು ಸ್ಪಷ್ಟ ಭಾಗಗಳಲ್ಲಿ ರಚಿಸಿ. ನಿಮ್ಮ ಸೆಟಪ್ ಅನ್ನು ಅರೇಂಜ್ ಮಾಡಿ, ಪರೀಕ್ಷೆಯ ಅಡಿಯಲ್ಲಿರುವ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೂಲಕ ಆಕ್ಟ್ ಮಾಡಿ, ಮತ್ತು ಫಲಿತಾಂಶ ಸರಿಯಾಗಿದೆ ಎಂದು ಅಸರ್ಟ್ ಮಾಡಿ. ಇದು ಪರೀಕ್ಷೆಗಳನ್ನು ಓದಲು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾಗಿಸುತ್ತದೆ.
• ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ನಡವಳಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ: ಪ್ರತಿ ಪರೀಕ್ಷಾ ಪ್ರಕರಣವು ಒಂದೇ, ನಿರ್ದಿಷ್ಟ ನಡವಳಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಬೇಕು. ಇದು ಪರೀಕ್ಷೆಯು ವಿಫಲವಾದಾಗ ಏನು ಮುರಿದುಹೋಯಿತು ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ.
• ವಿವರಣಾತ್ಮಕ ಪರೀಕ್ಷಾ ಹೆಸರುಗಳನ್ನು ಬಳಸಿ: `'it('ಟೆಸ್ಟ್ 1')'` ಗಿಂತ `'it('ಮೊತ್ತವು ಋಣಾತ್ಮಕವಾಗಿದ್ದರೆ ದೋಷವನ್ನು ಎಸೆಯಬೇಕು')'` ಎಂಬಂತಹ ಪರೀಕ್ಷಾ ಹೆಸರು ಹೆಚ್ಚು ಮೌಲ್ಯಯುತವಾಗಿದೆ.

ತಪ್ಪಿಸಬೇಕಾದ ವಿರೋಧಿ-ಮಾದರಿಗಳು

• ಅನುಷ್ಠಾನದ ವಿವರಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು: ಪರೀಕ್ಷೆಗಳು ಸಾರ್ವಜನಿಕ API ("ಏನು") ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಬೇಕು, ಖಾಸಗಿ ಅನುಷ್ಠಾನದ ("ಹೇಗೆ") ಮೇಲಲ್ಲ. ಖಾಸಗಿ ವಿಧಾನಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದರಿಂದ ನಿಮ್ಮ ಪರೀಕ್ಷೆಗಳು ದುರ್ಬಲವಾಗುತ್ತವೆ ಮತ್ತು ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಕಷ್ಟವಾಗುತ್ತದೆ.
• ರಿಫ್ಯಾಕ್ಟರ್ ಹಂತವನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು: ಇದು ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು. ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡುವುದು ನಿಮ್ಮ ಪ್ರೊಡಕ್ಷನ್ ಕೋಡ್ ಮತ್ತು ನಿಮ್ಮ ಟೆಸ್ಟ್ ಸೂಟ್ ಎರಡರಲ್ಲೂ ತಾಂತ್ರಿಕ ಸಾಲಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.
• ದೊಡ್ಡ, ನಿಧಾನಗತಿಯ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುವುದು: ಯೂನಿಟ್ ಪರೀಕ್ಷೆಗಳು ವೇಗವಾಗಿರಬೇಕು. ಅವು ನೈಜ ಡೇಟಾಬೇಸ್‌ಗಳು, ನೆಟ್‌ವರ್ಕ್ ಕರೆಗಳು, ಅಥವಾ ಫೈಲ್‌ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ಅವು ನಿಧಾನ ಮತ್ತು ಅವಿಶ್ವಾಸಾರ್ಹವಾಗುತ್ತವೆ. ನಿಮ್ಮ ಯೂನಿಟ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಮಾಕ್‌ಗಳು ಮತ್ತು ಸ್ಟಬ್‌ಗಳನ್ನು ಬಳಸಿ.

ವಿಸ್ತಾರವಾದ ಅಭಿವೃದ್ಧಿ ಜೀವನಚಕ್ರದಲ್ಲಿ TDD

TDD ನಿರ್ವಾತದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಇದು ಆಧುನಿಕ ಅಗೈಲ್ ಮತ್ತು ಡೆವ್‌ಆಪ್ಸ್ ಅಭ್ಯಾಸಗಳೊಂದಿಗೆ, ವಿಶೇಷವಾಗಿ ಜಾಗತಿಕ ತಂಡಗಳಿಗೆ ಸುಂದರವಾಗಿ ಸಂಯೋಜನೆಗೊಳ್ಳುತ್ತದೆ.

• TDD ಮತ್ತು ಅಗೈಲ್: ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಪರಿಕರದಿಂದ ಬಳಕೆದಾರರ ಕಥೆ ಅಥವಾ ಸ್ವೀಕಾರ ಮಾನದಂಡವನ್ನು ನೇರವಾಗಿ ವಿಫಲವಾಗುವ ಪರೀಕ್ಷೆಗಳ ಸರಣಿಗೆ ಅನುವಾದಿಸಬಹುದು. ಇದು ನೀವು ವ್ಯವಹಾರಕ್ಕೆ ಬೇಕಾದುದನ್ನು ನಿಖರವಾಗಿ ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.
• TDD ಮತ್ತು ನಿರಂತರ ಏಕೀಕರಣ/ನಿರಂತರ ನಿಯೋಜನೆ (CI/CD): TDD ಒಂದು ವಿಶ್ವಾಸಾರ್ಹ CI/CD ಪೈಪ್‌ಲೈನ್‌ನ ಅಡಿಪಾಯವಾಗಿದೆ. ಪ್ರತಿ ಬಾರಿ ಡೆವಲಪರ್ ಕೋಡ್ ಅನ್ನು ಪುಶ್ ಮಾಡಿದಾಗ, ಒಂದು ಸ್ವಯಂಚಾಲಿತ ವ್ಯವಸ್ಥೆ (ಉದಾಹರಣೆಗೆ GitHub Actions, GitLab CI, ಅಥವಾ Jenkins) ಸಂಪೂರ್ಣ ಟೆಸ್ಟ್ ಸೂಟ್ ಅನ್ನು ಚಲಾಯಿಸಬಹುದು. ಯಾವುದೇ ಪರೀಕ್ಷೆ ವಿಫಲವಾದರೆ, ಬಿಲ್ಡ್ ಅನ್ನು ನಿಲ್ಲಿಸಲಾಗುತ್ತದೆ, ದೋಷಗಳು ಉತ್ಪಾದನೆಯನ್ನು ತಲುಪುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಇದು ಸಮಯ ವಲಯಗಳನ್ನು ಲೆಕ್ಕಿಸದೆ ಇಡೀ ತಂಡಕ್ಕೆ ವೇಗದ, ಸ್ವಯಂಚಾಲಿತ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ.
• TDD ವರ್ಸಸ್ BDD (ನಡವಳಿಕೆ-ಚಾಲಿತ ಅಭಿವೃದ್ಧಿ): BDD ಎಂಬುದು TDD ಯ ವಿಸ್ತರಣೆಯಾಗಿದ್ದು, ಇದು ಡೆವಲಪರ್‌ಗಳು, QA, ಮತ್ತು ವ್ಯವಹಾರದ ಮಧ್ಯಸ್ಥಗಾರರ ನಡುವಿನ ಸಹಯೋಗದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ. ಇದು ನಡವಳಿಕೆಯನ್ನು ವಿವರಿಸಲು ನೈಸರ್ಗಿಕ ಭಾಷಾ ಸ್ವರೂಪವನ್ನು (ಗಿವೆನ್-ವೆನ್-ದೆನ್) ಬಳಸುತ್ತದೆ. ಆಗಾಗ್ಗೆ, ಒಂದು BDD ಫೀಚರ್ ಫೈಲ್ ಹಲವಾರು TDD-ಶೈಲಿಯ ಯೂನಿಟ್ ಪರೀಕ್ಷೆಗಳ ರಚನೆಗೆ ಚಾಲನೆ ನೀಡುತ್ತದೆ.

ತೀರ್ಮಾನ: TDD ಯೊಂದಿಗೆ ನಿಮ್ಮ ಪ್ರಯಾಣ

ಟೆಸ್ಟ್-ಡ್ರಿವನ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಕೇವಲ ಒಂದು ಪರೀಕ್ಷಾ ಕಾರ್ಯತಂತ್ರಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿದೆ—ಇದು ನಾವು ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯನ್ನು ಹೇಗೆ സമീപಿಸುತ್ತೇವೆ ಎಂಬುದರಲ್ಲಿನ ಒಂದು ಮಾದರಿ ಬದಲಾವಣೆಯಾಗಿದೆ. ಇದು ಗುಣಮಟ್ಟ, ಆತ್ಮವಿಶ್ವಾಸ ಮತ್ತು ಸಹಯೋಗದ ಸಂಸ್ಕೃತಿಯನ್ನು ಬೆಳೆಸುತ್ತದೆ. ರೆಡ್-ಗ್ರೀನ್-ರಿಫ್ಯಾಕ್ಟರ್ ಚಕ್ರವು ಸ್ವಚ್ಛ, ದೃಢವಾದ ಮತ್ತು ನಿರ್ವಹಿಸಬಲ್ಲ ಕೋಡ್‌ನತ್ತ ನಿಮಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡುವ ಸ್ಥಿರವಾದ ಲಯವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ ಬರುವ ಟೆಸ್ಟ್ ಸೂಟ್ ನಿಮ್ಮ ತಂಡವನ್ನು ಹಿನ್ನಡೆಗಳಿಂದ ರಕ್ಷಿಸುವ ಸುರಕ್ಷತಾ ಜಾಲವಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸ ಸದಸ್ಯರನ್ನು ಆನ್‌ಬೋರ್ಡ್ ಮಾಡುವ ಜೀವಂತ ದಸ್ತಾವೇಜೀಕರಣವಾಗುತ್ತದೆ.

ಕಲಿಕೆಯ ರೇಖೆಯು ಕಡಿದಾಗಿರಬಹುದು, ಮತ್ತು ಆರಂಭಿಕ ವೇಗವು ನಿಧಾನವೆಂದು ತೋರಬಹುದು. ಆದರೆ ಡೀಬಗ್ಗಿಂಗ್ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದರಲ್ಲಿ, ಸಾಫ್ಟ್‌ವೇರ್ ವಿನ್ಯಾಸವನ್ನು ಸುಧಾರಿಸುವುದರಲ್ಲಿ ಮತ್ತು ಡೆವಲಪರ್ ಆತ್ಮವಿಶ್ವಾಸವನ್ನು ಹೆಚ್ಚಿಸುವುದರಲ್ಲಿ ದೀರ್ಘಾವಧಿಯ ಲಾಭಾಂಶಗಳು ಅಪರಿಮಿತವಾಗಿವೆ. TDD ಯನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳುವ ಪ್ರಯಾಣವು ಶಿಸ್ತು ಮತ್ತು ಅಭ್ಯಾಸದಿಂದ ಕೂಡಿದೆ.

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