dpaiton
commented
8 months ago I'd like to point out that (I think) all of this has been implemented in the Python IHyperdrive class. That might adjust your perceived priority on updating the test-utils if we can run equivalent tests in Python already. I'd be happy to meet to elaborate further (this should also include @slundqui).
This also brings up a meta discussion that we should have on differentiating the python & rust feature sets. While it makes sense for there to be parity in many areas (e.g. everything that we wrap via hyperdrivepy), there are other areas where we should take care to avoid duplicate work. That being said, I realize that testing in particular might require duplicates since we want most tests for rust fns to live in rust.
jalextowle
A major area of technical debt in the Rust codebase is the
test-utilscrate. The abstractions that are currently being used are brittle and hard to work with. They don't lend themselves well to working with a remote chain, and they are tightly coupled to a deployment that usesanvil. TheAgentstruct and methods leaves things to be desired and is an area that could be improved. The major areas to improve are:Chainabstraction so that it works equally well for local and remote deployments. We may not even need something like theChaintrait, and we may be better off working with a set of orthogonal tools that we can use to buildether-rsclients with signer, nonce management, and error handling middleware that makes it trivial to get a provider, signer, and client set up for an arbitrary chain with arbitrary signer metadata.DevChainabstraction. Instead of tightly coupling address lookups to aDevChainstruct, it would be better if this was a utility that could be called to read from the artifacts server. That way we could mix and match test utils regardless of whether we are interacting with a local anvil chain or aninfradeployment.TestChainabstraction. Instead of tightly coupling pool deployment to aTestChainstruct, it would be better to have separate deployment functions that make it easy to deploy the factory, deployer coordinators, and pools. It would be nice to still have an integrated deployment flow (we'll still need this to build the docker images), but this should be more flexible. The benefit of doing this is that it would make it easier to testhyperdrive-mathwith many different pool configurations.Agentstruct. This struct is straddling the line between a tool that could actually be used to write trading bots and something that is only useful for testing. Some important logic is held in this struct (like the logic surrounding getting a conservative price forget_max_short) that should be upstreamed tohyperdrive-math. Generally speaking, we should just clean this struct up and make sure that it is well-tested and fully-featured.