Extreme mockall newbie alert - 2 basic questions

[Mrodent]

I looked where I should, at the very first part of the documentation, Getting Started.

I've seen this question at SO.

I've been puzzling over this example, and other similar examples, for about an hour. I also confirm that I've searched the discussions here.

Could someone please just tell me a couple of very basic things?

1. the line #[automock] must precede the trait definition... but if you have "mockall = "n.n.n."" under [dev-dependencies] in your cargo.toml, this will cause an "undeclared crate" error on compile ... unless you trait definition is in the tests section of the file. But if it is there, doesn't that mean you can't use it for your app code? I.e. as a basis for an impl to be used in the app code?

2. the example given there, i.e.

   mock.expect_foo().with(predicate::eq(4)).times(1).returning(|x| x + 1);

... doesn't actually seem to prove or safeguard anything ... in Python (for example) you're using actual instances of classes and just mocking out selected parts of the functionality. If your app implementation of MyTrait in this case does something completely different to |x| x + 1 your tests seemingly won't tell you that. I'm struggling to see what such a test in fact accomplishes.

I'm 100% certain that both of these are really naive questions, but there seems to be very little along the lines of (very) low-level introductions to testing and (especially) mocking in Rust.

[asomers]

1. This is a very common use case, and the solution is to use #[cfg_attr(test, automock)]. That way automock will only be used when building your unit tests.
2. One doesn't use Mockall in order to test the struct that's being mocked. Instead, one uses Mockall in order to test the structs that use the struct being mocked. For example, if you have a struct Outer{inner: Inner}, you can use a MockInner in order to test the Outer struct.

[Mrodent]

Thanks for the quick reply. Got it re point 1.

Also re point 2. So I was trying to run before I could walk, because I was wondering how you could ascertain whether a method was called with certain arguments as a result of some other method being called, that kind of thing, which is standard stuff with pytest, for example. Whether that's possible and how I shall no doubt learn in due course.

I shall now carry on with your (I assume it's from you) intro.

[asomers]

how you could ascertain whether a method was called with certain arguments as a result of some other method being called

Not if both methods are on the same object. You must either mock the entire object, or none of it.

[Mrodent]

Right... was beginning to suspect that might be a limitation. So "spies" are not possible, if I understand correctly. No doubt many testing "purists" will approve. With pytest I've come to use spies as the main workhorse of my testing! Time for a mentality reset in Rust.

[asomers]

It's not really an ideological decision, but a practical one. In Python, you can redefine any part of any struct at any time. But Rust is a compiled language, so you can't do that. In Rust, replacing the object wholesale was really the only option.

[Mrodent]

Yes I get that. There are such strong opinions about "right" and "wrong" testing, but I have read things over the years by obviously very expert people about why they really didn't like spies ... largely in relation to Java/Groovy mocking arrangements.
But (as with getting to grips with Rust as a language compared to Python), this really does represent a "mental reset" (or challenge) ... to understand how people go about something like TDD with Rust, best practice, that kind of thing.