Decoupling. For example if your code requires access to an outside resource (database, message queue, email service) you can mock said resource in order to test the code in isolation.
In python you can mock pretty much anything you want. You can mock package-defined variables by simply modifying them to the value you want (sys.modules['mymodule'].MY_GLOBAL_SWITCH = True). In such a way you can even mock standard library functions and built-ins (which have their own __builtin__ package). With such capabilities you can test pretty much any code. (There are some limitations indeed, like you can't change types which are defined in C code.)
Hey! Ho! Stop that. Nobody uses the word "Decoupling", I just learned that in the video. You must be pulling a fast one on me.
Let me clarify what I think you're saying. It's not about testing class X, it's about testing code that uses class X. As long as X is a class, then we can create a mock version and pass around instances of it. If our "X functionality" is stored somewhere else (ie a bare function), then that gets harder.
Down that road lies the hell of dependency injection frameworks. A simpler approach is to use something like detours[1] to mock bare functions directly.