Is there a need for #[non_exhaustive] in MongoDB Operation Result Structs?

[ricardosc12]

I'm currently writing unit tests for a web service using the Rust MongoDB Driver. As part of these tests, I aim to mock both input and return data without actually querying a database.

However, MongoDB marks its operation result structs as #[non_exhaustive]. This prevents direct instantiation when mocking these structs.

Wouldn't it be beneficial to allow users to handle potential versioning issues themselves in the case of operation results structs?

#[cfg(test)]
mod tests {

    use mongodb::results::UpdateResult;

    use crate::{
        modules::user::{repository::MockUserRepository, service::UserService},
        tests::unit::common::get_user_to_test,
    };

    #[tokio::test]
    async fn check_if_set_session_id_in_user() {
        let mut mock_repo = MockUserRepository::new();

        let mock_update_result = UpdateResult { //cannot create non-exhaustive struct using struct expression
            matched_count: 1,
            modified_count: 1,
            upserted_id: None,
        };

        mock_repo
            .expect_update_one()
            .returning(move |_, _, _| Ok(mock_update_result));

        let user_service = UserService::new(mock_repo);

        let mut user = get_user_to_test();

        user.session_id = None;

        assert!(user.session_id.is_none());

        let result = user_service.check_or_add_session(&mut user).await;

        assert!(result.is_ok());
        assert!(user.session_id.is_some());
    }
}

https://stackoverflow.com/questions/78760352/handling-non-exhaustive-structs-in-rust-unit-tests-with-mongodb-and-axum?noredirect=1#comment138862853_78760352

[isabelatkinson]

Hey @ricardosc12! #[non_exhaustive] is required for future-proofing against possible field additions, although I understand that this makes it challenging to mock results. RUST-1891 was filed by another user to add Default to these structs to make it possible to construct them outside of the crate. This likely won't be prioritized by the team in the near future, but we'd be happy to review a PR if you'd like to work on this yourself!

[ricardosc12]

Thank you for your understanding, and I'm glad this has already been reported, even though it's not currently in your plans to implement it. I will consider evaluating a contribution towards this. Thanks!