ஜாவாஸ்கிரிப்டில் சோதனை-உந்துதல் மேம்பாடு: உலகளாவிய டெவலப்பர்களுக்கான ஒரு விரிவான வழிகாட்டி

இந்தக் காட்சியை கற்பனை செய்து பாருங்கள்: ஒரு பெரிய, பழைய அமைப்பில் (legacy system) ஒரு முக்கியமான குறியீட்டுப் பகுதியை மாற்றியமைக்கும் பணி உங்களுக்கு வழங்கப்படுகிறது. உங்களுக்கு ஒருவித அச்ச உணர்வு ஏற்படுகிறது. உங்கள் மாற்றம் வேறு எதையாவது பாதிக்குமா? கணினி இன்னும் நோக்கம் கொண்டபடி செயல்படுகிறதா என்பதை நீங்கள் எப்படி உறுதியாக நம்ப முடியும்? மாற்றத்தைப் பற்றிய இந்த பயம் மென்பொருள் மேம்பாட்டில் ஒரு பொதுவான பிரச்சனையாகும், இது பெரும்பாலும் மெதுவான முன்னேற்றம் மற்றும் பலவீனமான பயன்பாடுகளுக்கு வழிவகுக்கிறது. ஆனால், மென்பொருளை நம்பிக்கையுடன் உருவாக்க ஒரு வழி இருந்தால், பிழைகள் உற்பத்திக்கு வருவதற்கு முன்பே அவற்றைப் பிடிக்கும் ஒரு பாதுகாப்பு வலையை உருவாக்கினால் என்ன செய்வது? இதுதான் சோதனை-உந்துதல் மேம்பாட்டின் (Test-Driven Development - TDD) வாக்குறுதியாகும்.

TDD என்பது ஒரு சோதனை நுட்பம் மட்டுமல்ல; இது மென்பொருள் வடிவமைப்பு மற்றும் மேம்பாட்டிற்கான ஒரு ஒழுங்குபடுத்தப்பட்ட அணுகுமுறையாகும். இது பாரம்பரியமான "குறியீட்டை எழுது, பிறகு சோதனை செய்" என்ற மாதிரியைத் தலைகீழாக மாற்றுகிறது. TDD உடன், உற்பத்தி குறியீட்டை எழுதுவதற்கு முன்பு தோல்வியடையும் ஒரு சோதனையை நீங்கள் எழுதுகிறீர்கள். இந்த எளிய தலைகீழ் மாற்றம் குறியீட்டின் தரம், வடிவமைப்பு மற்றும் பராமரிப்பு ஆகியவற்றில் ஆழமான தாக்கங்களை ஏற்படுத்துகிறது. இந்த வழிகாட்டி, தொழில்முறை டெவலப்பர்களின் உலகளாவிய பார்வையாளர்களுக்காக வடிவமைக்கப்பட்ட, ஜாவாஸ்கிரிப்டில் TDD-ஐ செயல்படுத்துவதற்கான ஒரு விரிவான, நடைமுறைப் பார்வையை வழங்கும்.

சோதனை-உந்துதல் மேம்பாடு (TDD) என்றால் என்ன?

அதன் மையத்தில், சோதனை-உந்துதல் மேம்பாடு என்பது மிகக் குறுகிய மேம்பாட்டுச் சுழற்சியின் மறுசெய்கையை நம்பியிருக்கும் ஒரு மேம்பாட்டு செயல்முறையாகும். அம்சங்களை எழுதிவிட்டுப் பிறகு அவற்றைச் சோதிப்பதற்குப் பதிலாக, முதலில் சோதனை எழுதப்பட வேண்டும் என்று TDD வலியுறுத்துகிறது. இந்த சோதனை தவிர்க்க முடியாமல் தோல்வியடையும், ஏனெனில் அந்த அம்சம் இன்னும் உருவாக்கப்படவில்லை. பின்னர் டெவலப்பரின் வேலை, அந்த குறிப்பிட்ட சோதனையில் தேர்ச்சி பெற சாத்தியமான எளிய குறியீட்டை எழுதுவதாகும். அது தேர்ச்சி பெற்றவுடன், குறியீடு சுத்தம் செய்யப்பட்டு மேம்படுத்தப்படுகிறது. இந்த அடிப்படைக் கண்ணி "ரெட்-கிரீன்-ரீஃபாக்டர்" (Red-Green-Refactor) சுழற்சி என்று அழைக்கப்படுகிறது.

TDD-இன் தாளம்: ரெட்-கிரீன்-ரீஃபாக்டர்

இந்த மூன்று-படி சுழற்சி TDD-இன் இதயத் துடிப்பாகும். இந்தத் தாளத்தைப் புரிந்துகொண்டு பயிற்சி செய்வது இந்த நுட்பத்தில் தேர்ச்சி பெறுவதற்கு அடிப்படையானது.

• 🔴 சிவப்பு — ஒரு தோல்வியடையும் சோதனையை எழுதுங்கள்: ஒரு புதிய செயல்பாட்டிற்கான தானியங்கு சோதனையை எழுதுவதன் மூலம் நீங்கள் தொடங்குகிறீர்கள். இந்தச் சோதனை, குறியீடு என்ன செய்ய வேண்டும் என்பதை வரையறுக்க வேண்டும். நீங்கள் இன்னும் எந்தவொரு செயல்படுத்தல் குறியீட்டையும் எழுதாததால், இந்தச் சோதனை தோல்வியடைவது உறுதி. தோல்வியடைந்த சோதனை ஒரு பிரச்சனை அல்ல; அது ஒரு முன்னேற்றம். சோதனை சரியாக வேலை செய்கிறது (அது தோல்வியடையக்கூடும்) என்பதை இது நிரூபிக்கிறது மற்றும் அடுத்த கட்டத்திற்கு தெளிவான, உறுதியான இலக்கை அமைக்கிறது.
• 🟢 பச்சை — தேர்ச்சி பெற எளிய குறியீட்டை எழுதுங்கள்: இப்போது உங்கள் இலக்கு ஒன்றே ஒன்றுதான்: சோதனையில் தேர்ச்சி பெற வைப்பது. சோதனையை சிவப்பிலிருந்து பச்சைக்கு மாற்றத் தேவையான மிகக் குறைந்த அளவிலான உற்பத்தி குறியீட்டை நீங்கள் எழுத வேண்டும். இது உள்ளுணர்வுக்கு முரணாக உணரப்படலாம்; குறியீடு நேர்த்தியாகவோ அல்லது திறமையாகவோ இல்லாமல் இருக்கலாம். அது பரவாயில்லை. இங்கு கவனம் செலுத்துவது சோதனையால் வரையறுக்கப்பட்ட தேவையை நிறைவேற்றுவதில் மட்டுமே.
• 🔵 ரீஃபாக்டர் — குறியீட்டை மேம்படுத்துங்கள்: இப்போது உங்களிடம் தேர்ச்சி பெற்ற சோதனை இருப்பதால், உங்களுக்கு ஒரு பாதுகாப்பு வலை உள்ளது. செயல்பாட்டை உடைத்துவிடுவோம் என்ற பயமின்றி உங்கள் குறியீட்டை நம்பிக்கையுடன் சுத்தம் செய்து மேம்படுத்தலாம். இங்குதான் நீங்கள் குறியீட்டுத் தவறுகளை (code smells) சரிசெய்கிறீர்கள், நகல்களை நீக்குகிறீர்கள், தெளிவை மேம்படுத்துகிறீர்கள் மற்றும் செயல்திறனை மேம்படுத்துகிறீர்கள். ரீஃபாக்டரிங் செய்யும் போது எந்த நேரத்திலும் உங்கள் டெஸ்ட் தொகுப்பை இயக்கி, நீங்கள் எந்தப் பின்னடைவுகளையும் ஏற்படுத்தவில்லை என்பதை உறுதிப்படுத்திக் கொள்ளலாம். ரீஃபாக்டரிங் செய்த பிறகும், அனைத்து சோதனைகளும் பச்சையாகவே இருக்க வேண்டும்.

ஒரு சிறிய செயல்பாட்டிற்கான சுழற்சி முடிந்ததும், அடுத்த பகுதிக்கு ஒரு புதிய தோல்வியுறும் சோதனையுடன் மீண்டும் தொடங்குகிறீர்கள்.

TDD-இன் மூன்று விதிகள்

ஏஜைல் மென்பொருள் இயக்கத்தில் ஒரு முக்கிய நபரான ராபர்ட் சி. மார்ட்டின் ('அங்கிள் பாப்' என்று அழைக்கப்படுபவர்), TDD ஒழுக்கத்தை முறைப்படுத்தும் மூன்று எளிய விதிகளை வரையறுத்தார்:

1. தோல்வியடையும் ஒரு யூனிட் சோதனையில் தேர்ச்சி பெறச் செய்வதற்காக அன்றி, வேறு எந்த உற்பத்தி குறியீட்டையும் நீங்கள் எழுதக்கூடாது.
2. ஒரு யூனிட் சோதனையைத் தோல்வியடையச் செய்வதற்குப் போதுமானதை விட அதிகமாக நீங்கள் எழுதக்கூடாது; மற்றும் கம்பைல் தோல்விகளும் தோல்விகளே.
3. தோல்வியடையும் அந்த ஒரு யூனிட் சோதனையில் தேர்ச்சி பெறப் போதுமானதை விட அதிகமாக உற்பத்தி குறியீட்டை நீங்கள் எழுதக்கூடாது.

இந்த விதிகளைப் பின்பற்றுவது உங்களை ரெட்-கிரீன்-ரீஃபாக்டர் சுழற்சிக்குள் கட்டாயப்படுத்துகிறது மற்றும் உங்கள் உற்பத்தி குறியீடு 100% ஒரு குறிப்பிட்ட, சோதிக்கப்பட்ட தேவையை பூர்த்தி செய்வதற்காக எழுதப்பட்டிருப்பதை உறுதி செய்கிறது.

நீங்கள் ஏன் TDD-ஐ பின்பற்ற வேண்டும்? உலகளாவிய வணிகத்திற்கான காரணம்

TDD தனிப்பட்ட டெவலப்பர்களுக்கு மகத்தான நன்மைகளை வழங்கினாலும், அதன் உண்மையான சக்தி குழு மற்றும் வணிக மட்டத்தில் உணரப்படுகிறது, குறிப்பாக உலகளவில் பரவியுள்ள சூழல்களில்.

• அதிகரித்த நம்பிக்கை மற்றும் வேகம்: ஒரு விரிவான சோதனைத் தொகுப்பு ஒரு பாதுகாப்பு வலையாக செயல்படுகிறது. இது குழுக்கள் புதிய அம்சங்களைச் சேர்க்க அல்லது ஏற்கனவே உள்ளவற்றை நம்பிக்கையுடன் ரீஃபாக்டர் செய்ய அனுமதிக்கிறது, இது உயர்வான நீடித்த மேம்பாட்டு வேகத்திற்கு வழிவகுக்கிறது. நீங்கள் கைமுறை பின்னடைவு சோதனை மற்றும் பிழைத்திருத்தத்தில் குறைந்த நேரத்தையும், மதிப்பு வழங்குவதில் அதிக நேரத்தையும் செலவிடுகிறீர்கள்.
• மேம்படுத்தப்பட்ட குறியீட்டு வடிவமைப்பு: முதலில் சோதனைகளை எழுதுவது உங்கள் குறியீடு எவ்வாறு பயன்படுத்தப்படும் என்பதைப் பற்றி சிந்திக்க உங்களைத் தூண்டுகிறது. உங்கள் சொந்த ஏபிஐ-இன் முதல் நுகர்வோர் நீங்கள்தான். இது இயற்கையாகவே சிறிய, அதிக கவனம் செலுத்தும் தொகுதிகள் மற்றும் தெளிவான பொறுப்புப் பிரிவுகளுடன் சிறந்த வடிவமைக்கப்பட்ட மென்பொருளுக்கு வழிவகுக்கிறது.
• வாழும் ஆவணம் (Living Documentation): வெவ்வேறு நேர மண்டலங்கள் மற்றும் கலாச்சாரங்களில் பணிபுரியும் ஒரு உலகளாவிய குழுவிற்கு, தெளிவான ஆவணம் முக்கியமானது. நன்கு எழுதப்பட்ட சோதனைத் தொகுப்பு என்பது ஒரு வாழும், இயங்கக்கூடிய ஆவணத்தின் வடிவமாகும். ஒரு புதிய டெவலப்பர், ஒரு குறியீட்டுப் பகுதி என்ன செய்ய வேண்டும் மற்றும் அது பல்வேறு சூழ்நிலைகளில் எவ்வாறு செயல்படுகிறது என்பதைத் துல்லியமாகப் புரிந்துகொள்ள சோதனைகளைப் படிக்கலாம். பாரம்பரிய ஆவணங்களைப் போலல்லாமல், இது ஒருபோதும் காலாவதியாகாது.
• குறைக்கப்பட்ட மொத்த உரிமைச் செலவு (TCO): மேம்பாட்டுச் சுழற்சியில் ஆரம்பத்தில் கண்டறியப்படும் பிழைகளை சரிசெய்வது, உற்பத்தியில் காணப்படும் பிழைகளை விட பல மடங்கு மலிவானது. TDD ஒரு வலுவான அமைப்பை உருவாக்குகிறது, இது காலப்போக்கில் பராமரிக்கவும் நீட்டிக்கவும் எளிதானது, இது மென்பொருளின் நீண்ட கால மொத்த உரிமைச் செலவைக் குறைக்கிறது.

உங்கள் ஜாவாஸ்கிரிப்ட் TDD சூழலை அமைத்தல்

ஜாவாஸ்கிரிப்டில் TDD உடன் தொடங்க, உங்களுக்கு சில கருவிகள் தேவை. நவீன ஜாவாஸ்கிரிப்ட் சூழல் அமைப்பு சிறந்த தேர்வுகளை வழங்குகிறது.

ஒரு சோதனை ஸ்டாக்கின் முக்கிய கூறுகள்

• டெஸ்ட் ரன்னர் (Test Runner): உங்கள் சோதனைகளைக் கண்டுபிடித்து இயக்கும் ஒரு நிரல். இது கட்டமைப்பு (`describe` மற்றும் `it` தொகுதிகள் போன்றவை) மற்றும் முடிவுகளை அறிக்கையிடுகிறது. ஜெஸ்ட் (Jest) மற்றும் மோக்கா (Mocha) இரண்டு மிகவும் பிரபலமான தேர்வுகள்.
• உறுதிப்படுத்தல் நூலகம் (Assertion Library): உங்கள் குறியீடு எதிர்பார்த்தபடி செயல்படுகிறதா என்பதைச் சரிபார்க்கும் செயல்பாடுகளை வழங்கும் ஒரு கருவி. இது `expect(result).toBe(true)` போன்ற அறிக்கைகளை எழுத உங்களை அனுமதிக்கிறது. சாய் (Chai) ஒரு பிரபலமான தனித்த நூலகம், அதேசமயம் ஜெஸ்ட் அதன் சொந்த சக்திவாய்ந்த உறுதிப்படுத்தல் நூலகத்தை உள்ளடக்கியுள்ளது.
• மாக் நூலகம் (Mocking Library): ஏபிஐ அழைப்புகள் அல்லது தரவுத்தள இணைப்புகள் போன்ற சார்புகளின் "போலிகளை" உருவாக்க ஒரு கருவி. இது உங்கள் குறியீட்டை தனிமைப்படுத்தி சோதிக்க உங்களை அனுமதிக்கிறது. ஜெஸ்ட் சிறந்த உள்ளமைக்கப்பட்ட மாக் திறன்களைக் கொண்டுள்ளது.

அதன் எளிமை மற்றும் அனைத்தும்-ஒன்றில்-இருக்கும் தன்மைக்காக, நாங்கள் எங்கள் எடுத்துக்காட்டுகளுக்கு ஜெஸ்ட்-ஐப் பயன்படுத்துவோம். "பூஜ்ஜிய-உள்ளமைவு" அனுபவத்தைத் தேடும் குழுக்களுக்கு இது ஒரு சிறந்த தேர்வாகும்.

ஜெஸ்ட் உடன் படிப்படியான அமைப்பு

TDD-க்காக ஒரு புதிய திட்டத்தை அமைப்போம்.

1. உங்கள் திட்டத்தைத் துவக்கவும்: உங்கள் டெர்மினலைத் திறந்து ஒரு புதிய திட்ட கோப்பகத்தை உருவாக்கவும்.

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

              
                Copy
              
            
          

2. ஜெஸ்ட்-ஐ நிறுவவும்: ஜெஸ்ட்டை உங்கள் திட்டத்தில் ஒரு டெவலப்மெண்ட் சார்புநிலையாக சேர்க்கவும்.

            npm install --save-dev jest
            

              
                Copy
              
            
          

3. சோதனை ஸ்கிரிப்ட்டை உள்ளமைக்கவும்: உங்கள் `package.json` கோப்பைத் திறக்கவும். `"scripts"` பகுதியைக் கண்டுபிடித்து `"test"` ஸ்கிரிப்ட்டை மாற்றவும். TDD பணிப்பாய்வுக்கு மிகவும் மதிப்புமிக்க `"test:watch"` ஸ்கிரிப்ட்டையும் சேர்ப்பது மிகவும் பரிந்துரைக்கப்படுகிறது.

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

              
                Copy
              
            
          

`--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', () => {
    // Arrange
    const amount = 10; // 10 USD
    const expected = 9.2; // Assuming a fixed rate of 1 USD = 0.92 EUR

    // Act
    const result = CurrencyConverter.convert(amount, 'USD', 'EUR');

    // Assert
    expect(result).toBe(expected);
  });
});
            

              
                Copy
              
            
          

இப்போது, உங்கள் டெர்மினலிலிருந்து டெஸ்ட் வாட்சரை இயக்கவும்:

            npm run test:watch
            

              
                Copy
              
            
          

சோதனை மிக மோசமாகத் தோல்வியடையும். ஜெஸ்ட் `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;
            

              
                Copy
              
            
          

இந்தக் கோப்பை நீங்கள் சேமித்தவுடன், ஜெஸ்ட் சோதனையை மீண்டும் இயக்கும், அது பச்சை நிறமாக மாறும். சோதனையின் தேவையைப் பூர்த்தி செய்ய மிகக் குறைந்த குறியீட்டை நாங்கள் எழுதியுள்ளோம்.

🔵 ரீஃபாக்டர்: குறியீட்டை மேம்படுத்துங்கள்

குறியீடு எளிமையானது, ஆனால் நாம் ஏற்கனவே மேம்பாடுகளைப் பற்றி சிந்திக்க முடியும். உள்ளமைக்கப்பட்ட `rates` பொருள் சற்று கடினமாக உள்ளது. இப்போதைக்கு, அது போதுமான அளவு சுத்தமாக இருக்கிறது. மிக முக்கியமான விஷயம் என்னவென்றால், ஒரு சோதனையால் பாதுகாக்கப்பட்ட ஒரு வேலை செய்யும் அம்சம் எங்களிடம் உள்ளது. அடுத்த தேவைக்குச் செல்வோம்.

சுழற்சி 2: அறியப்படாத நாணயங்களைக் கையாளுதல்

🔴 சிவப்பு: தவறான நாணயத்திற்கான ஒரு சோதனையை எழுதுங்கள்

நமக்குத் தெரியாத ஒரு நாணயத்திற்கு மாற்ற முயற்சித்தால் என்ன நடக்கும்? அது ஒரு பிழையைத் தூண்ட வேண்டும். இந்த நடத்தையை `CurrencyConverter.test.js` இல் ஒரு புதிய சோதனையில் வரையறுப்போம்.

            // In CurrencyConverter.test.js, inside the describe block

it('should throw an error for unknown currencies', () => {
  // Arrange
  const amount = 10;

  // Act & Assert
  // We wrap the function call in an arrow function for Jest's toThrow to work.
  expect(() => {
    CurrencyConverter.convert(amount, 'USD', 'XYZ');
  }).toThrow('Unknown currency: XYZ');
});
            

              
                Copy
              
            
          

கோப்பை சேமிக்கவும். சோதனை ரன்னர் உடனடியாக ஒரு புதிய தோல்வியைக் காட்டுகிறது. இது சிவப்பு ஏனெனில் நமது குறியீடு ஒரு பிழையைத் தூண்டவில்லை; அது `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]) {
      // Determine which currency is unknown for a better error message
      const unknownCurrency = !rates[from] ? from : to;
      throw new Error(`Unknown currency: ${unknownCurrency}`);
    }
    return amount * rates[from][to];
  }
};

module.exports = CurrencyConverter;
            

              
                Copy
              
            
          

கோப்பை சேமிக்கவும். இரண்டு சோதனைகளும் இப்போது தேர்ச்சி பெறுகின்றன. நாம் மீண்டும் பச்சை நிலைக்கு வந்துவிட்டோம்.

🔵 ரீஃபாக்டர்: அதைச் சுத்தம் செய்யுங்கள்

நமது `convert` செயல்பாடு வளர்ந்து வருகிறது. சரிபார்ப்பு தர்க்கம் கணக்கீட்டுடன் கலக்கப்பட்டுள்ளது. வாசிப்புத்திறனை மேம்படுத்த சரிபார்ப்பை ஒரு தனிப்பட்ட தனி செயல்பாட்டிற்குள் பிரித்தெடுக்கலாம், ஆனால் இப்போதைக்கு, இது இன்னும் நிர்வகிக்கக்கூடியதாக உள்ளது. முக்கிய விஷயம் என்னவென்றால், இந்த மாற்றங்களைச் செய்ய நமக்கு சுதந்திரம் உள்ளது, ஏனென்றால் நாம் எதையாவது உடைத்தால் நமது சோதனைகள் நமக்குத் தெரிவிக்கும்.

சுழற்சி 3: ஒத்திசைவற்ற விகிதப் பெறுதல்

விகிதங்களை ஹார்ட்கோட் செய்வது நடைமுறைக்கு மாறானது. நமது மாட்யூலை ஒரு (போலியான) வெளிப்புற ஏபிஐ-யிலிருந்து விகிதங்களைப் பெறும் வகையில் ரீஃபாக்டர் செய்வோம்.

🔴 சிவப்பு: ஒரு ஏபிஐ அழைப்பைப் போலியாகச் செய்யும் ஒரு ஒத்திசைவற்ற சோதனையை எழுதுங்கள்

முதலில், நமது கன்வர்ட்டரை மறுசீரமைக்க வேண்டும். இது இப்போது நாம் ஒரு ஏபிஐ கிளையண்டுடன் ஒரு கிளாஸ் ஆக இருக்க வேண்டும். நாம் `fetch` ஏபிஐ-ஐ மாக் செய்யவும் வேண்டும். ஜெஸ்ட் இதை எளிதாக்குகிறது.

இந்த புதிய, ஒத்திசைவற்ற யதார்த்தத்திற்கு இடமளிக்க நமது சோதனை கோப்பை மீண்டும் எழுதுவோம். நாம் மீண்டும் மகிழ்ச்சியான பாதையைச் சோதிப்பதன் மூலம் தொடங்குவோம்.

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

// Mock the external dependency
global.fetch = jest.fn();

beforeEach(() => {
  // Clear mock history before each test
  fetch.mockClear();
});

describe('CurrencyConverter', () => {
  it('should fetch rates and convert correctly', async () => {
    // Arrange
    // Mock the successful API response
    fetch.mockResolvedValueOnce({
      json: () => Promise.resolve({ rates: { EUR: 0.92 } })
    });

    const converter = new CurrencyConverter('https://api.exchangerates.com');
    const amount = 10; // 10 USD

    // Act
    const result = await converter.convert(amount, 'USD', 'EUR');

    // Assert
    expect(result).toBe(9.2);
    expect(fetch).toHaveBeenCalledTimes(1);
    expect(fetch).toHaveBeenCalledWith('https://api.exchangerates.com/latest?base=USD');
  });

  // We'd also add tests for API failures, etc.
});
            

              
                Copy
              
            
          

இதை இயக்குவது ஒரு சிவப்பு கடலில் விளைவிக்கும். நமது பழைய `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}`);
    }

    // Simple rounding to avoid floating point issues in tests
    const convertedAmount = amount * rate;
    return parseFloat(convertedAmount.toFixed(2));
  }
}

module.exports = CurrencyConverter;
            

              
                Copy
              
            
          

நீங்கள் சேமிக்கும்போது, சோதனை பச்சை நிறமாக மாற வேண்டும். நிதி கணக்கீடுகளில் ஒரு பொதுவான பிரச்சினையான மிதக்கும்-புள்ளித் தவறுகளைக் கையாள округление தர்க்கத்தையும் நாங்கள் சேர்த்துள்ளோம் என்பதைக் கவனியுங்கள்.

🔵 ரீஃபாக்டர்: ஒத்திசைவற்ற குறியீட்டை மேம்படுத்துங்கள்

இந்த `convert` முறை நிறைய செய்கிறது: பெறுதல், பிழை கையாளுதல், பாகுபடுத்துதல் மற்றும் கணக்கிடுதல். ஏபிஐ தகவல்தொடர்புக்கு மட்டுமே பொறுப்பான ஒரு தனி `RateFetcher` கிளாஸை உருவாக்குவதன் மூலம் இதை ரீஃபாக்டர் செய்யலாம். நமது `CurrencyConverter` பின்னர் இந்த ஃபெட்சரைப் பயன்படுத்தும். இது ஒற்றைப் பொறுப்புக் கொள்கையைப் பின்பற்றுகிறது மற்றும் இரண்டு கிளாஸ்களையும் சோதிக்கவும் பராமரிக்கவும் எளிதாக்குகிறது. TDD நம்மை இந்த சுத்தமான வடிவமைப்பை நோக்கி வழிநடத்துகிறது.

பொதுவான TDD முறைகள் மற்றும் எதிர்-முறைகள்

நீங்கள் TDD பயிற்சி செய்யும்போது, நன்றாக வேலை செய்யும் முறைகளையும், உராய்வை ஏற்படுத்தும் எதிர்-முறைகளையும் கண்டுபிடிப்பீர்கள்.

பின்பற்ற வேண்டிய நல்ல முறைகள்

• ஏற்பாடு, செயல், உறுதிப்படுத்தல் (Arrange, Act, Assert - AAA): உங்கள் சோதனைகளை மூன்று தெளிவான பகுதிகளில் கட்டமைக்கவும். உங்கள் அமைப்பை ஏற்பாடு செய்யுங்கள், சோதனையின் கீழ் உள்ள குறியீட்டை இயக்குவதன் மூலம் செயல்படுங்கள், மற்றும் விளைவு சரியானது என்பதை உறுதிப்படுத்தவும். இது சோதனைகளை எளிதாகப் படிக்கவும் புரிந்துகொள்ளவும் செய்கிறது.
• ஒரு நேரத்தில் ஒரு நடத்தையை சோதிக்கவும்: ஒவ்வொரு சோதனை வழக்கும் ஒரு ஒற்றை, குறிப்பிட்ட நடத்தையை சரிபார்க்க வேண்டும். இது ஒரு சோதனை தோல்வியடையும் போது என்ன உடைந்தது என்பதைத் தெளிவாகக் காட்டுகிறது.
• விளக்கமான சோதனை பெயர்களைப் பயன்படுத்தவும்: `'தொகை எதிர்மறையாக இருந்தால் ஒரு பிழையைத் தூண்ட வேண்டும்'` போன்ற ஒரு சோதனைப் பெயர் `'சோதனை 1'` என்பதை விட மிகவும் மதிப்புமிக்கது.

தவிர்க்க வேண்டிய எதிர்-முறைகள்

• செயல்படுத்தல் விவரங்களை சோதித்தல்: சோதனைகள் பொது ஏபிஐ ("என்ன") மீது கவனம் செலுத்த வேண்டும், தனிப்பட்ட செயல்படுத்தல் ("எப்படி") மீது அல்ல. தனிப்பட்ட முறைகளை சோதிப்பது உங்கள் சோதனைகளை பலவீனமாக்குகிறது மற்றும் ரீஃபாக்டரிங்கை கடினமாக்குகிறது.
• ரீஃபாக்டர் படியைப் புறக்கணித்தல்: இது மிகவும் பொதுவான தவறு. ரீஃபாக்டரிங்கைத் தவிர்ப்பது உங்கள் உற்பத்தி குறியீடு மற்றும் உங்கள் சோதனைத் தொகுப்பு இரண்டிலும் தொழில்நுட்பக் கடனுக்கு வழிவகுக்கிறது.
• பெரிய, மெதுவான சோதனைகளை எழுதுதல்: யூனிட் சோதனைகள் வேகமாக இருக்க வேண்டும். அவை உண்மையான தரவுத்தளங்கள், நெட்வொர்க் அழைப்புகள் அல்லது கோப்பு முறைமைகளை நம்பியிருந்தால், அவை மெதுவாகவும் நம்பகத்தன்மையற்றதாகவும் மாறும். உங்கள் யூனிட்களைத் தனிமைப்படுத்த மாக்ஸ் மற்றும் ஸ்டப்களைப் பயன்படுத்தவும்.

பரந்த மேம்பாட்டு வாழ்க்கைச் சுழற்சியில் TDD

TDD ஒரு வெற்றிடத்தில் இல்லை. இது நவீன ஏஜைல் மற்றும் DevOps நடைமுறைகளுடன் அழகாக ஒருங்கிணைக்கிறது, குறிப்பாக உலகளாவிய குழுக்களுக்கு.

• TDD மற்றும் ஏஜைல்: உங்கள் திட்ட மேலாண்மை கருவியிலிருந்து ஒரு பயனர் கதை அல்லது ஒரு ஏற்றுக்கொள்ளும் அளவுகோலை நேரடியாக தோல்வியடையும் சோதனைகளின் தொடராக மொழிபெயர்க்கலாம். இது நீங்கள் வணிகத்திற்குத் தேவையானதை சரியாக உருவாக்குகிறீர்கள் என்பதை உறுதி செய்கிறது.
• TDD மற்றும் தொடர்ச்சியான ஒருங்கிணைப்பு/தொடர்ச்சியான வரிசைப்படுத்தல் (CI/CD): TDD ஒரு நம்பகமான CI/CD பைப்லைனின் அடித்தளமாகும். ஒவ்வொரு முறையும் ஒரு டெவலப்பர் குறியீட்டை புஷ் செய்யும் போது, ஒரு தானியங்கு அமைப்பு (GitHub Actions, GitLab CI, அல்லது Jenkins போன்றவை) முழு சோதனைத் தொகுப்பையும் இயக்க முடியும். ஏதேனும் சோதனை தோல்வியுற்றால், பில்ட் நிறுத்தப்படும், இது பிழைகள் உற்பத்திக்கு வருவதைத் தடுக்கிறது. இது நேர மண்டலங்களைப் பொருட்படுத்தாமல் முழு அணிக்கும் வேகமான, தானியங்கு பின்னூட்டத்தை வழங்குகிறது.
• TDD vs. BDD (நடத்தை-உந்துதல் மேம்பாடு): BDD என்பது TDD-இன் ஒரு நீட்டிப்பாகும், இது டெவலப்பர்கள், QA மற்றும் வணிகப் பங்குதாரர்களுக்கு இடையேயான ஒத்துழைப்பில் கவனம் செலுத்துகிறது. இது நடத்தையை விவரிக்க ஒரு இயற்கை மொழி வடிவத்தைப் (Given-When-Then) பயன்படுத்துகிறது. பெரும்பாலும், ஒரு BDD அம்சம் கோப்பு பல TDD-பாணி யூனிட் சோதனைகளின் உருவாக்கத்தைத் தூண்டும்.

முடிவுரை: TDD உடன் உங்கள் பயணம்

சோதனை-உந்துதல் மேம்பாடு என்பது ஒரு சோதனை உத்தியை விட மேலானது—இது நாம் மென்பொருள் மேம்பாட்டை அணுகும் விதத்தில் ஒரு முன்னுதாரண மாற்றம். இது தரம், நம்பிக்கை மற்றும் ஒத்துழைப்பின் கலாச்சாரத்தை வளர்க்கிறது. ரெட்-கிரீன்-ரீஃபாக்டர் சுழற்சி ஒரு நிலையான தாளத்தை வழங்குகிறது, அது உங்களை சுத்தமான, வலுவான மற்றும் பராமரிக்கக்கூடிய குறியீட்டை நோக்கி வழிநடத்துகிறது. இதன் விளைவாக வரும் சோதனைத் தொகுப்பு உங்கள் அணியை பின்னடைவுகளிலிருந்து பாதுகாக்கும் ஒரு பாதுகாப்பு வலையாகவும், புதிய உறுப்பினர்களை உள்வாங்கும் ஒரு வாழும் ஆவணமாகவும் மாறுகிறது.

கற்றல் வளைவு செங்குத்தானதாக உணரப்படலாம், மற்றும் ஆரம்ப வேகம் மெதுவாகத் தோன்றலாம். ஆனால் பிழைத்திருத்த நேரத்தைக் குறைத்தல், மென்பொருள் வடிவமைப்பை மேம்படுத்துதல் மற்றும் டெவலப்பர் நம்பிக்கையை அதிகரித்தல் ஆகியவற்றில் நீண்ட காலப் பலன்கள் அளவிட முடியாதவை. TDD-ஐ மாஸ்டர் செய்வதற்கான பயணம் ஒழுக்கம் மற்றும் பயிற்சியின் ஒன்றாகும்.

இன்றே தொடங்குங்கள். உங்கள் அடுத்த திட்டத்தில் ஒரு சிறிய, முக்கியமற்ற அம்சத்தைத் தேர்ந்தெடுத்து, செயல்முறைக்கு உங்களை அர்ப்பணிக்கவும். முதலில் சோதனையை எழுதுங்கள். அது தோல்வியடைவதைப் பாருங்கள். அதை தேர்ச்சி பெறச் செய்யுங்கள். பின்னர், மிக முக்கியமாக, ரீஃபாக்டர் செய்யுங்கள். ஒரு பச்சை சோதனைத் தொகுப்பிலிருந்து வரும் நம்பிக்கையை அனுபவியுங்கள், நீங்கள் எப்படி மென்பொருளை வேறு எந்த வழியிலும் உருவாக்கினீர்கள் என்று விரைவில் ஆச்சரியப்படுவீர்கள்.