In what order do stacked unittest.mock.patch decorators pass their mocks to a test?

Stacked `patch` decorators are ordinary decorators, and Python applies decorators bottom-up: the one written closest to the `def` wraps the function first, and the ones above it wrap that wrapper. `unittest.mock` appends each replacement to the positional arguments as its own wrapper runs, so the innermost — bottom — patch contributes the *first* extra argument, and the topmost contributes the last. ```python @patch("os.getpid") # applied last -> second mock argument @patch("time.time") # applied first -> first mock argument def test_export(self, mock_time, mock_getpid): ... ``` Read the decorator list from the bottom up and the parameter list from the left, and the two line up. On a `TestCase` method `self` stays first; the mocks follow it. **The parameter names are yours.** `patch` passes positionally, so nothing validates that `mock_time` corresponds to `time.time` — a swapped pair of names produces a test that configures the wrong double and then asserts against the wrong one. That is the whole hazard of the ordering rule: getting it backwards does not raise, it produces confidently wrong assertions. Naming each parameter after its target, in the same order, is the cheap defence. **`new=` removes a parameter.** `patch(target, new=obj)` installs exactly `obj` and, because there is nothing to hand you that you did not already have, passes *no* extra argument. Mixing an explicit `new=` into a stack therefore shifts every parameter below it: ```python @patch("time.monotonic", new=lambda: 100.0) # contributes no argument @patch("time.time") # contributes the only argument def test_export(mock_time): ... ``` The same is true of the context-manager form: `with patch(t, new=obj) as x:` binds `x` to `obj` itself rather than to a mock, which is why `with patch(t, new=obj):` with no `as` is the usual spelling. **`new_callable=` keeps the parameter.** It names a factory that `patch` calls to build the replacement — `new_callable=Mock` for a plain mock without dunder support, `new_callable=PropertyMock` to replace an attribute that is accessed rather than called. Since `patch` still constructs the object, it still hands it to you, so the argument stays and the ordering is unaffected. **`patch.multiple` passes keywords.** Decorating with `patch.multiple("time", time=DEFAULT, monotonic=DEFAULT)` injects `time=` and `monotonic=` as keyword arguments named after the attributes, not positionally, so those parameters are matched by name and their position among the other mock parameters does not matter. In the context-manager form the same replacements arrive as a dict keyed by attribute name. **Class decoration interacts with method decoration.** When `patch` decorates a `TestCase` class, it behaves as if it were the outermost decorator on every test method — its mock is appended *after* the ones contributed by the method's own decorators. So a class-level patch plus two method-level patches gives `def test_x(self, m_bottom, m_top, m_class)`. This is the arrangement people most often get wrong when they add a class-level patch to an existing suite and every method's signature silently shifts. **When the ordering stops being worth it.** Three stacked decorators are readable; six are a signature nobody can verify by eye, and each addition renumbers the ones below. At that point the context-manager form is better: each `with patch(...) as fake_x:` binds its own name at the point of use, so there is no positional correspondence to maintain, and `contextlib.ExitStack` handles a variable number of them. A long stack is also frequently a design signal — a unit that needs six collaborators replaced is a unit with six collaborators. **A note on what the argument actually is.** Each injected parameter is the replacement object that is currently installed at the target, which by default is a `MagicMock`. It is not the patcher, and not the original — if you need the original inside the test, capture it before the patch starts or reach for it through the mock's configuration. The rule to keep is short: decorators apply bottom-up, arguments arrive left-to-right in that same order, `new=` contributes nothing, `new_callable=` contributes one, `patch.multiple` contributes keywords, and a class-level patch is last. **Mixing decorator kinds changes nothing.** `patch.object(SomeClass, "method")` stacked with a string-target `patch` follows exactly the same bottom-up rule; the two forms are the same patcher with a different way of naming the target, and each contributes one positional argument unless it was given `new=`. The same applies to `patch.dict`, which contributes no argument at all — there is nothing to hand back, since the mapping itself is patched in place. **How to settle an argument about a stack without reasoning.** Inside the test, assert the identity you believe holds: `assert mock_time is time.time`. If the parameter really is the double installed at that target, the assertion passes; if the names are swapped, it fails immediately and loudly instead of producing a wrong assertion later. It is a two-line check worth writing once when you inherit a deep stack you did not author, and it is also the fastest way to convince yourself of the ordering rule in a REPL.