Why is a collaborator constructed inside a Python class harder to test than one passed in?

A **seam** is a place where you can change what a piece of code does without editing that code. Python offers essentially two seams for a *collaborator* - an object your code calls out to, such as a store, an HTTP client, or a queue publisher - and choosing between them is a design decision, not a test detail. ### The two seams The first seam is **the parameter**. If a class or function takes its collaborator as an argument, a test supplies whatever it likes: ```python class Renderer: def __init__(self, store): self.store = store ``` The second seam is **the import**. If the class builds the collaborator itself, the only remaining handle is the name in the module namespace, which `unittest.mock.patch` can temporarily replace: ```python class Renderer: def __init__(self): self.store = InvoiceStore() # nothing to pass, nothing to override ``` Both make the test pass. They differ in what the test ends up depending on. ### Why the parameter seam wins by default **It is the honest dependency list.** The signature says what the object needs. A reader who wants to know what a class touches reads its `__init__`, not the whole body plus every module-level import. **It survives refactoring.** A patch target is a *string* resolved at run time. Move the module, rename it, or change where the name is imported, and the patch either fails loudly or - worse - patches a name nobody calls, so the test passes while quietly exercising the real collaborator. A parameter is checked by the interpreter and by a static type checker; a string is checked by nothing until the test runs. **It keeps the test about behaviour.** A patch-based test encodes the *structure* of the code under test: which module imports what. Restructure the code without changing behaviour and the tests go red anyway - the classic sign of tests that are pinned to implementation. **The fake documents the contract.** A hand-written in-memory double is a few lines and is executable documentation of the small slice of the interface that is actually used: ```python class FakeStore: def __init__(self): self.saved = {} def save(self, invoice_id, pdf): self.saved[invoice_id] = pdf ``` Assertions then read against real state (`fake.saved["INV-17"]`) instead of against call records, which is usually clearer and does not go stale when an argument is added. ### Keeping production callers happy The common objection is that injection forces every caller to build the dependency. The idiomatic Python answer is a default resolved in the body: ```python def __init__(self, store=None): self.store = InvoiceStore() if store is None else store ``` Use `is None`, not `or`: a legitimate collaborator can be falsy (an empty in-memory fake that defines `__len__` or `__bool__` would silently be replaced by the real one). Note that the default expression must not be `store=InvoiceStore()` in the signature - that constructs one shared instance at import time. Dependencies then get threaded upward until they are built once, near the program entry point - the place people call a *composition root*. That plumbing is the real cost of injection, and it is what makes the pattern feel heavy in small scripts and pay for itself in anything long-lived. ### When injection is not available Patching still exists for a reason. A module-level function that reaches for a global, a third-party library that constructs its own client, code you are not allowed to change this sprint, an import-time singleton: these have no parameter seam, and `unittest.mock.patch` is the correct tool rather than a defeat. The judgement is about proportion. One patch at the edge of the system is normal; a stack of them over code you own is the code telling you it never offered a seam in the first place. ### The failure mode on the other side Injection can also be overdone. Passing in value objects, standard-library calls, or things with no alternative implementation adds parameters that will never vary and makes every construction site noisier. Inject what has a *second* implementation in some real scenario - typically anything that performs I/O, talks to another process, or is slow or non-deterministic - and construct the rest inline.