Good practice testing structure for a rust project

I want to test stuff.

So the way I see it I have 3 options to pick from and would like to know what is usually used and what is a good practice and why. I can:

  • Write rust unit tests - tests in the same file as the thing they’re testing (I don’t like this because it doesnt make sense for my canister to have the tests)
  • Write integration tests in rust in a separate folder (package). But here I don’t know what libraries to use to make authenticated calls, to fake being a certain account (which is equivelent to mocking an address in evm) or maybe even to run an local IC through rust (I’m not sure if it helps or not).
  • Write tests in another project entirely that call my IC instance. For example using js or something else that is completely separate from my rust environment.

Any help is appreciated

For the integration test, you can use pocket-ic.

With it, you can write tests in Rust—for example, here is the suite of OISY’s backend—but also in various other languages such as JavaScript with pic.js as for example, here is the test suite of Juno.

I don’t know if it’s the best practice, but I believe this is a good approach to scope the tests for your backend.

If in addition you also want to add some E2E tests because you have both a frontend and a backend that runs on an IC instance, a handy plugin to automate sign-in with II is the internet-identity-playwright.

3 Likes