ರಸ್ಟ್ ಚೈಲ್ಡ್ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ mod.rs ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಪರೀಕ್ಷಾ ಫೈಲ್ ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದು

ರಸ್ಟ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ ಮಾಡ್ಯೂಲ್ ಪ್ರವೇಶವನ್ನು ಅನ್ವೇಷಿಸಲಾಗುತ್ತಿದೆ

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

ರಸ್ಟ್ ಪ್ರಾಜೆಕ್ಟ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ರಾಜೆಕ್ಟ್‌ನ ವಿವಿಧ ಭಾಗಗಳಿಂದ `mod.rs` ಫೈಲ್ ಅನ್ನು ಪ್ರವೇಶಿಸುವ ಸಾಮರ್ಥ್ಯವು ಪರೀಕ್ಷೆ ಮತ್ತು ಮಾಡ್ಯುಲಾರಿಟಿಗೆ ಮುಖ್ಯವಾಗಿದೆ. `mod.rs` ಫೈಲ್ ಮಾಡ್ಯೂಲ್‌ಗೆ ಪ್ರವೇಶ ಬಿಂದುವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಇದನ್ನು ಉಪ ಫೋಲ್ಡರ್‌ನ ವಿಷಯಗಳನ್ನು ಸಂಘಟಿಸಲು ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಪ್ರಮಾಣಿತ `src/` ಡೈರೆಕ್ಟರಿಯ ಹೊರಗಿರುವ `ಪರೀಕ್ಷೆಗಳು/` ಫೋಲ್ಡರ್‌ನಿಂದ ಈ ಫೈಲ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಪ್ರಯತ್ನಿಸುವಾಗ ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ. 🛠️

ನೀವು `src/` ಡೈರೆಕ್ಟರಿಯೊಳಗೆ `ನಿಯಂತ್ರಕಗಳು/` ಫೋಲ್ಡರ್ ಹೊಂದಿರುವ ಪ್ರಾಜೆಕ್ಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ಹೇಳೋಣ ಮತ್ತು ನೀವು ಅದರ ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಬಯಸುತ್ತೀರಿ. `tests/test.rs` ಫೈಲ್‌ನಿಂದ `mod.rs` ಫೈಲ್ ಅನ್ನು ಸರಿಯಾಗಿ ಆಮದು ಮಾಡಿಕೊಳ್ಳುವುದು ಮತ್ತು ಪ್ರವೇಶಿಸುವುದು ಹೇಗೆ ಎಂಬುದನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ನಿಮ್ಮ ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುಗಮಗೊಳಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ರಸ್ಟ್‌ನ ಮಾಡ್ಯೂಲ್ ವ್ಯವಸ್ಥೆಯು ಇದನ್ನು ಮನಬಂದಂತೆ ಸಾಧಿಸಲು ಸಾಪೇಕ್ಷ ಮಾರ್ಗಗಳು ಮತ್ತು ಮಾಡ್ಯೂಲ್ ಗೋಚರತೆಯ ಉತ್ತಮ ತಿಳುವಳಿಕೆಯನ್ನು ಬಯಸುತ್ತದೆ.

ಮುಂದಿನ ವಿಭಾಗದಲ್ಲಿ, `test.rs` ಫೈಲ್‌ನಿಂದ `ನಿಯಂತ್ರಕಗಳು` ಫೋಲ್ಡರ್‌ನಲ್ಲಿರುವ `mod.rs` ಅನ್ನು ಸರಿಯಾಗಿ ಉಲ್ಲೇಖಿಸುವ ಮೂಲಕ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ನಾವು ಹಂತಗಳ ಮೂಲಕ ನಡೆಯುತ್ತೇವೆ. ಕೊನೆಯಲ್ಲಿ, ಈ ಸವಾಲನ್ನು ನಿಭಾಯಿಸಲು ಮತ್ತು ನಿಮ್ಮ ರಸ್ಟ್ ಯೋಜನೆಗಳಿಗೆ ಪರಿಣಾಮಕಾರಿ ಪರೀಕ್ಷೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನೀವು ಸಜ್ಜಾಗುತ್ತೀರಿ. ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿವರಿಸಲು ಕೆಲವು ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳಿಗೆ ಧುಮುಕೋಣ!

ಆಜ್ಞೆ	ಬಳಕೆಯ ಉದಾಹರಣೆ
mod	ರಸ್ಟ್ ಯೋಜನೆಯೊಳಗೆ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಘೋಷಿಸುತ್ತದೆ. ಇತರ ಫೈಲ್‌ಗಳನ್ನು (ಉದಾ., ಮಾಡ್ ಕಂಟ್ರೋಲರ್‌ಗಳು;) ಅಥವಾ ಸಬ್‌ಮಾಡ್ಯೂಲ್‌ಗಳಂತಹ ಕೋಡ್‌ನ ನಿರ್ದಿಷ್ಟ ಭಾಗಗಳನ್ನು ಸೇರಿಸಲು ಮತ್ತು ಉಲ್ಲೇಖಿಸಲು ಇದನ್ನು ಬಳಸಬಹುದು.
#[cfg(test)]	ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವಾಗ ಮಾತ್ರ ಕೋಡ್‌ನ ಯಾವ ಭಾಗವನ್ನು ಕಂಪೈಲ್ ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ಸೂಚಿಸುವ ಗುಣಲಕ್ಷಣಗಳು. ಪರೀಕ್ಷಾ-ನಿರ್ದಿಷ್ಟ ತರ್ಕವನ್ನು ಮುಖ್ಯ ಕೋಡ್‌ಬೇಸ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಿಸಲು ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಪರೀಕ್ಷಾ ಕೋಡ್ ಉತ್ಪಾದನಾ ಕೋಡ್‌ನ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.
use	ನಿರ್ದಿಷ್ಟ ಮಾಡ್ಯೂಲ್‌ಗಳು, ಕಾರ್ಯಗಳು ಅಥವಾ ಪ್ರಕಾರಗಳನ್ನು ವ್ಯಾಪ್ತಿಗೆ ತರಲು ಬಳಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಿಯಂತ್ರಕಗಳನ್ನು ಬಳಸಿ :: sms; ಪರೀಕ್ಷಾ ಫೈಲ್‌ಗೆ `ನಿಯಂತ್ರಕಗಳು` ಡೈರೆಕ್ಟರಿಯಿಂದ `sms` ಮಾಡ್ಯೂಲ್ ಅನ್ನು ತರುತ್ತದೆ.
pub	ಈ ಕೀವರ್ಡ್ ಮಾಡ್ಯೂಲ್, ಫಂಕ್ಷನ್ ಅಥವಾ ವೇರಿಯಬಲ್ ಅನ್ನು ಅದರ ಪ್ರಸ್ತುತ ವ್ಯಾಪ್ತಿಯ ಹೊರಗಿನಿಂದ ಪ್ರವೇಶಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್‌ನ ಭಾಗಗಳಾದ `mod.rs` ನಲ್ಲಿನ ಕಾರ್ಯಗಳು ಪರೀಕ್ಷೆಗಳು ಸೇರಿದಂತೆ ಇತರ ಮಾಡ್ಯೂಲ್‌ಗಳಿಗೆ ಗೋಚರಿಸುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
#[test]	ಒಂದು ಕಾರ್ಯವನ್ನು ಘಟಕ ಪರೀಕ್ಷೆಯಾಗಿ ಗುರುತಿಸುತ್ತದೆ. ರಸ್ಟ್‌ನ ಅಂತರ್ನಿರ್ಮಿತ ಪರೀಕ್ಷಾ ಚೌಕಟ್ಟು ಪರೀಕ್ಷೆಗಳಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಕಾರ್ಯಗಳನ್ನು ಗುರುತಿಸಲು ಈ ಟಿಪ್ಪಣಿಯನ್ನು ಬಳಸುತ್ತದೆ, ಉದಾ., #[test] fn test_sms().
assert_eq!	ಎರಡು ಅಭಿವ್ಯಕ್ತಿಗಳು ಒಂದೇ ಮೌಲ್ಯಕ್ಕೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಮೌಲ್ಯಗಳು ಸಮಾನವಾಗಿಲ್ಲದಿದ್ದರೆ, ಪರೀಕ್ಷೆಯು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, assert_eq!(ಫಲಿತಾಂಶ, ಸರಿ("ಸಂದೇಶವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಕಳುಹಿಸಲಾಗಿದೆ!")); ಫಲಿತಾಂಶವು ನಿರೀಕ್ಷಿತ ಔಟ್‌ಪುಟ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ.
Err	ರಸ್ಟ್‌ನಲ್ಲಿನ ಫಲಿತಾಂಶ ಪ್ರಕಾರದ ರೂಪಾಂತರವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ, ಇದು ದೋಷ ಅಥವಾ ವೈಫಲ್ಯವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ದೋಷ ("ಅಮಾನ್ಯ ಇನ್‌ಪುಟ್") ನಲ್ಲಿ ಕಂಡುಬರುವಂತೆ, ವೈಫಲ್ಯದ ಸ್ಥಿತಿಯನ್ನು ಅನುಕರಿಸಲು ಪರೀಕ್ಷಾ ಸಂದರ್ಭದಲ್ಲಿ ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
Ok	ಫಲಿತಾಂಶ ಪ್ರಕಾರದ ಯಶಸ್ಸಿನ ರೂಪಾಂತರವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಸರಿ ("ಸಂದೇಶವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಕಳುಹಿಸಲಾಗಿದೆ!") ನಂತಹ ಯಶಸ್ವಿ ಫಲಿತಾಂಶವನ್ನು ಅನುಕರಿಸಲು ಇದನ್ನು ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ.
mod.rs	ಡೈರೆಕ್ಟರಿಗಾಗಿ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಘೋಷಿಸಲು ರಸ್ಟ್ ಬಳಸುವ ಫೈಲ್ ಹೆಸರು. ಅದೇ ಫೋಲ್ಡರ್‌ನಲ್ಲಿ ಸಬ್‌ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಸಂಘಟಿಸಲು ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ನೀವು ಮೂಲ ಫೋಲ್ಡರ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಿದಾಗ ಅವುಗಳನ್ನು ಪ್ರವೇಶಿಸುವಂತೆ ಮಾಡುತ್ತದೆ, ಉದಾ., ಮಾಡ್ ನಿಯಂತ್ರಕಗಳು; `ನಿಯಂತ್ರಕಗಳು/mod.rs` ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ.

ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು: ರಸ್ಟ್‌ನಲ್ಲಿ ಚೈಲ್ಡ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸುವುದು

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

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

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

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

mod controllers; // Declare the module from the controllers folder
use controllers::sms; // Use a specific module inside controllers
#[cfg(test)] // Mark the module for testing only
mod tests; // Declare the test module
#[cfg(test)] // Only compile the test code in test configuration
use crate::controllers::sms::send_sms; // Example of using the sms.rs file from controllers
#[test] // Declare a test function
fn test_sms_function() {
    assert_eq!(send_sms("12345", "Test message"), Ok("Message sent successfully!")); // Test the function
}

mod controllers { // Declare the controllers module
    pub mod sms; // Make the sms module accessible
    pub mod mod.rs; // Ensure mod.rs is public and accessible in tests
}
#[cfg(test)] // Only include this part in test builds
mod tests; // Test module declaration
use crate::controllers::sms::send_sms; // Access the sms function from controllers
#[test] // Mark this function as a test
fn test_sms() {
    let result = send_sms("12345", "Test message");
    assert_eq!(result, Ok("Message sent successfully!")); // Validate test results
}

mod controllers; // Declare the module path for controllers
use controllers::sms; // Use the sms module from controllers
#[cfg(test)] // This module is only included during testing
mod test; // Test module declaration
#[test] // The test annotation for unit tests
fn test_send_sms() {
    let result = sms::send_sms("12345", "Hello, World!");
    assert_eq!(result, Ok("Message sent successfully!")); // Check for expected result
}
#[test] // Another test for failure case
fn test_send_sms_failure() {
    let result = sms::send_sms("", "");
    assert_eq!(result, Err("Invalid input")); // Expect failure case
}

ಪರೀಕ್ಷೆಗಾಗಿ ರಸ್ಟ್‌ನಲ್ಲಿ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸುವುದು ಮತ್ತು ರಚನೆ ಮಾಡುವುದು ಹೇಗೆ

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

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

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