Testing tickets
Testing tickets requires some extra steps.
The problem with testing tickets
The Tezos 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 Octez client, other Tezos 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 Octez 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_param
which 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_storage
which given a ticket must return a value of your storage type - your contract (having a ticket in its storage type)
Note: Functions
mk_param
andmk_storage
will 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
C
holding 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 of10
to contractC
- print the storage of contract
C
- transfer a ticket with a value
"world"
and an amount of5
to 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
main
potentially 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_storage
function which simply wraps a ticket into an option type - we define the ticket information for a ticket of value
0x0202
and an amount of15
- we call
originate
and retrieve the address of the newly originated contract - we use the address to fetch the current contract storage using
Test.get_storage_of_address
and decompile it as ahuman_storage
- we read the content of the ticket and perform a series of assertions
result: