Testing tickets
Testing tickets requires some extra steps.
The problem with testing tickets
The Mavryk protocol has two types of operations:
- Internal operations are created from inside the chain, such as by smart contracts.
- External operations are created from outside the chain, such as by the Mavkit client, other Mavryk clients and SDKs, and in the context of LIGO testing, by functions such as
Test.Next.Originate.contract. For more information about the technical implementation, see Semantics of smart contracts and transactions in the Mavkit documentation.
In the protocol, both external and internal origination and transfer operations contain a piece of michelson code representing the initial storage for the origination or the parameter for the transfer.
Now imagine you have a value of type parameter_ty/storage_ty containing a ticket, that you want to transfer or originate,
in the operation data, tickets will be represented in Michelson as pairs:
ticketer address , ticket value , ticket amount
If we try to apply such an operation, the type wouldn't match: ticket of bytes VS some pair. The protocol would not let you do that since you could be creating a ticket out of nowhere unless the operation happens to be forged from within a contract (i.e. "internally")!
In the testing framework - for now - it means using "proxy-contracts" forging the operations using provided a ticket value and a ticket amount.
Proxy ticket contracts
The LIGO standard library provides a Proxy_ticket module which helps in working with tickets in the Testing framework. Here is the interface of Proxy_ticket:
init_transfer accepts:
- a function
mk_paramwhich given a ticket must return a value of your parameter type
and returns the typed address of a "transfer proxy-contract" which can then be used to do multiple transfers of tickets with the same ticketer address
transfer accepts :
- the typed address of a "transfer proxy-contract"
- the ticket information (value and amount) together with the destination address
and returns a value of type test_exec_result
originate accepts:
- the ticket information (value and amount)
- a function
mk_storagewhich given a ticket must return a value of your storage type - your contract (having a ticket in its storage type)
Note: Functions
mk_paramandmk_storagewill be executed in the proxy contract itself
Find more detailed information on the API of Proxy_ticket here
Usages
Transfer
Here is an example using Proxy_ticket.init_transfer and Proxy_ticket.transfer:
- import the module above as
Proxy_ticket - define a contract
Cholding a ticket of string in its parameter type. The contract will just store the value of the received ticket and the address of the sender - originate contract
C - initialize a "transfer proxy-contract" providing a function to build a parameter out of a ticket
- transfer a ticket with a value
"hello"and an amount of10to contractC - print the storage of contract
C - transfer a ticket with a value
"world"and an amount of5to contractC - print the storage of contract
C
result:
Note: note that the sender (stored in the contract) matches the address of the proxy contract
Origination
Here is an example using Proxy_ticket.originate and the type unforged_ticket :
- import the module above as
Proxy_ticket - define a contract
mainpotentially holding a ticket of bytes in its storage. The contract will just reads the ticket in its storage if present. Note that we define two version of the contract storage type: one for the contract and one for the storage type that we would like to manipulate in our testing logic - we define the
mk_storagefunction which simply wraps a ticket into an option type - we define the ticket information for a ticket of value
0x0202and an amount of15 - we call
originateand retrieve the address of the newly originated contract - we use the address to fetch the current contract storage using
Test.get_storage_of_addressand decompile it as ahuman_storage - we read the content of the ticket and perform a series of assertions
result: