fiery eagle
One of the testing methods used commonly in the EVM ecosystem is "Fork Testing". Basically you fork a live network and can then interact with real data in a sandboxed environment. How would one approach this in Stellar? Can quickstart be scripted to do something similar?
Reference from hardhat: https://hardhat.org/hardhat-network/docs/guides/forking-other-networks
vale radish
I think that this would currently require building the ledger object from a ledger snapshot. I think that the tooling to do this (partially) exists but it's probably non-trivial. It seems that this is something the soroban-test tool aims to provide this but the feature is not there yet ("Provides a way to run tests aganist a local sandbox; running against RPC endpoint coming soon.")
sinful violet
This is normally v fast too, and often they cache a somewhat recent fork so it doesn't need to be reloaded from the RPC each test run. Using quickstart seems a little overboard because you wouldn't need horizon, and maybe not even your own RPC.
fiery eagle
@vale radish @sinful violet you both think this should belong in soroban-test or as a potential new independant tool?
sinful violet
What is soroban-test? not sure I am familiar
vale radish
Yep, generally speaking, I'd love to see a crate that provides utils to capture a ledger snapshot from futurenet. It would inspire to build lots of interesting tools imo
fiery eagle
What is `soroban-test`? not sure I am familiar
fiery eagle
Yep, generally speaking, I'd love to see a crate that provides utils to capture ...
I suspect that populating a sandbox from a live ledger is going to require quite a lot of dev work. Forking a network, while less composable, might be a lower hanging fruit
@safe vector @trail horizon curios if you have any thoughts on this
vale radish
yeah i was just about to say that
trail horizon
Some dev work, not a million hours though. This is basically what soroban-rpc does when it launches. We would need to port that piece to rust (ideal, but difficult) or do some awful hacks (needs some thought)
vale radish
I'm thinking that the use case here is primarily allowing for rust tests for contracts that resemble an on-chain interaction @fiery eagle?
fiery eagle
I'm thinking that the use case here is primarily allowing for rust tests for con...
The idea would be integration testing with existing data. This becomes more relevant as the ecosystem matures and new contracts integrate with previously deployed ones
sinful violet
It's also the only way to test contracts with hardcoded values like the mainnet USDC address (wether or not ppl agree this is a good practice, it is done in other ecosystems and I imagine it will be done here)