Earlier quoted context omitted.
Yes. The test passes. https://imgur.com/a/4qlTKlc To try to monkey patch this in, you would need to also assert that it wasn't called with [2, 4, 6, 8, 10]. At which point, I would again ask "why are you testing that it _wasn't_ called with a given set of values?" The comment at the root of this is "Unit tests catch that kind of stuff". ... But unit tests aren't for testing internals of implementation but rather obse…
The test pass because your patching print_even so the 2nd filter is never called. Which I guess, idk maybe think through the testing more and your code more before jumping to conclusions about how things are? Testing is one tool you have, and it can test the internal like this. Obviously there's a use for it if its in the Python stdlib This is in mockito https://stackoverflow.com/questions/39452438/mockito-how-to-...…
However, it also means mocking list.stream() and mocking the Stream for stream.filter() and mock the call stream.toList() to return a new mocked object that has those mocks on it again.
I could catch the object passed in to printEven(...) but that has no history on it to see if filter was called on it before.
Trying to do the filter(...) call would be especially hard since you'd be parameterize it with a code block.
And all this returns to "is this a useful test?"
Testing should only be done on the observable parts of the function. Does printEven only print even numbers?
The tests that you are proposing are testing the implementation of those calls to work in a specific way. "It must call filter" - but if it's changed to a different filter or if it's changed to not use a filter but has the same functionality the code breaks.
Inefficient? Yes. Bad? Yes. Wrong - no. And not being wrong it isn't something that a unit test could validate without going unnecessarily into the implementation of the internals for the method. Internals changing while the contract remains the same is perfectly acceptable and shouldn't be breaking a unit test.