𝟯 BDD-യെ കുറിച്ച് ആരും നിങ്ങളോട് പറയാത്ത 3 കാര്യങ്ങൾ

നിങ്ങളുടെ Cucumber suite പ്രവർത്തിക്കാൻ നാൽപ്പത് മിനിറ്റ് എടുക്കുന്നു. കോഡിന്റെ പല പാളികൾ പരിശോധിക്കാതെ ഒരു ഫീച്ചർ ഫയലും (feature file) എന്താണ് പരിശോധിക്കുന്നതെന്ന് നിങ്ങൾക്ക് വിശദീകരിക്കാൻ കഴിയില്ല.

ബിസിനസ് സ്റ്റേക്ക്‌ഹോൾഡർമാർക്ക് (business stakeholders) ടെസ്റ്റുകൾ വായിക്കേണ്ടതുണ്ട് എന്നതുകൊണ്ടാണ് പല ടീമുകളും BDD സ്വീകരിക്കുന്നത്. എന്നാൽ പിന്നീട്, ആ സ്റ്റേക്ക്‌ഹോൾഡർമാർ അത് വായിക്കുന്നത് നിർത്തുന്നു. അവസാനം ഇത് പരിപാലിക്കാൻ പ്രയാസമുള്ള ഒരു അവസ്ഥയിലേക്ക് (maintenance nightmare) നിങ്ങൾ എത്തിച്ചേരുന്നു.

BDD-യെ കുറിച്ചുള്ള മൂന്ന് സത്യങ്ങൾ ഇതാ.

𝟭. Gherkin ഒരു പ്രോഗ്രാമിംഗ് ഭാഷയല്ല

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 ലളിതമായി സൂക്ഷിക്കുക.

𝟮. Step definitions ഒരു dependency graph അല്ല

ഒരു step definition മറ്റൊരു step definition-നെ ഇംപോർട്ട് ചെയ്യാൻ അനുവദിക്കരുത്. ഇത് സങ്കീർണ്ണമായ ഒരു വല പോലെയാകും. ഒരു സ്റ്റെപ്പ് പരാജയപ്പെട്ടാൽ, അത് മുഴുവൻ സ്റ്റേറ്റിനെയും (state) ബാധിക്കും.

പരിഹാരം ലളിതമാണ്:

  • നിങ്ങളുടെ page objects-നെ step definitions-ൽ നിന്ന് വേർതിരിക്കുക.
  • ഒരു shared domain layer ഉപയോഗിക്കുക.
  • domain objects-നെ വിളിക്കുന്ന ലളിതമായ wrappers ആയിരിക്കണം step definitions.

ഇത് നിങ്ങളുടെ സ്റ്റെപ്പുകളെ stateless ആക്കുന്നു. മറ്റേതെങ്കിലും സിനാരിയോകളെ ബാധിക്കാതെ തന്നെ കോഡിന്റെ ഒരു ഭാഗം മാറ്റാൻ നിങ്ങൾക്ക് സാധിക്കും.

𝟯. BDD ഒരു ഡോക്യുമെന്റേഷൻ പ്രോജക്റ്റാണ്

BDD എന്നത് ആശയവിനിമയത്തെക്കുറിച്ചാണ്, വെറും ടെസ്റ്റിംഗിനെക്കുറിച്ച് മാത്രമല്ല. ടെസ്റ്റുകൾ അതിന്റെ ഒരു അനുബന്ധ ഫലം (side effect) മാത്രമാണ്.

നിങ്ങൾ ടെസ്റ്റ് കവറേജ് (test coverage) അല്ലെങ്കിൽ എക്സിക്യൂഷൻ സ്പീഡ് (execution speed) എന്നിവയ്ക്ക് വേണ്ടി മാത്രം ശ്രമിച്ചാൽ, അതിന്റെ പ്രധാന ലക്ഷ്യം നിങ്ങൾക്ക് നഷ്ടപ്പെടും. നിങ്ങളുടെ സിസ്റ്റം മനസ്സിലാക്കാൻ ഒരു പുതിയ എഞ്ചിനീയർ ആദ്യം വായിക്കേണ്ടത് നിങ്ങളുടെ feature files ആയിരിക്കണം.

നിങ്ങളുടെ feature files വായിച്ചാൽ ഒരാൾക്ക് നിങ്ങളുടെ സിസ്റ്റം മനസ്സിലാക്കാൻ കഴിയില്ലെങ്കിൽ, നിങ്ങളുടെ BDD suite പരാജയപ്പെട്ടു എന്നാണ് അർത്ഥം.

𝗪𝗵𝗮𝘁 𝘁𝗼 𝗱𝗼 𝘁𝗼𝗺𝗼𝗿𝗿𝗼𝘄:

  • ഏറ്റവും മോശമായ നിങ്ങളുടെ ഒരു feature file തിരഞ്ഞെടുക്കുക.
  • സിനാരിയോകൾ മൂന്ന് മുതൽ അഞ്ച് വരികൾ വരെ മാത്രം ദൈർഘ്യമുള്ളതാക്കി മാറ്റുക.
  • ഡാറ്റകൾ step definitions അല്ലെങ്കിൽ factories-ലേക്ക് മാറ്റുക.
  • step-to-step ഇംപോർട്ടുകൾക്ക് പകരം domain objects ഉപയോഗിക്കുക.

നിങ്ങളുടെ feature files മാത്രം ഉപയോഗിച്ച് അഞ്ച് മിനിറ്റിനുള്ളിൽ ഒരു പുതിയ ജീവനക്കാരന് നിങ്ങളുടെ സിസ്റ്റം വിശദീകരിച്ചു കൊടുക്കാൻ നിങ്ങൾക്ക് കഴിയുമോ? ഇല്ലെങ്കിൽ, മാറ്റങ്ങൾ വരുത്തി എഴുതി തുടങ്ങുക.

നിങ്ങളുടെ Cucumber suite ഒരു മെയിന്റനൻസ് ദുരന്തമായി മാറുന്നതിന് മുമ്പ് BDD-യെ കുറിച്ച് ആരും നിങ്ങളോട് പറയാത്ത 3 കാര്യങ്ങൾ

സാങ്കേതിക വിദഗ്ധരും (technical stakeholders) സാങ്കേതികമല്ലാത്തവരും തമ്മിലുള്ള അകലം കുറയ്ക്കുന്നതിനുള്ള ഒരു പരിഹാരമായാണ് BDD (Behavior-Driven Development)-നെ പലപ്പോഴും കാണുന്നത്. ലിവിംഗ് ഡോക്യുമെന്റേഷൻ (living documentation), മെച്ചപ്പെട്ട സഹകരണം, കൂടുതൽ അർത്ഥവത്തായ ടെസ്റ്റുകൾ എന്നിവയാണ് ഇത് വാഗ്ദാനം ചെയ്യുന്നത്. എന്നാൽ ഇതിന് ഒരു ഇരുണ്ട വശമുണ്ട്.

നിങ്ങളുടെ Cucumber suite ഒരു മെയിന്റനൻസ് ദുരന്തമായി മാറുന്നതിന് മുമ്പ് ശ്രദ്ധിക്കേണ്ട മൂന്ന് കാര്യങ്ങൾ താഴെ പറയുന്നവയാണ്:

1. "ലിവിംഗ് ഡോക്യുമെന്റേഷൻ" എന്നത് ഒരു കള്ളമാണ് (നിങ്ങൾ അതിനായി പരിശ്രമിച്ചില്ലെങ്കിൽ മാത്രം)

ഫീച്ചർ ഫയലുകൾ ബിസിനസ് ആവശ്യങ്ങൾക്കായുള്ള കൃത്യമായ വിവരങ്ങൾ (source of truth) സ്വയമേവ നൽകുമെന്ന് കരുതിയാണ് പല ടീമുകളും BDD സ്വീകരിക്കുന്നത്. എന്നാൽ നിരന്തരമായ പരിപാലനം (maintenance) ഇല്ലെങ്കിൽ, ഈ ഫയലുകൾ പെട്ടെന്ന് കാലഹരണപ്പെടുകയും തെറ്റായ വിവരങ്ങൾ നൽകുകയും ചെയ്യും, ഒടുവിൽ അവ ഉപയോഗശൂന്യമായി മാറും. ഡോക്യുമെന്റേഷൻ എന്നത് ഒരു ഉൽപ്പന്നമല്ല, മറിച്ച് അത് നിരന്തരം പരിപാലിക്കേണ്ട ഒരു പ്രക്രിയയാണ്.

2. സ്റ്റെപ്പ് ഡെഫനിഷനുകളുടെ (Step Definition) അമിത വർദ്ധനവ്

നിങ്ങളുടെ ടെസ്റ്റ് സ്യൂട്ട് വളരുന്നതിനനുസരിച്ച്, നൂറുകണക്കിന് ചെറിയ സ്റ്റെപ്പ് ഡെഫനിഷനുകൾ എഴുതേണ്ടി വന്നേക്കാം. ഇത് നിയന്ത്രിക്കാൻ കഴിയാത്തവിധം വലിയൊരു കോഡ്ബേസ് ഉണ്ടാകാൻ കാരണമാകും, അവിടെ ശരിയായ സ്റ്റെപ്പ് കണ്ടെത്തുക എന്നത് ഒരു വലിയ ജോലിയായി മാറും. വളരെ ചെറിയ (granular) സ്റ്റെപ്പുകൾ ഒഴിവാക്കി, കൂടുതൽ പൊതുവായ (reusable) സ്റ്റെപ്പുകൾ ഉപയോഗിക്കാൻ ശ്രദ്ധിക്കണം.

3. BDD എന്നത് ഒരു ടെസ്റ്റിംഗ് ടൂൾ അല്ല; അതൊരു ആശയവിനിമയ ഉപാധിയാണ് (communication tool)

നിങ്ങൾ Gherkin ഉപയോഗിച്ച് ടെസ്റ്റ് കേസുകൾ എഴുതാൻ മാത്രമാണ് ശ്രമിക്കുന്നതെങ്കിൽ, നിങ്ങൾ അത് തെറ്റായ രീതിയിലാണ് ചെയ്യുന്നത്. BDD-യുടെ യഥാർത്ഥ മൂല്യം കോഡ് എഴുതുന്നതിന് മുമ്പ് നടക്കുന്ന ചർച്ചകളിലാണ് അടങ്ങിയിരിക്കുന്നത്. ബിസിനസ് ആവശ്യങ്ങളും സാങ്കേതിക പരിമിതികളും തമ്മിലുള്ള സംവാദം നടക്കുന്നുണ്ടെങ്കിൽ മാത്രമേ BDD വിജയിക്കുകയുള്ളൂ.

ചുരുക്കത്തിൽ: BDD ഒരു ഭാരമായി മാറാൻ അനുവദിക്കരുത്. ഗുണനിലവാരമുള്ള ആശയവിനിമയത്തിലും പരിപാലിക്കാൻ എളുപ്പമുള്ള സ്റ്റെപ്പ് ഡെഫനിഷനുകളിലും ശ്രദ്ധ കേന്ദ്രീകരിക്കുക.