---
title: "திறன் ஒப்பந்தங்களைச் சோதித்தல்"
description: "எத்திரியம் திறன் ஒப்பந்தங்களைச் சோதிப்பதற்கான நுட்பங்கள் மற்றும் கருத்தில் கொள்ள வேண்டியவைகளின் மேலோட்டம்."
lang: ta
---

எத்திரியம் போன்ற பொதுத் தொகுதிச்சங்கிலிகள் மாற்றவியலாதவை, இதனால் நிலைநிறுத்தத்திற்குப் பிறகு திறன் ஒப்பந்தங்களின் குறியீட்டை மாற்றுவது கடினம். "மெய்நிகர் மேம்படுத்தல்களை" (virtual upgrades) செய்வதற்கான [ஒப்பந்த மேம்படுத்தல் வடிவங்கள்](/developers/docs/smart-contracts/upgrading/) உள்ளன, ஆனால் இவற்றைச் செயல்படுத்துவது கடினம் மற்றும் சமூக ஒருமித்த கருத்து தேவை. மேலும், ஒரு பிழையைக் கண்டறிந்த _பிறகு_ மட்டுமே மேம்படுத்தலால் அதைச் சரிசெய்ய முடியும்—ஒரு தாக்குபவர் முதலில் பாதிப்பைக் கண்டறிந்தால், உங்கள் திறன் ஒப்பந்தம் சுரண்டப்படும் அபாயத்தில் உள்ளது.

இந்தக் காரணங்களுக்காக, முதன்மை வலைப்பின்னலில் [நிலைநிறுத்துவதற்கு](/developers/docs/smart-contracts/deploying/) முன்பு திறன் ஒப்பந்தங்களைச் சோதிப்பது [பாதுகாப்பிற்கான](/developers/docs/smart-contracts/security/) குறைந்தபட்சத் தேவையாகும். ஒப்பந்தங்களைச் சோதிப்பதற்கும் குறியீட்டின் சரியான தன்மையை மதிப்பிடுவதற்கும் பல நுட்பங்கள் உள்ளன; நீங்கள் எதைத் தேர்ந்தெடுக்கிறீர்கள் என்பது உங்கள் தேவைகளைப் பொறுத்தது. ஆயினும்கூட, ஒப்பந்தக் குறியீட்டில் உள்ள சிறிய மற்றும் பெரிய பாதுகாப்புப் பிழைகள் இரண்டையும் கண்டறிவதற்கு வெவ்வேறு கருவிகள் மற்றும் அணுகுமுறைகளைக் கொண்ட ஒரு சோதனைத் தொகுப்பு (test suite) சிறந்தது.

## முன்நிபந்தனைகள் {#prerequisites}

எத்திரியம் பிணையத்தில் நிலைநிறுத்துவதற்கு முன்பு திறன் ஒப்பந்தங்களை எவ்வாறு சோதிப்பது என்பதை இந்தப் பக்கம் விளக்குகிறது. உங்களுக்குத் [திறன் ஒப்பந்தங்கள்](/developers/docs/smart-contracts/) பற்றித் தெரிந்திருக்கும் என்று இது கருதுகிறது.

## திறன் ஒப்பந்தச் சோதனை என்றால் என்ன? {#what-is-smart-contract-testing}

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

அணுகுமுறைகள் மாறுபட்டாலும், பெரும்பாலான சோதனை முறைகளுக்கு ஒரு திறன் ஒப்பந்தம் கையாள எதிர்பார்க்கப்படும் தரவின் சிறிய மாதிரியுடன் அதைச் செயல்படுத்த வேண்டும். மாதிரித் தரவிற்கு ஒப்பந்தம் சரியான முடிவுகளைத் தந்தால், அது சரியாகச் செயல்படுவதாகக் கருதப்படுகிறது. ஒரு ஒப்பந்தத்தின் செயலாக்கம் எதிர்பார்த்த முடிவுகளுடன் பொருந்துகிறதா என்பதைச் சரிபார்க்க, [சோதனை நிகழ்வுகளை (test cases)](https://en.m.wikipedia.org/wiki/Test_case) எழுதுவதற்கும் செயல்படுத்துவதற்கும் பெரும்பாலான சோதனைக் கருவிகள் ஆதாரங்களை வழங்குகின்றன.

### திறன் ஒப்பந்தங்களைச் சோதிப்பது ஏன் முக்கியம்? {#importance-of-testing-smart-contracts}

திறன் ஒப்பந்தங்கள் பெரும்பாலும் அதிக மதிப்புள்ள நிதிச் சொத்துக்களை நிர்வகிப்பதால், சிறிய நிரலாக்கப் பிழைகள் [பயனர்களுக்குப் பெரிய இழப்புகளுக்கு](https://rekt.news/leaderboard/) வழிவகுக்கும். இருப்பினும், கடுமையான சோதனையானது திறன் ஒப்பந்தத்தின் குறியீட்டில் உள்ள குறைபாடுகள் மற்றும் சிக்கல்களை முன்கூட்டியே கண்டறிந்து, முதன்மை வலைப்பின்னலில் தொடங்குவதற்கு முன்பு அவற்றைச் சரிசெய்ய உதவும்.

ஒரு பிழை கண்டறியப்பட்டால் ஒப்பந்தத்தை மேம்படுத்த முடியும் என்றாலும், மேம்படுத்தல்கள் சிக்கலானவை மற்றும் முறையற்ற முறையில் கையாளப்பட்டால் [பிழைகளை ஏற்படுத்தலாம்](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/). ஒரு ஒப்பந்தத்தை மேம்படுத்துவது மாற்றவியலாமை என்ற கொள்கையை மேலும் நிராகரிக்கிறது மற்றும் கூடுதல் நம்பிக்கை அனுமானங்களுடன் பயனர்களுக்குச் சுமையை ஏற்படுத்துகிறது. மாறாக, உங்கள் ஒப்பந்தத்தைச் சோதிப்பதற்கான ஒரு விரிவான திட்டம் திறன் ஒப்பந்தப் பாதுகாப்பு அபாயங்களைக் குறைக்கிறது மற்றும் நிலைநிறுத்தத்திற்குப் பிறகு சிக்கலான தர்க்க மேம்படுத்தல்களைச் செய்ய வேண்டிய தேவையைக் குறைக்கிறது.

## திறன் ஒப்பந்தங்களைச் சோதிப்பதற்கான முறைகள் {#methods-for-testing-smart-contracts}

எத்திரியம் திறன் ஒப்பந்தங்களைச் சோதிப்பதற்கான முறைகள் இரண்டு பரந்த வகைகளின் கீழ் வருகின்றன: **தானியங்குச் சோதனை (automated testing)** மற்றும் **கைமுறைச் சோதனை (manual testing)**. தானியங்குச் சோதனை மற்றும் கைமுறைச் சோதனை ஆகியவை தனித்துவமான நன்மைகள் மற்றும் பரிமாற்றங்களை வழங்குகின்றன, ஆனால் உங்கள் ஒப்பந்தங்களை பகுப்பாய்வு செய்வதற்கான வலுவான திட்டத்தை உருவாக்க நீங்கள் இரண்டையும் இணைக்கலாம்.

### தானியங்குச் சோதனை {#automated-testing}

தானியங்குச் சோதனையானது, செயலாக்கத்தில் உள்ள பிழைகளுக்காகத் திறன் ஒப்பந்தங்களின் குறியீட்டைத் தானாகவே சரிபார்க்கும் கருவிகளைப் பயன்படுத்துகிறது. ஒப்பந்தச் செயல்பாடுகளின் மதிப்பீட்டை வழிநடத்த [ஸ்கிரிப்ட்களைப்](https://www.techtarget.com/whatis/definition/script?amp=1) பயன்படுத்துவதன் மூலம் தானியங்குச் சோதனையின் நன்மை கிடைக்கிறது. ஸ்கிரிப்ட் செய்யப்பட்ட சோதனைகளை மனிதத் தலையீடு குறைவாகக் கொண்டு மீண்டும் மீண்டும் இயங்குமாறு திட்டமிடலாம், இது கைமுறைச் சோதனை அணுகுமுறைகளை விடத் தானியங்குச் சோதனையை மிகவும் திறமையானதாக்குகிறது.

சோதனைகள் மீண்டும் மீண்டும் மற்றும் அதிக நேரம் எடுக்கும் போது; கைமுறையாகச் செய்வது கடினமாக இருக்கும் போது; மனிதப் பிழைகளுக்கு ஆளாகும் போது; அல்லது முக்கியமான ஒப்பந்தச் செயல்பாடுகளை மதிப்பிடுவதை உள்ளடக்கியிருக்கும் போது தானியங்குச் சோதனை குறிப்பாகப் பயனுள்ளதாக இருக்கும். ஆனால் தானியங்குச் சோதனைக் கருவிகளில் குறைபாடுகள் இருக்கலாம்—அவை சில பிழைகளைத் தவறவிடலாம் மற்றும் பல [தவறான நேர்மறைகளை (false positives)](https://www.contrastsecurity.com/glossary/false-positive) உருவாக்கலாம். எனவே, திறன் ஒப்பந்தங்களுக்குத் தானியங்குச் சோதனையைக் கைமுறைச் சோதனையுடன் இணைப்பது சிறந்தது.

### கைமுறைச் சோதனை {#manual-testing}

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

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

பயனுள்ள கைமுறைச் சோதனைக்குக் கணிசமான வளங்கள் (திறன், நேரம், பணம் மற்றும் முயற்சி) தேவைப்படுகின்றன, மேலும் சோதனைகளைச் செயல்படுத்தும் போது சில பிழைகளைத் தவறவிடுவது—மனிதப் பிழை காரணமாக—சாத்தியமாகும். ஆனால் கைமுறைச் சோதனையும் பயனுள்ளதாக இருக்கும்—எடுத்துக்காட்டாக, ஒரு மனிதச் சோதனையாளர் (எ.கா., ஒரு தணிக்கையாளர்) தானியங்குச் சோதனைக் கருவி தவறவிடக்கூடிய விளிம்பு நிலைகளை (edge cases) கண்டறிய உள்ளுணர்வைப் பயன்படுத்தலாம்.

## திறன் ஒப்பந்தங்களுக்கான தானியங்குச் சோதனை {#automated-testing-for-smart-contracts}

### அலகுச் சோதனை (Unit testing) {#unit-testing-for-smart-contracts}

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

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

#### திறன் ஒப்பந்தங்களை அலகுச் சோதனை செய்வதற்கான வழிகாட்டுதல்கள் {#unit-testing-guidelines}

##### 1. உங்கள் ஒப்பந்தத்தின் வணிகத் தர்க்கம் மற்றும் பணிப்பாய்வுகளைப் புரிந்து கொள்ளுங்கள்

அலகுச் சோதனைகளை எழுதுவதற்கு முன், ஒரு திறன் ஒப்பந்தம் என்ன செயல்பாடுகளை வழங்குகிறது மற்றும் பயனர்கள் அந்தச் செயல்பாடுகளை எவ்வாறு அணுகுவார்கள் மற்றும் பயன்படுத்துவார்கள் என்பதை அறிந்துகொள்வது உதவியாக இருக்கும். செல்லுபடியாகும் பயனர் உள்ளீடுகளுக்கு ஒரு ஒப்பந்தத்தில் உள்ள செயல்பாடுகள் சரியான வெளியீட்டை வழங்குகின்றனவா என்பதைத் தீர்மானிக்கும் [மகிழ்ச்சியான பாதைச் சோதனைகளை (happy path tests)](https://en.m.wikipedia.org/wiki/Happy_path) இயக்குவதற்கு இது மிகவும் பயனுள்ளதாக இருக்கும். [ஒரு ஏல ஒப்பந்தத்தின்](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction) இந்த (சுருக்கப்பட்ட) உதாரணத்தைப் பயன்படுத்தி இந்தக் கருத்தை விளக்குவோம்

```solidity
constructor(
        uint biddingTime,
        address payable beneficiaryAddress
    ) {
        beneficiary = beneficiaryAddress;
        auctionEndTime = block.timestamp + biddingTime;
    }

function bid() external payable {

      if (block.timestamp > auctionEndTime)
            revert AuctionAlreadyEnded();

      if (msg.value <= highestBid)
            revert BidNotHighEnough(highestBid);

 if (highestBid != 0) {
    pendingReturns[highestBidder] += highestBid;
        }
        highestBidder = msg.sender;
        highestBid = msg.value;
        emit HighestBidIncreased(msg.sender, msg.value);
    }

 function withdraw() external returns (bool) {
        uint amount = pendingReturns[msg.sender];
        if (amount > 0) {
           pendingReturns[msg.sender] = 0;

        if (!payable(msg.sender).send(amount)) {
                pendingReturns[msg.sender] = amount;
                return false;
            }
        }
        return true;
    }

function auctionEnd() external {
       if (block.timestamp < auctionEndTime)
            revert AuctionNotYetEnded();
        if (ended)
            revert AuctionEndAlreadyCalled();

        ended = true;
        emit AuctionEnded(highestBidder, highestBid);

        beneficiary.transfer(highestBid);
    }
}
```

இது ஏலக் காலத்தில் ஏலங்களைப் பெறுவதற்காக வடிவமைக்கப்பட்ட ஒரு எளிய ஏல ஒப்பந்தமாகும். `highestBid` அதிகரித்தால், முந்தைய அதிக ஏலதாரர் தங்கள் பணத்தைப் பெறுவார்; ஏலக் காலம் முடிந்ததும், `beneficiary` தங்கள் பணத்தைப் பெற ஒப்பந்தத்தை அழைப்பார்.

இதுபோன்ற ஒரு ஒப்பந்தத்திற்கான அலகுச் சோதனைகள், ஒப்பந்தத்துடன் தொடர்பு கொள்ளும்போது பயனர் அழைக்கக்கூடிய வெவ்வேறு செயல்பாடுகளை உள்ளடக்கும். ஏலம் நடந்துகொண்டிருக்கும்போது ஒரு பயனர் ஏலம் கேட்க முடியுமா என்பதைச் சரிபார்க்கும் அலகுச் சோதனை (அதாவது, `bid()` க்கான அழைப்புகள் வெற்றியடைகின்றன) அல்லது தற்போதைய `highestBid` ஐ விட அதிக ஏலத்தை ஒரு பயனர் வைக்க முடியுமா என்பதைச் சரிபார்க்கும் ஒரு சோதனை இதற்கு உதாரணமாக இருக்கும்.

ஒரு ஒப்பந்தத்தின் செயல்பாட்டுப் பணிப்பாய்வுகளைப் புரிந்துகொள்வது, செயலாக்கம் தேவைகளைப் பூர்த்தி செய்கிறதா என்பதைச் சரிபார்க்கும் அலகுச் சோதனைகளை எழுதவும் உதவுகிறது. எடுத்துக்காட்டாக, ஏலம் முடிந்ததும் (அதாவது, `auctionEndTime` ஆனது `block.timestamp` ஐ விடக் குறைவாக இருக்கும்போது) பயனர்கள் ஏலம் கேட்க முடியாது என்று ஏல ஒப்பந்தம் குறிப்பிடுகிறது. எனவே, ஏலம் முடிந்ததும் (அதாவது, `auctionEndTime` > `block.timestamp` ஆக இருக்கும்போது) `bid()` செயல்பாட்டிற்கான அழைப்புகள் வெற்றியடைகின்றனவா அல்லது தோல்வியடைகின்றனவா என்பதைச் சரிபார்க்கும் அலகுச் சோதனையை ஒரு டெவலப்பர் இயக்கலாம்.

##### 2. ஒப்பந்தச் செயலாக்கம் தொடர்பான அனைத்து அனுமானங்களையும் மதிப்பிடுங்கள்

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

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

- ஏலம் முடிந்ததும் அல்லது தொடங்காதபோதும் பயனர்கள் ஏலம் கேட்க முடியாது.

- ஏலம் ஏற்றுக்கொள்ளக்கூடிய வரம்பிற்குக் குறைவாக இருந்தால் ஏல ஒப்பந்தம் திரும்பப் பெறப்படும்.

- ஏலத்தை வெல்லத் தவறிய பயனர்களுக்கு அவர்களின் நிதி வரவு வைக்கப்படும்

**குறிப்பு**: அனுமானங்களைச் சோதிப்பதற்கான மற்றொரு வழி, ஒரு ஒப்பந்தத்தில் [செயல்பாட்டு மாற்றிகளை (function modifiers)](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers), குறிப்பாக `require`, `assert` மற்றும் `if…else` அறிக்கைகளைத் தூண்டும் சோதனைகளை எழுதுவதாகும்.

##### 3. குறியீட்டுத் தழுவலை (Code coverage) அளவிடவும்

[குறியீட்டுத் தழுவல்](https://en.m.wikipedia.org/wiki/Code_coverage) என்பது சோதனைகளின் போது செயல்படுத்தப்பட்ட உங்கள் குறியீட்டில் உள்ள கிளைகள், வரிகள் மற்றும் அறிக்கைகளின் எண்ணிக்கையைக் கண்காணிக்கும் ஒரு சோதனை அளவீடு ஆகும். சோதிக்கப்படாத பாதிப்புகளின் அபாயத்தைக் குறைக்கச் சோதனைகள் நல்ல குறியீட்டுத் தழுவலைக் கொண்டிருக்க வேண்டும். போதுமான தழுவல் இல்லாமல், அனைத்துச் சோதனைகளும் தேர்ச்சி பெறுவதால் உங்கள் ஒப்பந்தம் பாதுகாப்பானது என்று நீங்கள் தவறாகக் கருதலாம், அதே நேரத்தில் சோதிக்கப்படாத குறியீட்டுப் பாதைகளில் பாதிப்புகள் இன்னும் உள்ளன. இருப்பினும், அதிகக் குறியீட்டுத் தழுவலைப் பதிவு செய்வது, ஒரு திறன் ஒப்பந்தத்தில் உள்ள அனைத்து அறிக்கைகள்/செயல்பாடுகளும் சரியான தன்மைக்காகப் போதுமான அளவு சோதிக்கப்பட்டன என்ற உத்தரவாதத்தை அளிக்கிறது.

##### 4. நன்கு உருவாக்கப்பட்ட சோதனைக் கட்டமைப்புகளைப் பயன்படுத்தவும்

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

Solidity திறன் ஒப்பந்தங்களுக்கான அலகுச் சோதனைக் கட்டமைப்புகள் வெவ்வேறு மொழிகளில் (பெரும்பாலும் JavaScript, Python மற்றும் Rust) வருகின்றன. வெவ்வேறு சோதனைக் கட்டமைப்புகளுடன் அலகுச் சோதனைகளை எவ்வாறு தொடங்குவது என்பது பற்றிய தகவலுக்குக் கீழே உள்ள சில வழிகாட்டிகளைப் பார்க்கவும்:

- **[Brownie உடன் அலகுச் சோதனைகளை இயக்குதல்](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)**
- **[Foundry உடன் அலகுச் சோதனைகளை இயக்குதல்](https://book.getfoundry.sh/forge/writing-tests)**
- **[Waffle உடன் அலகுச் சோதனைகளை இயக்குதல்](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)**
- **[Remix உடன் அலகுச் சோதனைகளை இயக்குதல்](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)**
- **[Ape உடன் அலகுச் சோதனைகளை இயக்குதல்](https://docs.apeworx.io/ape/stable/userguides/testing.html)**
- **[Hardhat உடன் அலகுச் சோதனைகளை இயக்குதல்](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)**
- **[Wake உடன் அலகுச் சோதனைகளை இயக்குதல்](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)**

### ஒருங்கிணைப்புச் சோதனை (Integration testing) {#integration-testing-for-smart-contracts}

அலகுச் சோதனை ஒப்பந்தச் செயல்பாடுகளைத் தனித்தனியாகப் பிழைத்திருத்தம் செய்யும் அதே வேளையில், ஒருங்கிணைப்புச் சோதனைகள் ஒரு திறன் ஒப்பந்தத்தின் கூறுகளை முழுமையாக மதிப்பிடுகின்றன. ஒருங்கிணைப்புச் சோதனையானது குறுக்கு-ஒப்பந்த அழைப்புகள் அல்லது அதே திறன் ஒப்பந்தத்தில் உள்ள வெவ்வேறு செயல்பாடுகளுக்கு இடையிலான தொடர்புகளிலிருந்து எழும் சிக்கல்களைக் கண்டறிய முடியும். எடுத்துக்காட்டாக, [மரபுரிமை (inheritance)](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) மற்றும் சார்பு ஊசி (dependency injection) போன்ற விஷயங்கள் சரியாகச் செயல்படுகின்றனவா என்பதைச் சரிபார்க்க ஒருங்கிணைப்புச் சோதனைகள் உதவும்.

உங்கள் ஒப்பந்தம் ஒரு மட்டுப்படுத்தப்பட்ட கட்டமைப்பை (modular architecture) ஏற்றுக்கொண்டால் அல்லது செயலாக்கத்தின் போது பிற சங்கிலிசார் ஒப்பந்தங்களுடன் இடைமுகமாக இருந்தால் ஒருங்கிணைப்புச் சோதனை பயனுள்ளதாக இருக்கும். ஒருங்கிணைப்புச் சோதனைகளை இயக்குவதற்கான ஒரு வழி, ஒரு குறிப்பிட்ட உயரத்தில் [தொகுதிச்சங்கிலியைக் கவை (fork) செய்வதாகும்](/glossary/#fork) ([Forge](https://book.getfoundry.sh/forge/fork-testing) அல்லது [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) போன்ற கருவியைப் பயன்படுத்தி) மற்றும் உங்கள் ஒப்பந்தத்திற்கும் நிலைநிறுத்தப்பட்ட ஒப்பந்தங்களுக்கும் இடையிலான தொடர்புகளை உருவகப்படுத்துவதாகும்.

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

### பண்பு அடிப்படையிலான சோதனை (Property-based testing) {#property-based-testing-for-smart-contracts}

பண்பு அடிப்படையிலான சோதனை என்பது ஒரு திறன் ஒப்பந்தம் சில வரையறுக்கப்பட்ட பண்புகளைப் பூர்த்தி செய்கிறதா என்பதைச் சரிபார்க்கும் செயல்முறையாகும். வெவ்வேறு சூழ்நிலைகளில் உண்மையாக இருக்கும் என்று எதிர்பார்க்கப்படும் ஒரு ஒப்பந்தத்தின் நடத்தை பற்றிய உண்மைகளைப் பண்புகள் வலியுறுத்துகின்றன—ஒரு திறன் ஒப்பந்தப் பண்பின் உதாரணம் "ஒப்பந்தத்தில் உள்ள எண்கணிதச் செயல்பாடுகள் ஒருபோதும் அளவுமீறல் (overflow) அல்லது குறைவடைதல் (underflow) ஆகாது" என்பதாக இருக்கலாம்.

**நிலையான பகுப்பாய்வு (Static analysis)** மற்றும் **மாறும் பகுப்பாய்வு (dynamic analysis)** ஆகியவை பண்பு அடிப்படையிலான சோதனையைச் செயல்படுத்துவதற்கான இரண்டு பொதுவான நுட்பங்களாகும், மேலும் இரண்டும் ஒரு நிரலுக்கான குறியீடு (இந்த விஷயத்தில் ஒரு திறன் ஒப்பந்தம்) சில முன்வரையறுக்கப்பட்ட பண்புகளைப் பூர்த்தி செய்கிறதா என்பதைச் சரிபார்க்க முடியும். சில பண்பு அடிப்படையிலான சோதனைக் கருவிகள் எதிர்பார்க்கப்படும் ஒப்பந்தப் பண்புகள் பற்றிய முன்வரையறுக்கப்பட்ட விதிகளுடன் வருகின்றன மற்றும் அந்த விதிகளுக்கு எதிராகக் குறியீட்டைச் சரிபார்க்கின்றன, மற்றவை ஒரு திறன் ஒப்பந்தத்திற்கான தனிப்பயன் பண்புகளை உருவாக்க உங்களை அனுமதிக்கின்றன.

#### நிலையான பகுப்பாய்வு {#static-analysis}

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

ஒப்பந்தங்களில் நிலையான பகுப்பாய்வை இயக்குவதற்கு [லிண்டிங் (Linting)](https://www.perforce.com/blog/qac/what-is-linting) மற்றும் [நிலையான சோதனை](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) ஆகியவை பொதுவான முறைகளாகும். இரண்டிற்கும் கம்பைலரால் வெளியிடப்படும் [சுருக்கத் தொடரியல் மரங்கள் (abstract syntax trees)](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) மற்றும் [கட்டுப்பாட்டு ஓட்ட வரைபடங்கள் (control flow graphs)](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/) போன்ற ஒப்பந்தச் செயலாக்கத்தின் குறைந்த-நிலை பிரதிநிதித்துவங்களைப் பகுப்பாய்வு செய்ய வேண்டும்.

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

#### மாறும் பகுப்பாய்வு {#dynamic-analysis}

மாறும் பகுப்பாய்வு குறியீட்டு உள்ளீடுகளை (எ.கா., [குறியீட்டுச் செயலாக்கத்தில்](https://en.m.wikipedia.org/wiki/Symbolic_execution)) அல்லது உறுதியான உள்ளீடுகளை (எ.கா., [ஃபஸ்ஸிங்கில் (fuzzing)](https://owasp.org/www-community/Fuzzing)) ஒரு திறன் ஒப்பந்தச் செயல்பாடுகளுக்கு உருவாக்குகிறது, ஏதேனும் செயலாக்கத் தடம்(கள்) குறிப்பிட்ட பண்புகளை மீறுகிறதா என்பதைப் பார்க்க. இந்த வகையான பண்பு அடிப்படையிலான சோதனை அலகுச் சோதனைகளிலிருந்து வேறுபடுகிறது, இதில் சோதனை நிகழ்வுகள் பல சூழ்நிலைகளை உள்ளடக்குகின்றன மற்றும் ஒரு நிரல் சோதனை நிகழ்வுகளின் உருவாக்கத்தைக் கையாளுகிறது.

திறன் ஒப்பந்தங்களில் தன்னிச்சையான பண்புகளைச் சரிபார்க்கும் மாறும் பகுப்பாய்வு நுட்பத்திற்கு [ஃபஸ்ஸிங்](https://www.halborn.com/blog/post/what-is-fuzz-testing-fuzzing) ஒரு எடுத்துக்காட்டு. ஒரு ஃபஸ்ஸர் (fuzzer) வரையறுக்கப்பட்ட உள்ளீட்டு மதிப்பின் சீரற்ற அல்லது தவறான மாறுபாடுகளுடன் இலக்கு ஒப்பந்தத்தில் செயல்பாடுகளைத் தூண்டுகிறது. திறன் ஒப்பந்தம் பிழை நிலைக்கு நுழைந்தால் (எ.கா., ஒரு உறுதிமொழி தோல்வியடையும் நிலை), சிக்கல் கொடியிடப்படும் மற்றும் பாதிக்கப்படக்கூடிய பாதையை நோக்கிச் செயலாக்கத்தை இயக்கும் உள்ளீடுகள் ஒரு அறிக்கையில் தயாரிக்கப்படும்.

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

1. **பல சூழ்நிலைகளை உள்ளடக்கிய சோதனை நிகழ்வுகளை எழுதுவது கடினம்.** ஒரு பண்புச் சோதனைக்கு நீங்கள் ஒரு நடத்தை மற்றும் நடத்தையைச் சோதிக்கத் தரவுகளின் வரம்பை வரையறுக்க வேண்டும்—நிரல் வரையறுக்கப்பட்ட பண்பின் அடிப்படையில் தானாகவே சோதனை நிகழ்வுகளை உருவாக்குகிறது.

2. **உங்கள் சோதனைத் தொகுப்பு நிரலுக்குள் சாத்தியமான அனைத்துப் பாதைகளையும் போதுமான அளவு உள்ளடக்காமல் இருக்கலாம்.** 100% தழுவலுடன் கூட, விளிம்பு நிலைகளைத் தவறவிடுவது சாத்தியமாகும்.

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

### திறன் ஒப்பந்தங்களுக்கான பண்பு அடிப்படையிலான சோதனையை இயக்குவதற்கான வழிகாட்டுதல்கள் {#running-property-based-tests}

பண்பு அடிப்படையிலான சோதனையை இயக்குவது பொதுவாக ஒரு திறன் ஒப்பந்தத்தில் நீங்கள் சரிபார்க்க விரும்பும் ஒரு பண்பை (எ.கா., [முழு எண் அளவுமீறல்கள்](https://github.com/ConsenSysDiligence/mythril/wiki/Integer-Overflow) இல்லாதது) அல்லது பண்புகளின் தொகுப்பை வரையறுப்பதன் மூலம் தொடங்குகிறது. பண்புச் சோதனைகளை எழுதும் போது பரிவர்த்தனை உள்ளீடுகளுக்கான தரவை நிரல் உருவாக்கக்கூடிய மதிப்புகளின் வரம்பையும் நீங்கள் வரையறுக்க வேண்டியிருக்கலாம்.

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

- **[ஸ்லித்தர் உடன் திறன் ஒப்பந்தங்களின் நிலையான பகுப்பாய்வு](https://github.com/crytic/slither)**
- **[Wake உடன் திறன் ஒப்பந்தங்களின் நிலையான பகுப்பாய்வு](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)**
- **[Brownie உடன் பண்பு அடிப்படையிலான சோதனை](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)**
- **[Foundry உடன் ஒப்பந்தங்களை ஃபஸ்ஸிங் செய்தல்](https://book.getfoundry.sh/forge/fuzz-testing)**
- **[எக்கிட்னா உடன் ஒப்பந்தங்களை ஃபஸ்ஸிங் செய்தல்](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)**
- **[Wake உடன் ஒப்பந்தங்களை ஃபஸ்ஸிங் செய்தல்](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)**
- **[மேண்டிகோர் உடன் திறன் ஒப்பந்தங்களின் குறியீட்டுச் செயலாக்கம்](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)**
- **[Mythril உடன் திறன் ஒப்பந்தங்களின் குறியீட்டுச் செயலாக்கம்](https://github.com/ConsenSysDiligence/mythril/blob/develop/docs/source/tutorial.rst)**

## திறன் ஒப்பந்தங்களுக்கான கைமுறைச் சோதனை {#manual-testing-for-smart-contracts}

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

### உள்ளூர் தொகுதிச்சங்கிலியில் ஒப்பந்தங்களைச் சோதித்தல் {#testing-on-local-blockchain}

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

உள்ளூர் தொகுதிச்சங்கிலியில் (இது [மேம்பாட்டுப் பிணையம்](/developers/docs/development-networks/) என்றும் அழைக்கப்படுகிறது) உங்கள் ஒப்பந்தத்தைச் சோதிப்பது முதன்மை வலைப்பின்னலில் சோதிப்பதற்குப் பரிந்துரைக்கப்பட்ட மாற்றாகும். உள்ளூர் தொகுதிச்சங்கிலி என்பது உங்கள் கணினியில் உள்ளூரில் இயங்கும் எத்திரியம் தொகுதிச்சங்கிலியின் நகலாகும், இது எத்திரியத்தின் செயலாக்க அடுக்கின் நடத்தையை உருவகப்படுத்துகிறது. எனவே, குறிப்பிடத்தக்கச் செலவுகள் இல்லாமல் ஒரு ஒப்பந்தத்துடன் தொடர்புகொள்வதற்கு நீங்கள் பரிவர்த்தனைகளை நிரல் செய்யலாம்.

உள்ளூர் தொகுதிச்சங்கிலியில் ஒப்பந்தங்களை இயக்குவது கைமுறை ஒருங்கிணைப்புச் சோதனையின் ஒரு வடிவமாகப் பயனுள்ளதாக இருக்கும். [திறன் ஒப்பந்தங்கள் மிகவும் தொகுக்கக்கூடியவை](/developers/docs/smart-contracts/composability/), இது ஏற்கனவே உள்ள நெறிமுறைகளுடன் ஒருங்கிணைக்க உங்களை அனுமதிக்கிறது—ஆனால் அத்தகைய சிக்கலான சங்கிலிசார் தொடர்புகள் சரியான முடிவுகளைத் தருகின்றனவா என்பதை நீங்கள் இன்னும் உறுதிசெய்ய வேண்டும்.

[மேம்பாட்டுப் பிணையங்கள் பற்றி மேலும்.](/developers/docs/development-networks/)

### சோதனை வலையமைப்புகளில் ஒப்பந்தங்களைச் சோதித்தல் {#testing-contracts-on-testnets}

ஒரு சோதனைப் பிணையம் அல்லது சோதனை வலையமைப்பு எத்தேரியம் முதன்மை வலைப்பின்னலைப் போலவே செயல்படுகிறது, தவிர இது நிஜ உலக மதிப்பு இல்லாத ஈதரை (ETH) பயன்படுத்துகிறது. [சோதனை வலையமைப்பில்](/developers/docs/networks/#ethereum-testnets) உங்கள் ஒப்பந்தத்தை நிலைநிறுத்துவது என்பது நிதியை ஆபத்தில் சிக்க வைக்காமல் எவரும் அதனுடன் தொடர்பு கொள்ளலாம் (எ.கா., பரவலாக்கப்பட்ட செயலியின் (dapp) முன்பக்கம் வழியாக) என்பதாகும்.

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

உள்ளூர் தொகுதிச்சங்கிலியில் சோதித்த பிறகு சோதனை வலையமைப்பில் நிலைநிறுத்துவது சிறந்தது, ஏனெனில் முந்தையது எத்திரியம் மெய்நிகர் இயந்திரத்தின் நடத்தைக்கு நெருக்கமாக உள்ளது. எனவே, நிஜ உலக நிலைமைகளின் கீழ் ஒரு திறன் ஒப்பந்தச் செயல்பாட்டை மதிப்பிடுவதற்குப் பல எத்திரியம்-சொந்தத் திட்டங்கள் சோதனை வலையமைப்புகளில் பரவலாக்கப்பட்ட செயலிகளை (dapps) நிலைநிறுத்துவது பொதுவானது.

[எத்திரியம் சோதனை வலையமைப்புகள் பற்றி மேலும்.](/developers/docs/development-networks/#public-beacon-testchains)

## சோதனை மற்றும் முறைசார் சரிபார்ப்பு {#testing-vs-formal-verification}

சில தரவு உள்ளீடுகளுக்கு ஒரு ஒப்பந்தம் எதிர்பார்க்கப்படும் முடிவுகளை வழங்குகிறது என்பதை உறுதிப்படுத்தச் சோதனை உதவுகிறது என்றாலும், சோதனைகளின் போது பயன்படுத்தப்படாத உள்ளீடுகளுக்கு அதை உறுதியாக நிரூபிக்க முடியாது. எனவே, ஒரு திறன் ஒப்பந்தத்தைச் சோதிப்பது "செயல்பாட்டுச் சரியான தன்மைக்கு" உத்தரவாதம் அளிக்க முடியாது (அதாவது, உள்ளீட்டு மதிப்புகளின் _அனைத்து_ தொகுப்புகளுக்கும் ஒரு நிரல் தேவைக்கேற்பச் செயல்படுகிறது என்பதைக் காட்ட முடியாது).

முறைசார் சரிபார்ப்பு என்பது நிரலின் முறையான மாதிரி முறையான விவரக்குறிப்புடன் பொருந்துகிறதா என்பதைச் சரிபார்ப்பதன் மூலம் மென்பொருளின் சரியான தன்மையை மதிப்பிடுவதற்கான ஒரு அணுகுமுறையாகும். ஒரு முறையான மாதிரி என்பது ஒரு நிரலின் சுருக்கமான கணிதப் பிரதிநிதித்துவமாகும், அதே சமயம் ஒரு முறையான விவரக்குறிப்பு ஒரு நிரலின் பண்புகளை வரையறுக்கிறது (அதாவது, நிரலின் செயலாக்கம் பற்றிய தர்க்கரீதியான உறுதிமொழிகள்).

பண்புகள் கணிதச் சொற்களில் எழுதப்பட்டிருப்பதால், அனுமானத்தின் தர்க்கரீதியான விதிகளைப் பயன்படுத்தி அமைப்பின் முறையான (கணித) மாதிரி ஒரு விவரக்குறிப்பைப் பூர்த்தி செய்கிறதா என்பதைச் சரிபார்க்க முடியும். எனவே, முறைசார் சரிபார்ப்புக் கருவிகள் ஒரு அமைப்பின் சரியான தன்மையின் 'கணித ஆதாரத்தை' உருவாக்குவதாகக் கூறப்படுகிறது.

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

[திறன் ஒப்பந்தங்களுக்கான முறைசார் சரிபார்ப்பு பற்றி மேலும்.](/developers/docs/smart-contracts/formal-verification)

## சோதனை மற்றும் தணிக்கைகள் மற்றும் பிழை வெகுமதிகள் {#testing-vs-audits-bug-bounties}

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

இருப்பினும், ஒரு சுயாதீனக் குறியீட்டு மதிப்பாய்வைப் பெறுவதன் மூலம் ஒப்பந்தப் பாதிப்புகளைக் கண்டறியும் சாத்தியத்தை நீங்கள் மேலும் அதிகரிக்கலாம். [திறன் ஒப்பந்தத் தணிக்கைகள்](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) மற்றும் [பிழை வெகுமதிகள்](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) ஆகியவை உங்கள் ஒப்பந்தங்களை மற்றவர்களைப் பகுப்பாய்வு செய்ய வைப்பதற்கான இரண்டு வழிகளாகும்.

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

மாறாக, ஒரு பிழை வெகுமதித் திட்டம் பொதுவாக ஒரு திறன் ஒப்பந்தத்தில் உள்ள பாதிப்பைக் கண்டறிந்து அதை டெவலப்பர்களுக்கு வெளிப்படுத்தும் ஒரு நபருக்கு (பொதுவாக [ஒயிட்ஹாட் ஹேக்கர்கள் (whitehat hackers)](<https://en.wikipedia.org/wiki/White_hat_(computer_security)>) என்று விவரிக்கப்படுகிறது) நிதி வெகுமதியை வழங்குவதை உள்ளடக்குகிறது. திறன் ஒப்பந்தங்களில் உள்ள குறைபாடுகளைக் கண்டறிய மற்றவர்களின் உதவியைக் கேட்பதை உள்ளடக்கியிருப்பதால் பிழை வெகுமதிகள் தணிக்கைகளைப் போலவே இருக்கும்.

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

## சோதனைக் கருவிகள் மற்றும் நிரலகங்கள் {#testing-tools-and-libraries}

### அலகுச் சோதனைக் கருவிகள் {#unit-testing-tools}

- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _Solidity இல் எழுதப்பட்ட திறன் ஒப்பந்தங்களுக்கான குறியீட்டுத் தழுவல் கருவி._

- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _மேம்பட்ட திறன் ஒப்பந்த மேம்பாடு மற்றும் சோதனைக்கான கட்டமைப்பு (Ethers.js ஐ அடிப்படையாகக் கொண்டது)._

- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Solidity திறன் ஒப்பந்தங்களைச் சோதிப்பதற்கான கருவி. ஒரு ஒப்பந்தத்திற்கான சோதனை நிகழ்வுகளை எழுதவும் இயக்கவும் பயன்படுத்தப்படும் Remix IDE "Solidity Unit Testing" செருகுநிரலின் கீழ் செயல்படுகிறது._

- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _எத்திரியம் திறன் ஒப்பந்தச் சோதனைக்கான உறுதிமொழி நிரலகம். உங்கள் ஒப்பந்தங்கள் எதிர்பார்த்தபடி செயல்படுவதை உறுதிப்படுத்திக் கொள்ளுங்கள்!_

- **[Brownie அலகுச் சோதனைக் கட்டமைப்பு](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownie Pytest ஐப் பயன்படுத்துகிறது, இது குறைந்தபட்சக் குறியீட்டுடன் சிறிய சோதனைகளை எழுத உங்களை அனுமதிக்கும் அம்சம் நிறைந்த சோதனைக் கட்டமைப்பாகும், பெரிய திட்டங்களுக்கு நன்றாக அளவிடப்படுகிறது மற்றும் மிகவும் நீட்டிக்கக்கூடியது._

- **[Foundry Tests](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry Forge ஐ வழங்குகிறது, இது எளிய அலகுச் சோதனைகள், எரிவாயு உகப்பாக்கச் சரிபார்ப்புகள் மற்றும் ஒப்பந்த ஃபஸ்ஸிங் ஆகியவற்றைச் செயல்படுத்தக்கூடிய வேகமான மற்றும் நெகிழ்வான எத்திரியம் சோதனைக் கட்டமைப்பாகும்._

- **[Hardhat Tests](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _Ethers.js, Mocha மற்றும் Chai ஐ அடிப்படையாகக் கொண்ட திறன் ஒப்பந்தங்களைச் சோதிப்பதற்கான கட்டமைப்பு._

- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _எத்திரியம் மெய்நிகர் இயந்திரத்தை இலக்காகக் கொண்ட திறன் ஒப்பந்தங்களுக்கான Python அடிப்படையிலான மேம்பாடு மற்றும் சோதனைக் கட்டமைப்பு._

- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _சிறந்த பயனர் அனுபவம் மற்றும் செயல்திறனுக்காக pytest மற்றும் Anvil ஐப் பயன்படுத்தி, வலுவான பிழைத்திருத்தத் திறன்கள் மற்றும் குறுக்கு-சங்கிலிச் சோதனை ஆதரவுடன் அலகுச் சோதனை மற்றும் ஃபஸ்ஸிங்கிற்கான Python அடிப்படையிலான கட்டமைப்பு._

### பண்பு அடிப்படையிலான சோதனைக் கருவிகள் {#property-based-testing-tools}

#### நிலையான பகுப்பாய்வுக் கருவிகள் {#static-analysis-tools}

- **[ஸ்லித்தர்](https://github.com/crytic/slither)** - _பாதிப்புகளைக் கண்டறிவதற்கும், குறியீட்டுப் புரிதலை மேம்படுத்துவதற்கும், திறன் ஒப்பந்தங்களுக்கான தனிப்பயன் பகுப்பாய்வுகளை எழுதுவதற்குமான Python அடிப்படையிலான Solidity நிலையான பகுப்பாய்வுக் கட்டமைப்பு._

- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _Solidity திறன் ஒப்பந்த நிரலாக்க மொழிக்கான நடை மற்றும் பாதுகாப்புச் சிறந்த நடைமுறைகளைச் செயல்படுத்துவதற்கான லிண்டர்._

- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** - _Web3 திறன் ஒப்பந்தப் பாதுகாப்பு மற்றும் மேம்பாட்டிற்காகக் குறிப்பாக வடிவமைக்கப்பட்ட Rust அடிப்படையிலான நிலையான பகுப்பாய்வி._

- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _பாதிப்பு மற்றும் குறியீட்டுத் தரக் கண்டறிதல்கள், குறியீட்டிலிருந்து பயனுள்ள தகவல்களைப் பிரித்தெடுப்பதற்கான அச்சுப்பொறிகள் மற்றும் தனிப்பயன் துணைத் தொகுதிகளை எழுதுவதற்கான ஆதரவுடன் கூடிய Python அடிப்படையிலான நிலையான பகுப்பாய்வுக் கட்டமைப்பு._

- **[Slippy](https://github.com/fvictorio/slippy)** - _Solidity க்கான எளிய மற்றும் சக்திவாய்ந்த லிண்டர்._

#### மாறும் பகுப்பாய்வுக் கருவிகள் {#dynamic-analysis-tools}

- **[எக்கிட்னா](https://github.com/crytic/echidna/)** - _பண்பு அடிப்படையிலான சோதனையின் மூலம் திறன் ஒப்பந்தங்களில் உள்ள பாதிப்புகளைக் கண்டறிவதற்கான வேகமான ஒப்பந்த ஃபஸ்ஸர்._

- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _திறன் ஒப்பந்தக் குறியீட்டில் பண்பு மீறல்களைக் கண்டறியப் பயனுள்ள தானியங்கு ஃபஸ்ஸிங் கருவி._

- **[மேண்டிகோர்](https://manticore.readthedocs.io/en/latest/index.html)** - _EVM பைட் குறியீட்டைப் பகுப்பாய்வு செய்வதற்கான மாறும் குறியீட்டுச் செயலாக்கக் கட்டமைப்பு._

- **[Mythril](https://github.com/ConsenSysDiligence/mythril)** - _கறை பகுப்பாய்வு (taint analysis), கான்கோலிக் பகுப்பாய்வு (concolic analysis) மற்றும் கட்டுப்பாட்டு ஓட்டச் சரிபார்ப்பு ஆகியவற்றைப் பயன்படுத்தி ஒப்பந்தப் பாதிப்புகளைக் கண்டறிவதற்கான EVM பைட் குறியீட்டு மதிப்பீட்டுக் கருவி._

- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribble என்பது ஒரு விவரக்குறிப்பு மொழி மற்றும் இயக்க நேரச் சரிபார்ப்புக் கருவியாகும், இது Diligence Fuzzing அல்லது MythX போன்ற கருவிகளைக் கொண்டு ஒப்பந்தங்களைத் தானாகவே சோதிக்க அனுமதிக்கும் பண்புகளுடன் திறன் ஒப்பந்தங்களைக் குறிக்க உங்களை அனுமதிக்கிறது._

## தொடர்புடைய பயிற்சிகள் {#related-tutorials}

- [வெவ்வேறு சோதனைத் தயாரிப்புகளின் மேலோட்டம் மற்றும் ஒப்பீடு](/developers/tutorials/guide-to-smart-contract-security-tools/) \_
- [திறன் ஒப்பந்தங்களைச் சோதிக்க எக்கிட்னாவை எவ்வாறு பயன்படுத்துவது](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)
- [திறன் ஒப்பந்தப் பிழைகளைக் கண்டறிய மேண்டிகோரை எவ்வாறு பயன்படுத்துவது](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
- [திறன் ஒப்பந்தப் பிழைகளைக் கண்டறிய ஸ்லித்தரை எவ்வாறு பயன்படுத்துவது](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
- [சோதனைக்காக Solidity ஒப்பந்தங்களை எவ்வாறு கேலி (mock) செய்வது](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/)
- [Foundry ஐப் பயன்படுத்தி Solidity இல் அலகுச் சோதனைகளை எவ்வாறு இயக்குவது](https://www.rareskills.io/post/foundry-testing-solidity)

## மேலும் படிக்க {#further-reading}

- [எத்திரியம் திறன் ஒப்பந்தங்களைச் சோதிப்பதற்கான ஆழமான வழிகாட்டி](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297)
- [எத்திரியம் திறன் ஒப்பந்தங்களை எவ்வாறு சோதிப்பது](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d)
- [டெவலப்பர்களுக்கான MolochDAO இன் அலகுச் சோதனை வழிகாட்டி](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide)
- [ஒரு ராக்ஸ்டாரைப் போலத் திறன் ஒப்பந்தங்களை எவ்வாறு சோதிப்பது](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001)

## பயிற்சிகள்: எத்திரியத்தில் திறன் ஒப்பந்தச் சோதனை {#tutorials}

- [உள்ளூர், பல-கிளையன்ட் சோதனை வலையமைப்பில் ஒரு பரவலாக்கப்பட்ட செயலியை (dapp) எவ்வாறு உருவாக்குவது மற்றும் சோதிப்பது](/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/) _– உள்ளூர் சோதனை வலையமைப்பில் ஒரு திறன் ஒப்பந்தத்தை நிலைநிறுத்துதல் மற்றும் சோதனைகளைச் செய்வதற்கான ஒத்திகை._
- [சோதனைக்காக Solidity திறன் ஒப்பந்தங்களை எவ்வாறு கேலி (mock) செய்வது](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/) _– போலித் தரவை எவ்வாறு பயன்படுத்துவது மற்றும் அலகுச் சோதனையை எவ்வாறு செயல்படுத்துவது என்பது குறித்த இடைநிலைப் பயிற்சி._
- [திறன் ஒப்பந்தங்களைச் சோதிக்க எக்கிட்னாவை எவ்வாறு பயன்படுத்துவது](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) _– ஃபஸ்ஸிங் மற்றும் திறன் ஒப்பந்தச் சோதனைக்கான மேம்பட்ட அணுகுமுறை._