Why does a bare unittest.mock.Mock accept calls to methods the real object lacks?

## A Mock has no interface A `unittest.mock.Mock` has no interface. Every attribute you touch that it has not seen before is created on the spot as a **child mock**, stored, and returned; the child is itself a Mock, so it is callable, and calling it returns another mock. Attribute access is therefore total: no name is ever wrong. `mock.post_entry`, `mock.post_entrie` and `mock.transmogrify` all succeed, all return something callable, and all record their calls. This is what makes a Mock so cheap to use — and it is the single largest source of false confidence in Python test suites. Concretely: a payment reconciliation job depends on a ledger client whose method is `post_entry`. Someone renames it to `record_entry` and updates the production call sites. The unit tests replace the client with a bare `Mock`, so nothing in the 27-minute suite notices: - the tests still call `client.post_entry(...)` on a double that happily invents it, - `assert_called_once_with` still passes on the child that got created, - and the suite stays green while the real object no longer has that method. The tests were never checking the interface; they were checking that the test agreed with itself. Note also that child mocks are cached, so `mock.post_entry is mock.post_entry` — the assertion sees exactly the child the code touched, which is precisely why the illusion is so convincing. ## `spec=` and `spec_set=` `spec=` closes the name hole. `Mock(spec=Ledger)` copies the attribute names from the object or class you pass in (using `dir()`), and any access outside that set raises `AttributeError: Mock object has no attribute 'post_entrie'` at the moment of access, not at the assertion. It also fakes `__class__`, so `isinstance(Mock(spec=Ledger), Ledger)` is True and production code that type-checks its collaborator still works — a useful lie, though `type(mock)` remains a Mock subclass. You can spec against a class or against a live instance; against an instance you also pick up attributes assigned in `__init__`, which a class-based spec cannot see. `spec_set=` is the stricter sibling. - `spec=` only constrains *reads*: you can still write `mock.newattr = 1` and invent an attribute on the double, which reintroduces the typo problem in the arrange phase. - `spec_set=` also constrains *writes*, so assigning a name the real object does not have raises AttributeError. Mock's own configuration attributes — `return_value`, `side_effect` and the rest — remain settable. There is essentially no reason to prefer `spec=` over `spec_set=` for a double you fully control; the looser form exists mostly for doubles that need extra bookkeeping attributes hung on them. ## What a spec does not check What `spec=` does **not** do is check how you call things. It validates the attribute name and stops. `Mock(spec=Ledger).post_entry(1, 2, 3, 4)` passes even though the real method takes two arguments, and the children handed out by a specced mock are ordinary unconstrained mocks, so one level down you are back to inventing names. Signature checking and recursive constraint are `unittest.mock.create_autospec` and `patch(..., autospec=True)`; a spec is a **shallow, name-level fence**. ## Sealing a hand-built double `unittest.mock.seal` covers the case where there is no interface to spec against — a double you assembled by hand for a config object, a dynamically built client, a nested tree of `return_value` chains. You build exactly the structure the test needs, call `seal(mock)`, and from then on any *new* auto-created attribute anywhere in that tree raises AttributeError naming the full path, such as `mock.db.port`. Attributes you configured before sealing keep working. So `spec` pins a mock to a real class up front; `seal` freezes whatever you actually built. Sealing recurses into child mocks that were created by attribute access, which is what makes it useful on a deep tree. ## The interview point The interview point beneath all of this is that a mock's permissiveness converts a compile-time-ish error — calling a method that does not exist — into a green test. Static checkers help but do not see through a Mock, whose type is deliberately anything. So the discipline is: 1. spec every double against the real collaborator, 2. prefer `spec_set` or autospec, 3. seal what you cannot spec, 4. and remember that even a perfectly specced mock only tells you the *shape* of the local version of the dependency was respected. One more practical wrinkle: mock names starting with `assert` are guarded — a Mock refuses to invent an attribute like `assert_called_onece` and raises AttributeError instead, so that misspelled assertions fail rather than silently passing. That guard covers only the assertion family; every other misspelled name is still invented, which is why spec remains the real defence.