Add contract test CLI

[mattgeddes]

Hey @andrewvious and @eureka-cpu . Here's another bit of code we can play with.

I'll put together a pull request for some changes to the wasm_cli crate to parse some new command line subcommands and options to aid developers in testing their smart contracts in isolation. I'll just create the CLI stubs and fill those in with specific details around what I want the code to do for each command. This'll be a change from previous tasks because you'll largely be writing new code rather than just modifying existing code, which I thought might be fun (and very helpful).

Essentially, the bits of code you'll be adding will manipulate some local state. I was thinking a simple sqlite3 database, but I'm open to anything. It'll just be a couple of tables -- one containing some fake accounts (addresses and balances) and one with some other metadata. The other thing we'll do use the wasm_runtime crate to execute a smart contract similar to the way that the execute subcommand works today (with some differences).

I'll include very specific details in the code for what we need in each case. That should make it easy to find (I'll take it with the bug number) and easy to fill in.

[mattgeddes]

Tagging @andrewvious again to see if that causes him to appear in the assignee list.

[andrewvious]

Tagging @andrewvious again to see if that causes him to appear in the assignee list.

Tagging myself to see if I can appear for the assignee list.

[mattgeddes]

Hey @andrewvious

I just pushed some changes to the feat-test-cli branch. I was trying to get clever with clap, but apparently I'm not as clever as I thought, so I took the easy path for now 🙂 .
There's three main pieces of functionality I think we want to fill in, and you'll find specific details all tagged with '#716' in the code (to match issue #716 in github). The pieces are:

1. To initialise a new database in the inittestdb/mod.rs file's run() function. I think the BonsaiDB project fits the bill, and I've described the two small database tables we want in the comments of that module. All of the command line args you need should be passed in (location of the DB file, whether to force it, default balance, etc).
2. To fill in the assertbalance subcommand to do a query for an account in the database and to return success if its balance is the same as specified on the command line (options exist in the CLI). If the balance doesn't match, spit out a clear error message on stderr and exit with a failure.
3. Finally, the most complex. Given the arguments to the test module:
   1. Execute the specified function in the specified WASM module with the full JSON input (see versatus-rust repo for examples) with the inputs coming from the database and from the arguments passed in on the CLI. The execution side of things is partially there, so it should just be some database queries and a call or two to serde.
   2. For any function that succeeds, apply the result to the database. For example, if the transfer function is called and returns a transferEvent, move the balance in the database from one account to another.

I may rename those subcommands to make them more consistent with each other...

What we'll end up with is a set of command line subcommands that will allow a developer to script the testing of their smart contract locally, including the state. We'll tie it to ERC20 for now, but make it generic later. Here's a skeleton of what such as test script might look like once we've filled in the above:

versatus-wasm init-test-db --dbpath ./test-state --default-balance 1000 || die "Test failed"
versatus-wasm assertbalance --dbpath ./test-state --address "0xdeadbeef" --value "1000" || die "Test failed"
versatus-wasm test --dbpath ./test-state --wasm ./contract.wasm --function "transfer" --inputs '{ "address": "0xdeadbeef", "value": "100" }' || die "Test failed"
versatus-wasm assertbalance --dbpath ./test-state --address "0xdeadbeef" --value "1100" || die "Test failed"

The first two are probably the easiest to implement, and the third will likely be a little more fiddly. You'll likely import the versatus-rust crate from github for the data structures. We can go through the details of any of this as needed. I'll also try and copy/paste this message into github for posterity.

How does that sound?

[mattgeddes]

This work was done to spec, but other forces mean work to be done to have this in main. Moving out of alphanet milestone and we'll come up with a plan for integrating the new stuff.