Test doubles

Avoids defining full classes for lightweight test stubs by dynamically creating minimal fake objects inline.

Unit testing: needing a repository or service stub that accepts method calls but performs no real work. Test-driven development: creating a quick stand-in for a dependency without polluting the test module with class definitions. Prototyping: spinning up a minimal object with a required interface for quick experimentation.

Python testing, pytest, unittest, dependency injection patterns, repository pattern implementations

type('classname', (), {'methodname': lambda self, arg: None})()

type(..., (), {...: lambda ...: ...})()

classname: str, methodname: str, arg: str, return: any

• unittest.mock.MagicMock
• unittest.mock.patch
• pytest fixtures
• dependency injection
• repository pattern

• unittest.mock.MagicMock: more feature-rich with call tracking and return value configuration
• but heavier and less transparent. Simple stub class definition: clearer and more IDE-friendly
• but requires more boilerplate lines. types.SimpleNamespace: simpler for attribute-only fakes
• but cannot hold callable methods.

Forgetting the trailing () to instantiate: type('X', (), {...}) creates a class object, not an instance — calling .save() on the class raises TypeError. Omitting 'self' in the lambda: lambda item: None instead of lambda self, item: None causes TypeError on method call because Python passes the instance as the first argument. Passing the methods dict as the second argument: type('X', {'save': ...}) puts the dict in the bases position, causing TypeError — the empty base-class tuple () is required. Forgetting to quote method keys: {save: ...} instead of {'save': ...} causes NameError since save is not a defined variable.

unittest.mock.MagicMock: full-featured mock with call recording and auto-created attributes vs. type() stub which is a minimal silent object. types.SimpleNamespace: attribute-only namespace object vs. type() stub which supports callable methods. collections.namedtuple: immutable tuple with named fields vs. type() stub which is mutable and method-bearing.

Coming from JavaScript: may expect object literals like {save: () => null} to create callable objects directly — Python requires explicit class construction via type() or class definitions. Coming from Ruby: may expect OpenStruct or Struct.new to provide similar ad-hoc objects — Python's type() is lower-level and requires manual method definition in a dict.

• dynamic class creation
• test doubles
• monkey patching
• type() metaclass construction
• stub objects

Do not use this in production code — it is a testing convenience only; real classes are far more maintainable and discoverable. Each call to type() creates a genuinely new class object in memory, which has minor overhead if used inside tight loops. The lambda methods become true bound methods after instantiation so self is passed automatically, but they lack docstrings, type annotations, and IDE autocompletion support.

Enables rapid test writing by eliminating boilerplate class definitions for simple stubs, keeping test code focused on behavior verification rather than test infrastructure setup.

type() with three args is Python's class factory — like 3D-printing a disposable object on demand, use it once for a test and throw it away.

The three-argument form of type() is Python's built-in metaclass constructor — it is exactly what the class statement compiles to under the hood. This pattern leverages that mechanism to skip the class keyword entirely.

unittest.mock.MagicMock for complex test doubles with behavior verification, or pytest fixtures with proper stub classes for shared test infrastructure