Mocking external generic struct

[MrCasCode]

Hi,

I have this struct in my module

pub struct LiquidityMapBuilder<'a, T: TransportTrait> {
    contract: &'a Contract<T>,
    tick_spacing: i32
}

Contract is a generic struct from an exernal crate web3::contract::Contract

I've tried mocking the struct as:

#[cfg(test)]
trait TransportTrait : Transport + Send + Sync + 'static {}
#[cfg(not(test))]
trait TransportTrait : Transport + Send + Sync {}

#[cfg(test)]
mod mock {
    use super::*;
    use mockall::mock;
    mock! {
        pub Contract <T: TransportTrait>{
            pub fn query<R, A, B, P>(
                &self,
                func: &str,
                params: P,
                from: A,
                options: Options,
                block: B,
            ) -> impl Future<Output = Result<R>> + '_
            where
                R: Detokenize + 'static,
                A: Into<Option<Address>> + 'static,
                B: Into<Option<BlockId>> + 'static,
                P: Tokenize + 'static;
        }
    }
}

#[cfg(test)]
use mock::MockContract as Contract;
#[cfg(not(test))]
use web3::contract::Contract;

From what I've been reading adding the ' static is mandatory for now #217. The problem is that this that now the functions return types don't match because R has a 'static lifetime in the tests. If I don't make it static then I have the problem of not living long enough.

How could I deal with this issue? Being an external crate I can't modify the code to change the return types depending of if testing or not

[asomers]

Well, you have modified the code to change the return types depending on #[cfg(test)]. What error do you get when you try to use this definition?

[MrCasCode]

I had a type mistmatch in the return type. I was able to bypass this one but then since I'm working with Futures I'm stuck with the new trait not being Send, and having problems later on.

I'm not experience enough with Futures and Generics so I think I'm gonna let it be and don't test those functions, I've spent a lot of time fighting with the types and I feel discouraged now.

Anyways I have the feeling that while the ' static limitation is present for these complex types it's going to be easier do it manually by creating a new trait.

[asomers]

Why isn't the trait Send? And if you want help with the return type issue, you need to provide the exact error message and the code that triggered it.