Open spencewenski opened 5 months ago
The main thing we would need to add support for probably is cleaning up the db after tests.
What’s the best way to allow tests to be parallelized while also cleaning up the db between tests? Is there a way to track which tables are modified and/or which rows are added? Also, as a best practice, ids of rows added during tests should be random, so ideally if we’re able to track which ids are created by a test we can delete just those ids.
It looks like seaorm also allows mocking the db, which may cover our use cases. It may also allow us to run tests without needing a running Postgres instance. Though, it still might be good to have some sanity tests against an actual pg instance, and maybe we would want to run all tests against an actual pg instance still. Tbd
Could we create something like rspec’s let
that lazy inits db models and cleans them up when they’re dropped? Or does something like that exist already?
Not related to the previous comment, this could be interesting: https://github.com/rust-rspec/rspec
looks like it hasn’t been updated in a while though. I wonder if it’s still maintained and/or if it’s considered done/stable.
Also interesting: https://crates.io/crates/shoulda
Factoybot for rust: https://crates.io/crates/factori
I’m not sure I love the ergonomics of this, but if the mixin fields have typechecking/autocomplete, then it could be interesting
Can we allow using in-memory SQLite for tests? We’d probably want to provide a way to switch between SQLite and a real db on a per test or per group basis somehow
Some testing utilities (mainly related to using insta
and rstest
) were added in https://github.com/roadster-rs/roadster/pull/277