Why can a misspelled assertion on a unittest.mock Mock pass silently?

A `Mock` is deliberately permissive: `Mock.__getattr__` creates a child mock for any attribute you touch and caches it, which is what lets you write `client.session.post(...)` against a mock without configuring anything. That same permissiveness is what makes a mistyped assertion dangerous, because an assertion is just an attribute access followed by a call — and both halves succeed on a mock no matter what you spell. ## The classic failure Imagine a flight-schedule differ whose publish step swallows an exception and quietly emits nothing. The test that was supposed to catch it reads `differ.sink.assert_called_onse_with(expected)`. On an old interpreter that access creates a child mock, calling it returns another mock, the statement value is discarded, and the test passes. The bug rides a three-week release train into production with a green suite behind it. The test was not weak; it never ran. ## What CPython did about it `unittest.mock` grew a guard in `__getattr__`. On Python 3.5 any attribute name starting with `assert` or `assret` raises `AttributeError` instead of being auto-created. Python 3.12 widened the prefix list to also cover `asert`, `aseert` and `assrt`. Current versions go further and reject a deny list built from the real assertion names with the `assert_` prefix stripped — so `called_once_with`, `has_calls`, `any_call` and `not_called` raise too, which catches the other common slip of dropping the prefix entirely. The error message names the attribute and suggests giving the mock a spec if you genuinely meant it as data. `Mock(unsafe=True)` disables the guard. That exists for the legitimate case where the object you are faking really does have an attribute called `assert_something`, and it should be rare — reaching for it to silence an error is how you re-open the hole. ## What still passes silently on 3.14 **Forgetting the parentheses.** `differ.sink.assert_called_once_with` — with no call — is a valid attribute access that yields a bound method and then throws it away. Nothing is checked, nothing raises, and the guard cannot help because the name is spelled correctly. This is the single most common surviving form. **A typo in the attribute being mocked, combined with a negative assertion.** `differ.emmit.assert_not_called()` auto-creates the child `emmit`, which was of course never called, so the assertion passes — while the real `differ.emit` was called all along. Every negative assertion on a mock is vacuous if the target name is wrong, and the guard only inspects the assertion name, not the attribute path in front of it. **Asserting on the wrong object.** `differ.assert_not_called()` passes whenever the code only ever called children of `differ`. ## How to make the failure loud * **Prefer positive assertions.** `assert_called_once_with(...)` on a mistyped attribute fails immediately with "Called 0 times", because it demands evidence rather than the absence of it. Pair every `assert_not_called()` with at least one positive assertion elsewhere in the test that proves you are holding the right mock. * **Constrain the mock to the real interface.** Giving a mock a spec of the object it stands in for makes any attribute the real object does not have raise `AttributeError`, which kills the mistyped-child case outright. (That mechanism has its own depth and its own tradeoffs; the point here is only that it closes this hole.) * **Make the test fail first.** A test that has never been seen red is not evidence. Break the production line the assertion covers and watch the assertion complain; a silent assertion is exposed instantly. * **Lint for pointless statements.** An expression statement whose value is unused — exactly what a parenthesis-less assertion is — is a standard lint finding, and a static type checker that knows the mocked type will also flag misspelled attributes. * **Watch mutation coverage or a canary.** If a suite has a habit of this, deliberately introducing a defect and confirming a red build is the cheapest audit you can run in review. ## Interview framing The question is really about two things at once: understanding that a mock's convenience comes from unconditional attribute creation, and knowing that "the test passed" and "the test checked something" are different claims. Candidates who answer only "there is a check for that now" have half of it; the strong answer names what the interpreter guard covers, what it cannot cover, and the review habits that catch the rest.