First of all, I didn't even know that mock was part of unittest now. I thought you still had to install it separately.
Generally, I suspect both will work. Maybe more a matter of taste. I'm generally pessimistic towards mocking unless it's the only way possible. Mocking is a clever but equally nasty hack and the code often becomes hard to read (once it's escaped your short-term memory) and it's so easy to "overmock" and accidentally make everything a mock object that doesn't help you check your sanity.
Done well, I believe mocking can be incredibly insightful and readable. I'll admit that doing it well is often less trivial than it sounds! I also see the value in creating objects that are essentially test harnesses, so I'm not necessarily saying I'd never follow your approach. Just wanted to get your thoughts. Thanks for the input!
Yeah you could over mock thing, but will always prefer using the same approaches in all of my tests, writing a specific mock for each thing seems a weird, and not all code lend itself to the pattern you demonstrated (I.e. having a pluggable engines)
Mocking is a very valid approach, as you demonstrated. I think that unit tests should be very specific, and anything beyond the limits of your process, should be avoided (mocked).
There are other types of tests, like component/integration tests, where the opposite is advised (but still for a lot of reason it perfectlly valid to use pretenders/simulators, for some parts of your system)
For example I'm started recently testing any component I'm writing in a docker compose setup which give me access to controlling the connections to DB, or other services, I.e. you can stop the database container and test reconnectivity.
Comment
First of all, I didn't even know that mock was part of unittest now. I thought you still had to install it separately.
Generally, I suspect both will work. Maybe more a matter of taste. I'm generally pessimistic towards mocking unless it's the only way possible. Mocking is a clever but equally nasty hack and the code often becomes hard to read (once it's escaped your short-term memory) and it's so easy to "overmock" and accidentally make everything a mock object that doesn't help you check your sanity.
Parent comment
Could you speak to the benefits of using this approach over something like unittest.mock.Mock?
Replies
Done well, I believe mocking can be incredibly insightful and readable. I'll admit that doing it well is often less trivial than it sounds! I also see the value in creating objects that are essentially test harnesses, so I'm not necessarily saying I'd never follow your approach. Just wanted to get your thoughts. Thanks for the input!
Yeah you could over mock thing, but will always prefer using the same approaches in all of my tests, writing a specific mock for each thing seems a weird, and not all code lend itself to the pattern you demonstrated (I.e. having a pluggable engines)
Mocking is a very valid approach, as you demonstrated.
I think that unit tests should be very specific, and anything beyond the limits of your process, should be avoided (mocked).
There are other types of tests, like component/integration tests, where the opposite is advised (but still for a lot of reason it perfectlly valid to use pretenders/simulators, for some parts of your system)
For example I'm started recently testing any component I'm writing in a docker compose setup which give me access to controlling the connections to DB, or other services, I.e. you can stop the database container and test reconnectivity.