What are the risks of installing a stub module into sys.modules during a test?

### What sys.modules is `sys.modules` is the interpreter's import cache: a plain mutable mapping from module name to module object, one per interpreter. The import statement checks it before doing anything else, and a successful import writes into it. Because it is a plain mapping, you can write into it yourself — and the import machinery will honour whatever you put there, without asking whether it came from a file. That gives tests a blunt but occasionally necessary tool. If the code under test does `import lab_vendor_client` at module scope and that distribution is not installed in the test environment, importing the code at all fails. Registering a `types.ModuleType` under that name before the import makes the code load and run against your object. ### The four risks **It is global, and it is not undone.** The entry is visible to every module in the process, not just the file that wrote it. Leave it behind and every later test that imports the name gets the stub — usually silently, sometimes producing a pass where a real failure was waiting. This is the same leak as an unrestored module attribute, with a wider blast radius, because it affects imports that have not happened yet. **Timing decides whether it works at all.** The stub only affects imports that occur *after* it is installed. If the module under test was imported during collection, it already bound the real object into its own namespace, and the import statement will never run again for it — your sys.modules entry sits there being consulted by nobody. This is why the technique belongs as close to the start of the process as it can be, and why it fits a genuinely unimportable dependency better than a merely inconvenient one. **Dotted names are separate entries.** Registering `lab_vendor` does not satisfy `import lab_vendor.results`. The machinery resolves each part of a dotted name and looks up the full name in the cache; on a miss it tries to import the submodule for real through the parent's submodule search path, which a plain module object does not have. If the code imports submodules, register every dotted name you need and also set each submodule as an attribute of its parent, because `from lab_vendor import results` reads it as an attribute. **A too-generous stub hides mistakes.** A bare `MagicMock` as the module answers every attribute access with a new mock, so a call to a function that does not exist on the real module passes the test and fails in production, and a renamed function is never noticed. Build the stub as a `types.ModuleType` with exactly the functions and constants the code under test uses, so an unexpected access raises `AttributeError` and the test tells you the truth. ### Doing it safely The cleanup must be structural, exactly as for any other shared state. `unittest.mock.patch.dict(sys.modules, {"lab_vendor_client": stub})` snapshots the mapping, applies the entry, and restores the snapshot on exit inside a `finally` — including the case where the real module was already cached and must be put back. `addCleanup` with a function that deletes the key is the equivalent when you need the stub installed for the duration of one test method rather than one block. What is never acceptable is a bare assignment with the removal written as the last line of the test. A second discipline is scope. Install the narrowest name that makes the import succeed, keep it in place for the shortest span that covers the import, and assert on the calls your stub received rather than on the stub's internals. ### When not to reach for it A stub module is a workaround for an import you do not control. When you do control the code, the cheaper fixes are ordinary: move the import inside the function that uses it so the module can be loaded without the dependency present, or accept the collaborator as an argument so no import needs to be intercepted at all. Reserve import-cache surgery for third-party or platform modules that genuinely cannot be imported in the test environment — a driver for hardware that is not attached, a platform-specific module on the wrong operating system, a heavy optional dependency your suite deliberately does not install. Stated as an interview answer: writing to `sys.modules` is legitimate, occasionally the only option, and always a promise to clean up — because you are editing a process-wide registry that every future import will read.