Replies: 2 comments 7 replies
-
I can think of two problems that would arise pretty quickly:
BTW, it would be easy to build the Mutex into the Context object. The only reason I didn't is because it would be easy for users to accidentally trigger deadlocks, because they don't know about the Mutex's existence. If somebody ever writes a Mutex type for Rust that has builtin lock-order-reversal detection, then we could use that. |
Beta Was this translation helpful? Give feedback.
-
@jder it looks like Clippy has the ability to add crate-specific lints. See this thread for more info: rust-lang/rust-clippy#6872 . Do you think it would be possible to add a lint to guard against the immediately-dropping-a-context-object bug? |
Beta Was this translation helpful? Give feedback.
-
Hi all! I'm experimenting with using mockall for mocking out a number of modules with static methods. It generally works great, but I've run into two papercuts:
First, it's pretty easy to accidentally write something like:
Which doesn't do what you want since the context object is immediately dropped and panics. It's harder to do this for non-static mocks since the context object is also the mock object (and so you'll need to keep it alive for longer).
Second, you have to remember to take some kind of mutex in each test (as the docs kindly call out). In practice for us this means we'll need one process-wide mutex or have to be very careful about the order of mutexes we take for different module mocks in order to prevent deadlocks. Sounds like there's been some discussion about the risks of trying to solve this (would love pointers to them if anyone has them handy).
I was wondering if we could solve both of these by allowing test code to look something like this instead:
Basically, more closely mimic the non-static API. The
lock_context
function could take a process-wide mutex on your behalf and hold until the context object is dropped. You could still have the first bug I mentioned but it's (a) less likely because you'll often set multiple expects on the same context object and (b) the "lock" name of the method might make you think of mutex guards which you need to hold on to (and might also hint that you should think about deadlocks with any of your own mutexes).Would that be something you'd like to see in mockall? I'd love to discuss contributing it, perhaps under an attribute argument like
#[automock(static_lock)]
if you're interested. Thanks!Beta Was this translation helpful? Give feedback.
All reactions