by Qingmingzi@NEL

Recently I’ve been doing an NNS contract testing tool. The goal is it’s simple and easy to use, suitable for non-technical personnel testing while developing fast and implementing fast. After writing it, I found out that isn’t a NEO smart contract black box testing framework? so I would like to write an article to share it with everyone.

The code platform I selected is C#. It’s separated into two parts: the display and logic processing. The logic part is written with netstandard2.0 (supporting both .net framework 4.6.1 and above and .net core 2.0). The UI is first done with the .net framework desktop program. I will do a few simple examples with .net core 2.1 in the future if time permits.

The biggest difficulty in testing a smart contract is to construct a contract to invoke a transaction. This work is difficult for non-smart contract developers, not to mention non-developers.

However, with the complexity of NEO smart contracts (such as NNS’s auction registrar contract), the increase in the amount of assets managed within the contract, plus the developers’ own thinking dead ends. The contract black box testing rapid implementation tool for the non-technical staff of is indispensable. This issued needs to be addressed.

In the past, if a rookie NEO developer wants to test the contract, he could only use NEO’s GUI debugging contract function or construct RPC to call the CLI, but they are very inconvenient to use, especially when there are multiple contract methods and they’re related to each other.

Fortunately, NEL recently released Neo_SDK_Thin (https://www.nuget.org/packages/neo.sdk.thin/), which implements NEO’s core methods such as private and public key calculations, various format conversions, script constructs, and transaction constructs separately. It is implemented without relying on block synchronization. This is a very useful tool and the project mentioned in this article also relies on it. But this is still a long way from the quickly debugging the contract. UTXO information that is essential for constructing a transaction is still lacking. How to construct a transaction using the trading class of Neo_SDK_Thin is still difficult for beginners, and it is still not convenient to view the results after the transaction is deployed.

Therefore, I am here to recommend this testing framework to everyone. I hope it could help everyone start smart contract debugging faster and more comfortable.

Key points of the framework:

Construct the nelApiHelper class to facilitate the use of the NEL series of utility APIs (only relevant parts of the contract call)

Constructing the neoHelper class and extending some functions based on Neo_SDK_Thin

HexStr converted to Str, HexStr flip, HexStr turn value, large integer precision adjustment, etc.

Jarray2script method, constructing a Jarray form of the parameter that will be input into the contract, a one-click output of contract call script

neoAddress class, enter WIF, you can automatically construct the address, public key, the private key

neoTranstion class, currently implemented integration methods, such as ordinary transfer transactions and contract call transactions, one-click construction, signature, and sending to the chain.

Construct the contractOperate class, the base class for fast contract calls

A simple and convenient integrated black box contract test interface framework (may not look nice currently)

In fact, you can see that by replacing the contract function area, you can quickly provide a black box test tool for any contract. Looking at the project code, you can see that there are few codes in the contract function area.

Obtain contract information class methods, such as NEP5 balanceOf (only need to send a transaction to invokeScript)

Execute contract function methods, such as NEP5 transfer (need to be sent to the chain)

For these methods, the part you write yourself can be completed in only 2–3 lines of code and the construction of an input of the parameter into the contract is a process of editing json.

At the same time, after the transaction is sent, the txid is thrown into the txid temporary storage area. After the new transaction, the applicationLog related to the transaction will be automatically loaded, and the important information such as the result of the contract method, the consumption of gas, and the notification triggered by the contract can be viewed in a one-stop way.

Of course, this is not the final version, but more will be added later:

Transaction structure to add the network fee function

Implementing complex call transactions such as CGAS involving and UTXO and NEP5 asset exchange contracts.

It is easier to use the nuget of the framework’s generic class.

xxx, etc.

Finally, here is the code address (originally developed for the NNS test, don’t care about the name):

PS: If you just want to use the NNS related contract methods in your project, you can use nuget directly.