Mocking

This mini-post is part of a series about good testing practices, which I also presented at a couple of conferences. Here it is in PyCon US 2023 Sometimes, in a test, we switch a part of the system, a dependency, with an alternative implementation. These are called test doubles. Things like stubs, mocks and fakes. A few of the central reasons for doing this are: Performance - if the real thing is too slow to run a lot of tests, we switch it with a fast test double. Control - it might be difficult or impossible to set up the real thing in a certain state or make it behave in a certain way. Maybe it’s non-deterministic, maybe it has side effects that are not acceptable in tests. But tests doubles are under our full control and won’t create side effects we don’t want. The problem with test doubles Test doubles can be useful, but they are a re-implementation. They know the implementation details of the thing they’re replacing. Different types of test doubles do it differently, but this is what they do. ...

This mini-post is part of a series about good testing practices, which I also presented at a couple of conferences. Here it is in PyCon US 2023 The root cause of many testing problems is improper test scope, i.e. that their boundaries aren’t appropriate. Test a cohesive whole - complete story My approach here is that a test should verify a cohesive whole, a “complete story”. It can be a large story like an e2e test or a small story that’s part of a bigger story, like a custom sorting function that something else uses. As long as it’s something self-contained - something whole, it might be worth testing. ...