परीक्षण के लिए Solidity स्मार्ट अनुबंधों को मॉक कैसे करें

मॉक ऑब्जेक्ट्स (Mock objects) (opens in a new tab) ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में एक सामान्य डिज़ाइन पैटर्न हैं। पुराने फ्रांसीसी शब्द 'mocquer' से आने वाले, जिसका अर्थ 'मज़ाक उड़ाना' है, यह 'किसी वास्तविक चीज़ की नकल करने' के रूप में विकसित हुआ, जो वास्तव में हम प्रोग्रामिंग में कर रहे हैं। कृपया केवल तभी अपने स्मार्ट अनुबंधों का मज़ाक उड़ाएं जब आप चाहें, लेकिन जब भी संभव हो उन्हें मॉक (mock) करें। यह आपके जीवन को आसान बनाता है।

मॉक्स के साथ अनुबंधों की यूनिट-टेस्टिंग (Unit-testing)

किसी अनुबंध को मॉक करने का मूल अर्थ उस अनुबंध का एक दूसरा संस्करण बनाना है जो मूल अनुबंध के समान व्यवहार करता है, लेकिन इस तरह से जिसे डेवलपर द्वारा आसानी से नियंत्रित किया जा सके। आप अक्सर ऐसे जटिल अनुबंधों के साथ समाप्त होते हैं जहां आप केवल अनुबंध के छोटे हिस्सों का यूनिट-टेस्ट करना चाहते हैं। समस्या यह है कि क्या होगा यदि इस छोटे से हिस्से का परीक्षण करने के लिए एक बहुत ही विशिष्ट अनुबंध स्थिति (state) की आवश्यकता होती है जिसमें पहुंचना मुश्किल है?

आप हर बार जटिल परीक्षण सेटअप लॉजिक लिख सकते हैं जो अनुबंध को आवश्यक स्थिति में लाता है या आप एक मॉक लिख सकते हैं। इनहेरिटेंस (inheritance) के साथ किसी अनुबंध को मॉक करना आसान है। बस एक दूसरा मॉक अनुबंध बनाएं जो मूल अनुबंध से इनहेरिट करता हो। अब आप अपने मॉक में फ़ंक्शंस को ओवरराइड (override) कर सकते हैं। आइए इसे एक उदाहरण से समझते हैं।

उदाहरण: निजी ERC-20

हम एक उदाहरण ERC-20 अनुबंध का उपयोग करते हैं जिसमें एक प्रारंभिक निजी समय (private time) होता है। मालिक (owner) निजी उपयोगकर्ताओं को प्रबंधित कर सकता है और शुरुआत में केवल उन्हें ही टोकन प्राप्त करने की अनुमति होगी। एक बार एक निश्चित समय बीत जाने के बाद, सभी को टोकन का उपयोग करने की अनुमति होगी। यदि आप उत्सुक हैं, तो हम नए ओपनजेपेलिन (OpenZeppelin) अनुबंध v3 से _beforeTokenTransfer (opens in a new tab) हुक का उपयोग कर रहे हैं।

pragma solidity ^0.6.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract PrivateERC20 is ERC20, Ownable {
    mapping (address => bool) public isPrivateUser;
    uint256 private publicAfterTime;

    constructor(uint256 privateERC20timeInSec) ERC20("PrivateERC20", "PRIV") public {
        publicAfterTime = now + privateERC20timeInSec;
    }

    function addUser(address user) external onlyOwner {
        isPrivateUser[user] = true;
    }

    function isPublic() public view returns (bool) {
        return now >= publicAfterTime;
    }

    function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual override {
        super._beforeTokenTransfer(from, to, amount);

        require(_validRecipient(to), "PrivateERC20: invalid recipient");
    }

    function _validRecipient(address to) private view returns (bool) {
        if (isPublic()) {
            return true;
        }

        return isPrivateUser[to];
    }
}

और अब आइए इसे मॉक करें।

pragma solidity ^0.6.0;
import "../PrivateERC20.sol";

contract PrivateERC20Mock is PrivateERC20 {
    bool isPublicConfig;

    constructor() public PrivateERC20(0) {}

    function setIsPublic(bool isPublic) external {
        isPublicConfig = isPublic;
    }

    function isPublic() public view returns (bool) {
        return isPublicConfig;
    }
}

आपको निम्नलिखित त्रुटि संदेशों (error messages) में से एक मिलेगा:

• PrivateERC20Mock.sol: TypeError: Overriding function is missing "override" specifier.
• PrivateERC20.sol: TypeError: Trying to override non-virtual function. Did you forget to add "virtual"?.

चूंकि हम नए 0.6 Solidity संस्करण का उपयोग कर रहे हैं, इसलिए हमें उन फ़ंक्शंस के लिए virtual कीवर्ड जोड़ना होगा जिन्हें ओवरराइड किया जा सकता है और ओवरराइड करने वाले फ़ंक्शन के लिए override जोड़ना होगा। तो आइए उन्हें दोनों isPublic फ़ंक्शंस में जोड़ें।

अब अपने यूनिट परीक्षणों में, आप इसके बजाय PrivateERC20Mock का उपयोग कर सकते हैं। जब आप निजी उपयोग के समय के दौरान व्यवहार का परीक्षण करना चाहते हैं, तो setIsPublic(false) का उपयोग करें और इसी तरह सार्वजनिक उपयोग के समय का परीक्षण करने के लिए setIsPublic(true) का उपयोग करें। बेशक हमारे उदाहरण में, हम समय को तदनुसार बदलने के लिए टाइम हेल्पर्स (time helpers) (opens in a new tab) का भी उपयोग कर सकते हैं। लेकिन मॉकिंग का विचार अब स्पष्ट होना चाहिए और आप ऐसे परिदृश्यों की कल्पना कर सकते हैं जहां यह केवल समय को आगे बढ़ाने जितना आसान नहीं है।

कई अनुबंधों को मॉक करना

यदि आपको हर एक मॉक के लिए एक और अनुबंध बनाना पड़े तो यह अव्यवस्थित हो सकता है। यदि यह आपको परेशान करता है, तो आप MockContract (opens in a new tab) लाइब्रेरी पर एक नज़र डाल सकते हैं। यह आपको तुरंत (on-the-fly) अनुबंधों के व्यवहार को ओवरराइड करने और बदलने की अनुमति देता है। हालाँकि, यह केवल किसी अन्य अनुबंध पर कॉल को मॉक करने के लिए काम करता है, इसलिए यह हमारे उदाहरण के लिए काम नहीं करेगा।

मॉकिंग और भी अधिक शक्तिशाली हो सकती है

मॉकिंग की शक्तियां यहीं समाप्त नहीं होती हैं।

• फ़ंक्शंस जोड़ना: न केवल किसी विशिष्ट फ़ंक्शन को ओवरराइड करना उपयोगी है, बल्कि केवल अतिरिक्त फ़ंक्शंस जोड़ना भी उपयोगी है। टोकन के लिए एक अच्छा उदाहरण केवल एक अतिरिक्त mint फ़ंक्शन होना है ताकि किसी भी उपयोगकर्ता को मुफ्त में नए टोकन प्राप्त करने की अनुमति मिल सके।
• टेस्टनेट्स (testnets) में उपयोग: जब आप अपने विकेंद्रीकृत एप्लिकेशन (dapp) के साथ टेस्टनेट्स पर अपने अनुबंधों को तैनात करते हैं और उनका परीक्षण करते हैं, तो एक मॉक किए गए संस्करण का उपयोग करने पर विचार करें। जब तक आपको वास्तव में आवश्यकता न हो, फ़ंक्शंस को ओवरराइड करने से बचें। आखिरकार आप वास्तविक लॉजिक का परीक्षण करना चाहते हैं। लेकिन उदाहरण के लिए एक रीसेट फ़ंक्शन जोड़ना उपयोगी हो सकता है जो अनुबंध की स्थिति को शुरुआत में रीसेट कर देता है, किसी नई तैनाती की आवश्यकता नहीं होती है। स्पष्ट रूप से आप इसे मेननेट (Mainnet) अनुबंध में नहीं रखना चाहेंगे।