Now that the contract is finished and implemented, all that's left to do is deploy it. Though we would also suggest writing some tests to make sure it's working as intended. This subchapter will explain how to do both.
Generating the ABI
We have a tool that is compiled with the project that generates the ABI of your contract. Its executable is compiled from the src/bins/contractabigenerator/main.cpp file, with the following code snippet by default:
Compile the project and run ./contractabigenerator. All of your Dynamic Contracts registered in src/contract/customcontracts.h (in the ContractTypes tuple shown earlier in the previous step) will have their ABIs generated inside the ABI folder, as <ContractName>.json.
If you want a finer control of which ABIs you want to generate, replace ContractTypes with the exact names of the contract classes that should be generated:
The ContractManager contract will always have its ABI generated in both cases, as it is a vital part of the project.
Deploying the Blockchain
Go back to the project's root, compile and deploy the blockchain by running ./scripts/AIO-setup.sh. See "Setting up the development environment" for more information. Your contract should be initialized alongside the blockchain, ready to be interacted with.
Testing the Contract
We use the catch2 framework to test our project as a whole, so it is expected to have at least a little bit of familiarity with how it works (it's pretty easy!).
For testing contracts specifically, we have developed our own test suite called SDKTestSuite, in tests/sdktestsuite.hpp (the .cpp file is for testing the test suite itself). Using this test suite is highly recommended, as it simulates the environment of the blockchain (e.g. creating blocks, advancing the chain, taking care of the state and its variables, etc.) to make sure contracts are behaving the way they would in the actual deployed blockchain. Check the Doxygen docs, as well as the contract test files in the tests/contract subfolder, for more information on how to use the test suite.
First, create a new file in the tests/contract folder with the name of your contract - in our case, tests/contract/simplecontract.cpp (which already exists as it is part of the project).
Then, add the file to the tests/CMakeLists.txt file:
Keep in mind that we're not accessing the contract directly, we're interacting with it through SDKTestSuite, and that requires us to parse its inputs and outputs accordingly.
In order to run your tests, compile the project as you normally would, and then run ./src/bins/orbitersdkd-tests/orbitersdkd-tests -d yes [simplecontract] from within your build directory. The [simplecontract] tag forces only these specific tests for SimpleContract to run (this is set in the TEST_CASE() lines in the example above). The -d yes flag makes it more verbose, showing exactly which test case is being run at the moment.
As a bonus, even though this whole chapter is focused on precompiled contracts, the SDKTestSuite also has a function that can deploy a contract's bytecode directly, called SDKTestSuite::deployBytecode(), which takes a Bytes object as a parameter that represents the contract's bytecode.