BDD பற்றி யாரும் உங்களுக்குச் சொல்லாத 3 விஷயங்கள்

உங்கள் Cucumber suite இயங்குவதற்கு நாற்பது நிமிடங்கள் ஆகிறது. குறியீட்டின் (code) பல அடுக்குகளைப் படிக்காமல், ஒரு feature file எதைச் சோதிக்கிறது என்பதை உங்களால் விளக்க முடியாது.

வணிகப் பங்குதாரர்கள் (business stakeholders) சோதனைகளைப் படிக்க வேண்டும் என்பதற்காகப் பல குழுக்கள் BDD முறையைப் பின்பற்றுகின்றன. பின்னர், அந்தப் பங்குதாரர்கள் படிப்பதை நிறுத்திவிடுகிறார்கள். இறுதியில், அது பராமரிப்பிற்குப் பெரும் சுமையாக (maintenance nightmare) மாறிவிடுகிறது.

BDD பற்றிய மூன்று உண்மைகள் இதோ.

1. Gherkin என்பது ஒரு நிரலாக்க மொழி (programming language) அல்ல

Gherkin-இல் test scripts எழுதுவதை நிறுத்துங்கள். உங்கள் scenarios ஒவ்வொன்றையும் கிளிக் செய்வதையும், ஒவ்வொரு புலத்தையும் (field) பட்டியலிட்டால், நீங்கள் அதைத் தவறாகச் செய்கிறீர்கள் என்று அர்த்தம்.

தவறான 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-இல் இருக்கும். ஒரு தயாரிப்பு மேலாளர் (product manager) சில நொடிகளில் அவற்றைப் படிக்கும் வகையில் உங்கள் feature files-ஐ எளிமையாக வைத்திருங்கள்.

2. Step definitions என்பவை ஒரு dependency graph அல்ல

ஒரு step definition மற்றொன்றை import செய்ய அனுமதிக்காதீர்கள். இது ஒரு சிக்கலான வலைப்பின்னலை (tangled web) உருவாக்கும். ஒரு படி (step) தோல்வியடைந்தால், அது முழு நிலையைப்பற்றியும் (entire state) பாதிக்கும்.

தீர்வு எளிது:

  • உங்கள் page objects-ஐ step definitions-லிருந்து தனித்தனியாகப் பிரியுங்கள்.
  • ஒரு பகிரப்பட்ட domain layer-ஐப் பயன்படுத்துங்கள்.
  • Step definitions என்பவை domain objects-ஐ அழைக்கும் மெல்லிய உறைகவசங்களாக (thin wrappers) இருக்க வேண்டும்.

இது உங்கள் படிநிலைகளை stateless ஆக மாற்றும். மற்ற எல்லா scenarios-களையும் பாதிக்காமல் உங்கள் குறியீட்டின் ஒரு பகுதியை மட்டும் மாற்ற முடியும்.

3. BDD என்பது ஒரு ஆவணப்படுத்தல் திட்டம் (documentation project)

BDD என்பது வெறும் சோதனை (testing) பற்றியது மட்டுமல்ல, அது தகவல் தொடர்பு (communication) பற்றியது. சோதனைகள் என்பது அதன் ஒரு துணை விளைவு (side effect) மட்டுமே.

நீங்கள் test coverage அல்லது இயங்கும் வேகத்திற்காக (execution speed) மட்டும் மேம்படுத்தினால், உங்கள் முக்கிய இலக்கை இழந்துவிடுவீர்கள். உங்கள் அமைப்பைப் (system) புரிந்துகொள்ள ஒரு புதிய பொறியாளர் முதலில் படிக்க வேண்டிய விஷயமாக உங்கள் feature files இருக்க வேண்டும்.

ஒரு நபர் உங்கள் feature files-ஐப் படிப்பதன் மூலம் உங்கள் அமைப்பைப் புரிந்துகொள்ள முடியாவிட்டால், உங்கள் BDD suite தோல்வியடைந்துவிட்டது என்று அர்த்தம்.

நாளை நீங்கள் செய்ய வேண்டியவை:

  • உங்கள் மிக மோசமான feature file-ஐத் தேர்ந்தெடுங்கள்.
  • Scenarios-களை மூன்று முதல் ஐந்து வரிகள் நீளத்திற்கு மாற்றி எழுதுங்கள்.
  • தரவுகளை (data) step definitions அல்லது factories-க்குள் நகர்த்துங்கள்.
  • Step-to-step imports-க்கு பதிலாக domain objects-ஐப் பயன்படுத்துங்கள்.

உங்கள் feature files-ஐ மட்டும் பயன்படுத்தி, ஐந்து நிமிடங்களில் ஒரு புதிய பணியாளருக்கு (new hire) உங்கள் அமைப்பைப் பற்றி விளக்க முடியுமா? முடியாவிட்டால், மாற்றி எழுதத் தொடங்குங்கள்.

மூலம்: https://dev.to/qawalah/3-things-nobody-tells-you-about-bdd-before-your-cucumber-suite-becomes-a-maintenance-nightmare-9c7

விருப்பத்தேர்வு கற்றல் சமூகம்: https://t.me/GyaanSetuAi