search

eigerco / nebula

A soroban contract library
https://nebula.eiger.co
Apache License 2.0
7 stars 2 forks source link

E2E testing tools for Soroban contracts #34

Closed eloylp closed 1 year ago

eloylp commented 1 year ago

Context

During the development of the first smart contracts, we manually tested them in Futurenet

As we can observe in the above manual tests, the CLI code is able to interact with Futurnet. That could provide some inspiration.

Futurenet is currently the only environment that runs the Soroban smart contract platform. Its in continuous change. Thats also an extra motivation for having e2e tests.

Goals

To be able to write a fairly efficient e2e tests suite that works in Futurenet , capable of running in a CI.

eloylp commented 1 year ago

On my mind, happy path, it would be great to have a set of Rust declarative macros to easen this kind of tests :thought_balloon:

mariopil commented 1 year ago

When I was in Hooks I've developed a test framework for Hooks contracts that was using standalone XRP server. Maybe it could be useful here. https://github.com/eqlabs/hooks-test-framework

eloylp commented 1 year ago

When I was in Hooks I've developed a test framework for Hooks contracts that was using standalone XRP server. Maybe it could be useful here. https://github.com/eqlabs/hooks-test-framework

@mariopil i cannot access such repo :cry: probably permissions. But from what you comment, looks thats the idea :D

mariopil commented 1 year ago

Try now - I've gave you and @geofmureithi both read permissions.

mariopil commented 1 year ago

Oh, seems I can only add one of you to the repo...: You must purchase at least one more seat to add this user as a collaborator. [Add seat](https://github.com/organizations/eqlabs/settings/billing/seats?seats=1)

eloylp commented 1 year ago

When I was in Hooks I've developed a test framework for Hooks contracts that was using standalone XRP server. Maybe it could be useful here. https://github.com/eqlabs/hooks-test-framework

I like the idea ! On my mind that would be like having a sofisticated table driven test, in which adding new cases is very easy. That would reduce a lot all the boilerplate code (testing infrastructure related code), which would be practically the same on each test. Leaving the developer to only care about the logical part of the test. Also, the testing code infrastructure could get improved and versioned. So my vote on looking into that :+1:

Said that, i also think we are in a very early stage. I think would be good to check the state of the art regarding as we commented :)

We are going to build 3 new contracts at #35 , i would start organically from there, gaining experiences with low level "rust ways" of encapsulating this code infrastructure, that would be the building blocks for such a testing framework IMO. We could even leave open such low level building blocks for the community to build on top of them :D . Please feel free to use this issue as communication hub for sharing your experiences in code.

So yeah, IMO lets organically build the low level tools heading :boat: to the testing framework :rocket:

geofmureithi commented 1 year ago

Soroban comes with alot of commands inbuilt. We can steal ideas from cargo make:

[tasks.init]
command = "init"
args = ["addr", "--", "MYPRIVATEKEY"]

[tasks.create_proposal]
command = "create_proposal"
args = ["id", "1"]

[tasks.vote]
command = "vote"
args = ["param1", "param2"]
dependencies = ["create_proposal"]

[tasks.flow]
dependencies = [
    "init",
    "create_proposal",
    "vote"
]
geofmureithi commented 1 year ago

Additionally, soroban-cli has a run_in_sandbox method that simulates an rpc server. https://github.com/stellar/soroban-tools/blob/13ee0d59fd77d06b983e37b42d6ed418acbb1f2c/cmd/soroban-cli/src/commands/contract/deploy.rs#L132

eloylp commented 1 year ago

@mariopil is this of interest for parsing transactions ? https://docs.rs/stellar-xdr/0.0.17/stellar_xdr

mariopil commented 1 year ago

Rather no currently. I'm using js as it seems that the js SDKs are most up to date.

eloylp commented 1 year ago

Rather no currently. I'm using js as it seems that the js SDKs are most up to date.

Yeah, thats true. In the other hand i feel we could be missing an opportunity to contribute to Soroban maybe ? Sorry i probably do not have enough context. What are the main blockers you have found for not doing it in Rust ? Apart everything is pre-release :grin:

mariopil commented 1 year ago

I could only parse properly xdr results using the js SDK. And not even the StellarSDK, but had to use SorobanClient one. The tool still uses soroban client for most of the tasks (deploy contract, invoke methods, etc.)