Closed darioush closed 9 years ago
My vote is -1. I'd really like to avoid adding even more complexity to testify especially given no precedent in other testing frameworks.
-1
It's actually possible to implement various levels of import mocking as a test fixture, without adding complexity to the test system.
I can show you how my import test fixture works if you ask me.
This is how i've fixtured it in the past. This is likely more aggressive than you want for your purpose, but something similar will do what you need.
@T.setup_teardown
def mock_imports(self):
class FakeImporter(object):
@staticmethod
def find_module(dummy_fullname, dummy_path=None):
# I'm able to find all modules.
return FakeImporter
@staticmethod
def load_module(fullname):
result = self.fake_modules.get(fullname)
sys.modules[fullname] = result
return result
old_sys_meta_path = sys.meta_path[:]
with contextlib.nested(
# Clear out the sys.path so that we have can assert its changes deterministically.
mock.patch.object(sys, 'path', []),
# Clear out any of the currently-imported modules, temporarily.
mock.patch.dict(sys.modules, values=dict(), clear=True),
):
sys.meta_path[:] = [FakeImporter] # there's no mock.patch.list
# Run whatever test we're trying to run.
yield
sys.meta_path[:] = old_sys_meta_path
I agree with @asottile and @bukzor. Imports can be mocked outside of the test framework itself. If you are having issues mocking imports caused by Testify itself, that would be a different issue.
This can be used for proper mocking of difficult to mock libraries due to python import hell.