𝗕𝗗𝗗 ಬಗ್ಗೆ ಯಾರೂ ನಿಮಗೆ ಹೇಳದ 𝟯 ವಿಷಯಗಳು

ನಿಮ್ಮ Cucumber suite ಚಲಿಸಲು ನಲವತ್ತು ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಕೋಡ್‌ನ ಪದರಗಳನ್ನು ಓದದೆ, ಒಂದು ಫೀಚರ್ ಫೈಲ್ (feature file) ಏನನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ವಿವರಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ವ್ಯವಹಾರದ ಪಾಲುದಾರರು (business stakeholders) ಪರೀಕ್ಷೆಗಳನ್ನು ಓದಬೇಕೆಂಬ ಕಾರಣಕ್ಕಾಗಿ ಅನೇಕ ತಂಡಗಳು BDD ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುತ್ತವೆ. ನಂತರ, ಆ ಪಾಲುದಾರರು ಓದುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತಾರೆ. ಅಂತಿಮವಾಗಿ ನೀವು ನಿರ್ವಹಣೆಯ ತಲೆನೋವನ್ನು (maintenance nightmare) ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ.

BDD ಬಗ್ಗೆ ಇಲ್ಲಿ ಮೂರು ಸತ್ಯಗಳಿವೆ.

𝟭. 𝗚𝗵𝗲𝗿𝗸𝗶𝗻 ಎಂಬುದು ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಲ್ಲ

Gherkin ನಲ್ಲಿ ಟೆಸ್ಟ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ನಿಮ್ಮ ಸನ್ನಿವೇಶಗಳು (scenarios) ಪ್ರತಿಯೊಂದು ಕ್ಲಿಕ್ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಫೀಲ್ಡ್ ಅನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತಿದ್ದರೆ, ನೀವು ಅದನ್ನು ತಪ್ಪಾಗಿ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ.

ಕೆಟ್ಟ Gherkin:

  • Given the user enters email "test@example.com"
  • And the user enters password "Password123!"
  • And the user clicks "Place Order"

ಉತ್ತಮ Gherkin:

  • Given the user has items ready to purchase
  • When the user pays with a valid credit card
  • Then the order is confirmed

"ಹೇಗೆ" (how) ಎಂಬುದು ನಿಮ್ಮ step definitions ನಲ್ಲಿ ಇರುತ್ತದೆ. "ಏನು" (what) ಎಂಬುದು ನಿಮ್ಮ feature files ನಲ್ಲಿ ಇರುತ್ತದೆ. ನಿಮ್ಮ feature files ಸರಳವಾಗಿರಲಿ, ಇದರಿಂದ ಉತ್ಪನ್ನ ವ್ಯವಸ್ಥಾಪಕರು (product manager) ಅವುಗಳನ್ನು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಓದಬಹುದು.

𝟮. 𝗦𝘁𝗲𝗽 𝗱𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻𝘀 ಎಂಬುದು 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗴𝗿𝗮𝗽𝗵 ಅಲ್ಲ

ಒಂದು step definition ಮತ್ತೊಂದು step definition ಅನ್ನು ಇಂಪೋರ್ಟ್ (import) ಮಾಡದಂತೆ ನೋಡಿಕೊಳ್ಳಿ. ಇದು ಗೊಂದಲಮಯ ಜಾಲವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಒಂದು ಹಂತವು ವಿಫಲವಾದರೆ, ಅದು ಇಡೀ ಸ್ಥಿತಿಯನ್ನು (state) ಹಾಳುಮಾಡುತ್ತದೆ.

ಪರಿಹಾರ ಸರಳವಾಗಿದೆ:

  • ನಿಮ್ಮ page objects ಗಳನ್ನು ನಿಮ್ಮ step definitions ನಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ.
  • ಹಂಚಿಕೆಯ ಡೊಮೇನ್ ಲೇಯರ್ (shared domain layer) ಅನ್ನು ಬಳಸಿ.
  • Step definitions ಎಂಬುದು ಡೊಮೇನ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಕರೆಯುವ ತೆಳುವಾದ ವ್ರ್ಯಾಪ್ಪರ್‌ಗಳಾಗಿರಲಿ (thin wrappers).

ಇದು ನಿಮ್ಮ ಹಂತಗಳನ್ನು ಸ್ಟೇಟ್‌ಲೆಸ್ (stateless) ಮಾಡುತ್ತದೆ. ಉಳಿದ ಎಲ್ಲಾ ಸನ್ನಿವೇಶಗಳನ್ನು ಹಾಳುಮಾಡದೆ ನೀವು ನಿಮ್ಮ ಕೋಡ್‌ನ ಒಂದು ಭಾಗವನ್ನು ಬದಲಾಯಿಸಬಹುದು.

𝟯. 𝗕𝗗𝗗 ಎಂಬುದು ಒಂದು 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗽𝗿𝗼𝗷𝗲𝗰𝘁

BDD ಎಂಬುದು ಕೇವಲ ಪರೀಕ್ಷೆಯಲ್ಲ, ಅದು ಸಂವಹನದ ಬಗ್ಗೆಯಾಗಿದೆ. ಪರೀಕ್ಷೆಗಳು ಅದರ ಒಂದು ಪರಿಣಾಮ (side effect) ಅಷ್ಟೆ.

ನೀವು ಕೇವಲ ಟೆಸ್ಟ್ ಕವರೇಜ್ ಅಥವಾ ಕಾರ್ಯಗತಗೊಳಿಸುವ ವೇಗಕ್ಕಾಗಿ (execution speed) ಮಾತ್ರ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದರೆ, ನೀವು ಮುಖ್ಯ ಗುರಿಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಒಬ್ಬ ಹೊಸ ಎಂಜಿನಿಯರ್ ಮೊದಲು ಓದಬೇಕಾದದ್ದು ನಿಮ್ಮ feature files ಆಗಿರಬೇಕು.

ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ನಿಮ್ಮ feature files ಅನ್ನು ಓದಿದ ನಂತರ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನಿಮ್ಮ BDD suite ವಿಫಲವಾಗಿದೆ ಎಂದರ್ಥ.

𝗡𝗮𝘃𝗮𝗹ೆ ಏನು ಮಾಡಬೇಕು:

  • ನಿಮ್ಮ ಅತ್ಯಂತ ಕಳಪೆ feature file ಅನ್ನು ಆರಿಸಿ.
  • ಸನ್ನಿವೇಶಗಳನ್ನು ಮೂರುದಿಂದ ಐದು ಸಾಲುಗಳವರೆಗೆ ಇರುವಂತೆ ಮರುಬರೆಯಿರಿ.
  • ಡೇಟಾವನ್ನು step definitions ಅಥವಾ factories ಗೆ ವರ್ಗಾಯಿಸಿ.
  • step-to-step ಇಂಪೋರ್ಟ್‌ಗಳ ಬದಲಿಗೆ ಡೊಮೇನ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಬಳಸಿ.

ಕೇವಲ ನಿಮ್ಮ feature files ಬಳಸಿ ಐದು ನಿಮಿಷಗಳಲ್ಲಿ ಹೊಸ ಉದ್ಯೋಗಿಗೆ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ವಿವರಿಸಬಲ್ಲಿರಾ? ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಮರುಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿ.

ನಿಮ್ಮ Cucumber suite ನಿರ್ವಹಣಾ ದುಸ್ತರವಾಗುವ (maintenance nightmare) ಮೊದಲು BDD ಬಗ್ಗೆ ಯಾರೂ ನಿಮಗೆ ಹೇಳದ 3 ವಿಷಯಗಳು

BDD (Behavior-Driven Development) ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುಧಾರಿಸುವ ಒಂದು ಮ್ಯಾಜಿಕ್ ಪರಿಹಾರವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಆದರೆ, ಸರಿಯಾದ ಮಾರ್ಗದರ್ಶನವಿಲ್ಲದೆ, ಇದು ನಿಮ್ಮ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷಾ (automated testing) ಪ್ರಕ್ರಿಯೆಯನ್ನೇ ಒಂದು ದೊಡ್ಡ ತಲೆನೋವಾಗಿ ಪರಿವರ್ತಿಸಬಹುದು.

ನಿಮ್ಮ Cucumber suite ನಿರ್ವಹಣೆಗೆ ಕಷ್ಟವಾಗುವ ಮೊದಲು ನೀವು ತಿಳಿದುಕೊಳ್ಳಲೇಬೇಕಾದ 3 ಪ್ರಮುಖ ವಿಷಯಗಳು ಇಲ್ಲಿವೆ:

1. The Gherkin Trap (Gherkin ಬಲೆ)

ಅನೇಕರು Feature filesಗಳಲ್ಲಿ ಅತಿಯಾದ ವಿವರಗಳನ್ನು ಬರೆಯಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. Gherkin ಭಾಷೆಯು ಮಾನವನಿಗೆ ಓದಲು ಸುಲಭವಾಗುವಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಆದರೆ ನೀವು ಪ್ರತಿಯೊಂದು ಸಣ್ಣ ವಿವರವನ್ನೂ (implementation details) ಅಲ್ಲಿ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ನಿಮ್ಮ Feature files ಅತ್ಯಂತ ದೀರ್ಘ ಮತ್ತು ನಿರ್ವಹಣೆಗೆ ಕಷ್ಟವಾಗುವಂತಾಗುತ್ತವೆ.

ಯಾವಾಗ ನೀವು "ಏನು" (What) ನಡೆಯಬೇಕು ಎಂಬುದಕ್ಕಿಂತ "ಹೇಗೆ" (How) ನಡೆಯಬೇಕು ಎಂಬುದನ್ನು ಬರೆಯಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರೋ, ಆಗ ನೀವು ಈ ಬಲೆಯಲ್ಲಿ ಸಿಲುಕುತ್ತೀರಿ. Feature files ಗಳು ವ್ಯವಹಾರದ ತರ್ಕವನ್ನು (business logic) ವಿವರಿಸಬೇಕೇ ಹೊರತು, ಸಾಫ್ಟ್‌ವೇರ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬ ತಾಂತ್ರಿಕ ವಿವರಗಳನ್ನಲ್ಲ.

2. Step Definition Bloat (Step Definition ಅತಿಯಾಗುವುದು)

ನೀವು Feature filesಗಳಲ್ಲಿ ಹೆಚ್ಚು ವಿವರಗಳನ್ನು ಸೇರಿಸಿದಂತೆಲ್ಲಾ, ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ step definitions ಕೂಡ ಹೆಚ್ಚಾಗುತ್ತಾ ಹೋಗುತ್ತವೆ. ಇದು ಅಂತಿಮವಾಗಿ ಸಾವಿರಾರು ಸಾಲುಗಳ Step definitions ಗೂ ಮತ್ತು ಅವುಗಳ ನಡುವೆ ಗೊಂದಲಮಯವಾದ ಸಂಬಂಧಗಳಿಗೂ ಕಾರಣವಾಗುತ್ತದೆ.

ಇದರಿಂದಾಗಿ ಹೊಸ stepಗಳನ್ನು ಸೇರಿಸುವುದು ಅಥವಾ ಹಳೆಯವುಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ಅತ್ಯಂತ ಕಷ್ಟವಾಗುತ್ತದೆ. ಇದು ನಿಮ್ಮ ಪರೀಕ್ಷಾ ಕೋಡ್ ಅನ್ನು ಅಸ್ತವ್ಯಸ್ತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ ನಿಮ್ಮ ಪರೀಕ್ಷಾ ಸುಟ್‌ (test suite) ಅನ್ನು ನಿರ್ವಹಿಸಲಾಗದ ಸ್ಥಿತಿಗೆ ತರುತ್ತದೆ.

3. The "Testing vs. Documentation" Confusion (ಪರೀಕ್ಷೆ ಮತ್ತು ದಾಖಲಾತಿ ನಡುವಿನ ಗೊಂದಲ)

BDD ನ ಮುಖ್ಯ ಉದ್ದೇಶ ವ್ಯವಹಾರದ ತಂಡ (Business team) ಮತ್ತು ತಾಂತ್ರಿಕ ತಂಡದ (Technical team) ನಡುವೆ ಸಂವಹನವನ್ನು ಸುಧಾರಿಸುವುದು. ಆದರೆ ಅನೇಕರು BDD ಅನ್ನು ಕೇವಲ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯುವ ಒಂದು ವಿಧಾನವೆಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸುತ್ತಾರೆ.

ನೀವು ಕೇವಲ ಪರೀಕ್ಷೆಗಾಗಿ (Testing) ಮಾತ್ರ BDD ಬಳಸುತ್ತಿದ್ದರೆ, ನೀವು ಅದರ ನಿಜವಾದ ಶಕ್ತಿಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ. BDD ಎಂಬುದು ಕೇವಲ ಪರೀಕ್ಷೆಯ ಸಾಧನವಲ್ಲ, ಅದು ಒಂದು ಸಂವಹನ ವಿಧಾನವಾಗಿದೆ (communication tool). ಇದು ಎಲ್ಲರೂ ಒಂದೇ ರೀತಿಯ ನಿರೀಕ್ಷೆಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

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

Optional learning community: https://t.me/GyaanSetuAi