ic-repl is the other alternative that I’m aware of that works with the Dfinity suite of ic_cdk and connected packages
But the thing is writing separate scripts in a somewhat limited scripting language when we could utilize Rust’s fantastic compiler is kinda disappointing.
Since ic-repl is written in Rust, I believe the internal modules could be decoupled to be called by the ic-repl CLI and be used from a Rust codebase as an integration testing framework.
That way we can write tests in our Rust codebase and co-locate them with our application code but with a #[cfg(test)] so that tests get run within their own binary like how native Rust tests are supposed to run and then only our application code gets compiled to wasm canisters as intended.
Under the hood, ic-repl uses the ic-agentcrate, which does have a lot of the compiler support you’re looking for. Have you tried that already? And if so, why do you think it’s not appropriate for your use case?
Basically I’m working on a large multi-canister backend with multiple cross canister calls and have reached the stage where simple UI based testing won’t cut it and the codebase needs unit and integration tests. Trying to figure out what’s the most modern prescripted way of doing it for canisters written in Rust
I see. Long story short: tooling is not at a point yet where we have really good solutions for larger projects. If it’s doable for you, ic-kit is probably the most advanced thing out there for now. Besides that I can only recommend that you do as much as possible in unit tests since testing integration is not really in a nice place.
Outside of ic-kit, the best I can offer right now is to write tests with ic-agent against a running dfx instance, but that’s also not ideal. If you find a better solution, please let us know so we can document it properly.
