Is there way to make cloneable expectations?

[alefbragin]

I try to mock DB repo. (In app logic repo is a cloneable object.)
I use mock! macro to achieve Clone behavior for MockRepo. In order to expectation of repo functions for cloned object also works, I use this construction:

let mut mock = MockRepo::new();

mock.expect_clone().returning(|| {
    let mut m = MockRepo::new();
    m.expect_add_user().returning(|_| Ok(()));
    m
});

Is there more direct way to achieve this?

MockRepo definition

#[async_trait]
pub trait Repo {
    async fn add_user(&self, user: &User) -> anyhow::Result<()>;
}

mock! {
    Repo {}

    #[async_trait]
    impl Repo for Repo {
        async fn add_user(&self, user: &User) -> anyhow::Result<()>;
    }

    impl Clone for Repo {
        fn clone(&self) -> Self;
    }
}

upd: When it's needed to multiple clone, this approach is used by me:

fn make_repo() -> MockRepo {
    let mut repo = MockRepo::new();
    repo.expect_clone().returning(make_repo);

    repo.expect_add_user().returning(|_| Ok(()));
    repo
}

let repo = make_repo();

[asomers]

Are you asking if the Mock object can automatically implement Clone? The answer is no. For one thing, it's not clear what should happen to their expectations. Should they be cloned too, or should the clone have blank expectations? Some applications may want one way, some the other. Call counts are even trickier. If an expectation has call counts set with .times(), how should they be divided between the original and the clone? Finally, it's not possible for a mock object to automatically implement Clone, because some of its expectations may contain non-cloneable closures, matchers, or return values.
What you did with make_repo is exactly what I would advise.

[sweatybridge]

Hi, one train of thought I've been exploring is not to clone the expectations but to clone a reference to the mocked struct using Arc<MockRepo>, similar to code snippets suggested in the following issues:

• Is there a way to specify derives for the generated mock struct? #59
• Support DerefMut for mocks #191

Following the Repo trait example above, I could imagine automock generating a MockRepoWrapper struct (not the best name) that either forwards all trait impls to inner MockRepo or expose a set_expectation method to safely mutate inner ref using scoped closure. See my example below:

#[cfg(test)]
mod tests {
    use async_trait::async_trait;
    use mockall::automock;
    use std::sync::Arc;

    #[automock]
    #[async_trait]
    pub trait Repo {
        async fn add_user(&self, user: u64) -> Result<(), ()>;
    }

    #[tokio::test]
    async fn test_mock_clone() {
        let mut mock = MockRepoWrapper::new();
        // Mutable reference to inner MockRepo is closure scoped so should be safe to borrow
        mock.set_expectations(|mock_ref| {
            mock_ref.expect_add_user().times(1).returning(|_id| Ok(()));
        });
        mock.clone().clone().add_user(123).await.unwrap();
    }

    #[tokio::test]
    async fn test_mock_expect() {
        let mut mock = MockRepoWrapper::new();
        // Will crash if the mutable reference is borrowed in more than one place
        mock.expect_add_user().times(1).returning(|_id| Ok(()));
        mock.clone().clone().add_user(123).await.unwrap();
    }

    /// Everything below may be generated by automock
    struct MockRepoWrapper {
        inner: Arc<MockRepo>,
    }

    impl Clone for MockRepoWrapper {
        fn clone(&self) -> Self {
            MockRepoWrapper {
                inner: self.inner.clone(),
            }
        }
    }

    impl MockRepoWrapper {
        pub fn new() -> MockRepoWrapper {
            MockRepoWrapper {
                inner: Arc::new(MockRepo::new()),
            }
        }

        /// Guarantees the borrowed &mut is owned exclusively by the closure
        pub fn set_expectations<F: FnOnce(&mut MockRepo)>(&mut self, g: F) {
            g(Arc::get_mut(&mut self.inner).unwrap())
        }

        /// Relies on user to setup mock in one place
        pub fn expect_add_user(&mut self) -> &mut __mock_MockRepo_Repo::__add_user::Expectation {
            Arc::get_mut(&mut self.inner).unwrap().expect_add_user()
        }
    }

    #[async_trait]
    impl Repo for MockRepoWrapper {
        async fn add_user(&self, user: u64) -> Result<(), ()> {
            self.inner.add_user(user).await
        }
    }
}

If this works, then those structs which derive clone can be automock-ed, which makes this crate even more easy to use (see #308).

For one thing, it's not clear what should happen to their expectations. Should they be cloned too, or should the clone have blank expectations?

Regarding your concern above, if we implement Arc, expectations on all clones will be set on the same mock object. I think this is a sensible default since expectations are evaluated in FIFO order. If user wants blank expectations, he/she should perhaps inject a new Repo instance as dependency instead of using clone() as a substitute for new().

Do you see any other complications that might arise from this approach?

[asomers]

Yes, I see one very big concern: clones are independent objects that should not in general share expectations. Obviously it's fine for your project if they do. But in general, it isn't. There are already Mockall consumers using cloneable objects that require them not to. Mockall itself must do the most general thing. So I really don't see a way to derive Clone without hampering that generality.

[DanielJoyce]

It would be handy if there was a way to clone expectations at least, or copy them, so when we handle clone we can handle which ones are copied.

[asomers]

Alas, that's not generally possible either, because an expectation's return value isn't necessarily Clone. In fact, the return_once method exists precisely to handle return values that aren't Clone. So it will never be possible to clone an expectation. At best, it might be possible to try_clone it.

[YarekTyshchenko]

Clone being part of the mocked interface never sat right with me. @asomers is totally right that it is never sensible to implement Clone for automocks. I have instead moved Arc out of those dependencies. Here is a playground link that demonstates the solution: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3eee62859ec131a210f9d6ae0cdd8086

// Another trait stipulates that implementing struct must be Clone
trait EventHandler : Clone {
    fn handle(&self) {}
}

// Service<T> here is Clone, because T is Arc<Dependency>, which is clone
impl<T> EventHandler for Service<T>
where
    T: Deref<Target: Dependency> + Clone,
{
    fn handle(&self) {
        self.t.do_thing();
    }
}

Note: this requires newer rust (works on 1.81). On older you'd have to do T: Deref + Clone, T::Target: Dependency, which looks a bit uglier

I'm saying here that a dependency isn't of trait Dependency directly, but something that dereferences into Dependency, and that container is also clonable, but that's outside the interface for that mock to deal with.

Mocking semantics are also maintained: If your service starts up a bunch of threads and has to share a single instance of your dependency across them somehow, it'll do the same with your mock, exactly as it would do in production code

For dependencies with mutable receiver I think it should be possible to use DerefMut, and which would mean you'd use an Arc Mutex/RwLock in your wrapper. You could also push the mutex down into the dependency as it may be more efficient to manage that there, and keep the regular non-mutable shared pointer.