How to mock Entity Loader-type queries? (Or, examples on how to mock complex relationships?)

[sunarisunz]

Hi all,

so, first question, is it even possible? Looking at the documentation I only see examples of mocking the results of simple find_by_* and find_related queries, but I had no luck trying to mock relatively complex relationships with Entity::load. Any advice/examples welcome, I am at a loss here.

edit: answer marked, thanks! tldr until/unless the developer experience for the mocking API improves a bit, you might be better off Not Doing That™ and just writing your own mocking layer for the unit tests where database logic is not the thing being tested. potentially a lot of boilerplate, but... so is using the mocking API as it is right now, with the upside of being less confusing to use.

[morvayo]

yes but you need to mock each SQL result set rather than the final nested ModelEx

Entity::load can execute several queries so queue their results in order with MockDatabase::append_query_results

joined results need the column aliases selected by the query and collection results need the relation keys

there are mocked load_one and load_many examples here
https://github.com/SeaQL/sea-orm/blob/master/src/query/loader.rs

share your SeaORM version and exact load chain and we can work out the fixtures

[sunarisunz]

Right! I'm using SeaORM 2.0.2, as for my relationships they go something like this:

user <1:1 on user_id> org_membership
org <1:N on org_id> org_membership
user <1:N on user_id> grant
user <1:N on user_id> scope

(pardon my extremely clumsy attempt at notation, if you need the code I can provide it though I would need to clean it up a bit first since it's business code I'm not at freedom to share, however mundane it is)

[morvayo]

no need to share the business code renamed entities and dummy values are enough

with user as the root the 1:1 membership can be joined into the first result set while grant and scope are loaded through separate batch queries whether org is requested through membership also matters

could you share just the anonymized .load().with(...).one/all(...) chain and the mock error? please include the relation attributes for those renamed fields so we can match the query shape and aliases

also the load_one and load_many tests i linked cover the lower level Model Loader rather than a complete Entity::load example the Entity Loader docs show how the joined and batch results are assembled

[sunarisunz]

Right, load is

let user = users::Entity::load()
    .filter_by_email(email)
    .with((organization_memberships::Entity, organizations::Entity))
    .with(client_root_scopes::Entity) // grants and scopes are not necessary here actually
    .one(db_conn)
    .await
    [...]

attributes on users:

    #[sea_orm(has_one)]
    pub membership: HasOne<super::organization_memberships::Entity>,

    #[sea_orm(has_many)]
    pub grants: HasMany<super::grants::Entity>,

    #[sea_orm(has_many)]
    pub client_scopes: HasMany<super::client_scopes::Entity>,

...for memberships:

    pub user_id: String,

    #[sea_orm(belongs_to, from = "user_id", to = "id")]
    pub portal_user: BelongsTo<super::users::Entity>,

    pub organization_id: String,

    #[sea_orm(belongs_to, from = "organization_id", to = "id")]
    pub organization: BelongsTo<super::organizations::Entity>,

...for organizations:

    #[sea_orm(has_many)]
    pub membership: HasMany<super::organization_memberships::Entity>,

...and for scopes:

    pub user_id: String,

    #[sea_orm(belongs_to, from = "user_id", to = "id")]
    pub portal_user: BelongsTo<super::users::Entity>,

Which usually results in: Type Error: A null value was encountered while decoding All fields of nested model are null

[sunarisunz]

my bad, forgot the attributes. edited.

[Huliiiiii]

I agree that the current Mock API doesn't offer a great developer experience. If you have more complex needs, you could look for other mocking solutions or implement your own. In fact, for complex relationships, I'd recommend integration or end-to-end tests rather than mocked unit tests.

[sunarisunz]

Hmmm I did something similar with pretty much anything that requires making HTTP calls, wrap it in an enum that simply uses the mock implementation for #[cfg(test)]. I suppose I could do the same with the entire database.

But yeah at that point maybe we should just focus on integration tests. Not that we weren't gonna do them anyway

[Huliiiiii]

The Mock API relies on the order in which queries return results. This is easy to mock for simple queries, but for complex relationship queries, the order depends on the internal implementation.

[sunarisunz]

Ah crap. Am I right in theorizing future updates or even slightly different ways to express the same query might change that order?

'Cuz if so then yeah, this is a wild goose chase, as nice as the mocking features seemed at first glance ;;

[Huliiiiii]

Yeah, although it's generally stable.

But if you don't rely too heavily on backend-specific features, you can use in-memory SQLite to speed up your tests.

While I don't think it would be difficult to refactor the mock implementation into an in-memory mock database, I don't see much point in doing so. If the goal is to test database behavior, the tests should run on a real database. If the database behavior isn't relevant and only data is needed, mocking the data access layer or repository would be more appropriate.

There are some good blog post on this topic:
https://testing.googleblog.com/2024/02/increase-test-fidelity-by-avoiding-mocks.html
https://abseil.io/resources/swe-book/html/ch13.html?utm_source=chatgpt.com