PlatON Network

Recall that in the last issue we explained the introduction of automation testing related to PlatON, this time we will explain what testing work is done in PlatON for smart contracts. First of all, we need to understand what a smart contract is, essentially, a smart contract is a piece of program that automates the processing of traditional contracts in the form of computer instructions. In simple terms, a smart contract is a piece of code that triggers the execution of a transaction between two parties on a blockchain asset. So here are a few questions to illustrate PlatON’s smart contract testing. This is the third part of the article.

Smart contract coverage testing scope

For each version of PlatON, we validate it against contract-related, and the validation covers the following four main directions.

Basic operator test contracts

function add(uint a, uint b) internal pure returns (uint c) { 
 c = a + b; 
 require(c >= a, “SafeMath add wrong value”); 
 return c; 
} 
function sub(uint a, uint b) internal pure returns (uint) { 
 require(b <= a, “SafeMath sub wrong value”); 
 return a — b; 
}

Verification of PlatON’s support for these bases is achieved by writing test contracts in which logic code for operators, such as arithmetic operators, comparison operators or logical operators, is written, and then invoked by compiling and deploying them.

Contract Types

EVM Test Contracts

string public constant name = type(TypeName).name;

function getContractName() public returns(string memory contractName){ 
    return name; }

WASM Test Contracts

ACTION void clone_contract(const Address & contract_address){ 
    auto info = platon_create_contract(contract_address, 0U, 0U); 
    if(info.second) set_state("clone", info.first); 
}

PlatON chain supports both EVM and WASM contracts, so we also need to cover syntax, method and data type test cases for the two different contract types in the testing process to ensure that the expected test results are achieved in both contracts.

PlatON built-in contract calls

function assemblyCallppos(bytes memory data,address addr) public {
    uint256 len = data.length; 
    uint retsize; 
    bytes memory resval; 
    assembly {
        let result := delegatecall(gas(), addr, add(data, 0x20), len, 0, 0)
        retsize := returndatasize()
    }
    resval = new bytes(retsize); 
    assembly { 
        returndatacopy(add(resval, 0x20), 0, returndatasize()) 
    } 
    returnValue = resval;
}

In addition to supporting external contract calls, we also write test contracts to call PlatON’s economic model business code during testing to verify that the RPC interface to PlatON can be called properly via external contracts.

Compiler Version Adaptation

As smart contracts evolve over time, different versions of compilers are released, and PlatON needs to adapt each version to the compilers that have been released to ensure that contracts compiled by users using different compiler versions can be deployed to the chain properly.

Thinking about follow-on optimization

At present, the JUnit testing framework is too cumbersome for our testing team to use in the testing process, and we need to invest some manpower to fix the maintenance scripts, review the historical data and spend a lot of effort on script modification during the version iteration. After discussion and research by the internal testing team, and in order to align with the economic model automation, we will consider porting the existing smart contract automation and redeveloping it in python to simplify the process of generating java wrapper classes. Users will be able to have a clearer understanding of the entire contract invocation process, while python is also a relatively dominant language for testing, allowing more testers to participate in enriching the automation content.