#Approaches to Testing

1 messages · Page 1 of 1 (latest)

timber apex
#

blob_dance I'm looking for more insight into how folks are testing their contracts, and what testing methodologies they're using, or wanting to use and aren't sure how to in Rust or Soroban.

The testing docs already cover a few approaches:

https://developers.stellar.org/docs/build/guides/testing

There are docs there about:
• Unit Tests
• Mocking
• Testing Authorization
• Testing Events
• Integration Tests
• Integration Tests with Mainnet Data
• Fuzzing
• Differential Tests
• Differential Tests with Test Snapshots
• Mutation Testing
• Code Coverage

Do you have other approaches to testing that you use and don't see it?

I'd love to hear from you so that we can make the docs better. ferrisPray

Contract Testing | Stellar Docs

Testing Stellar Smart Contracts

#

Cross-posted to #🔹｜developer-chat message

woeful epoch
#

This is a very comprehensive and rigorous testing Pyramid.

It definitely reinforces the idea that smart contract development is closer to firmware embedded programming then it is to web dev.

There's no feature flags or rollbacks on-chain! The cost of failure can be total for many protocols going to mainnet.

My questions would mostly be around how automated testing can simulate the risk of something like a sophisticated actor executing various Oracle attacks

#

Or risks present in front-end clients using insecure or compromised dependencies.

But I'm not sure if that is within the scope of this discussion

gaunt hornet
#

Some extras that come to mind:

  • CI (and CD) topics. Also nightly/weekly builds for deps changes
  • Testing storage (and timing specific tests related to that, but maybe that's what you mean with differential)
  • Cost optimization and regression on it
  • Testing with dependencies on other contracts (can be tricky to get things up and running, etc.).
  • Audits/pentesting might have a place in that section.
timber apex
#

Great ideas, thanks. I can add some of these.

#

The integration pages discuss testing with dependencies. Maybe I should make that clearer. Or do those pages need to go further? @gaunt hornet What’s missing?

gaunt hornet
# timber apex The integration pages discuss testing with dependencies. Maybe I should make tha...

Thanks I did not know that page! This has all the info I personally need. Would be handy if there was some way to have a hook for the fetch directly from soroban_sdk::contractimport! (in tests)
In the CI section otherwise the fetch could be shown with some discussions around best practices to define deps. I am still unsure what to do here. Ideally I would like to be able to define a contract as any other Rust deps in the cargo.toml.

gaunt hornet
#

@timber apex I was just thinking. There is also some things to say about the integration tests with a frontend I think. Slightly out of scope but it's at the intersection so I thought I would point it out as, unless I missed it, I did not see UI tests calling contracts in the doc.

timber apex
gaunt hornet
#

Also TIL that there was this test_snapshots folder 🙀 This is so cool.

timber apex
#

A contract ID isn't sufficient to make the build reproducible, because contract's can upgrade their wasm.

#

So at least a wasm hash is needed.

#

It also needs an RPC config to collect it. We could have it use the stellar-cli on the command line, and assume it is installed and use the stellar-cli config. But that seems not a great experience if someone doesn't have it installed. Or has the wrong version installed.

#

It could accept an RPC config as inputs, but then that RPC might only be available with authentication credentials, which then means that needs configuring as a secret / env var in CI.

#

Anyway, it unravels as you see!

#

Contracts don't actually take up much storage space, which is why there's a CAP proposing to store them all in memory.

#

If there was a host that stored them all, indexed by their hash, then the SDK could download them from there as needed, rather than from the network. The SDK could check the wasm matches the hash so that the host is relatively untrusted.