andrea crotti <andrea.crott...@gmail.com> writes: > I'm writing a program which has to interact with many external > resources, at least: > - mysql database > - perforce > - shared mounts > - files on disk > > And the logic is quite complex, because there are many possible paths to > follow depending on some other parameters. > This program even needs to run on many virtual machines at the same time > so the interaction is another thing I need to check... > > Now I successfully managed to mock the database with sqlalchemy and only > the fields I actually need, but I now would like to simulate also > everything else.
There is a paradigm called "inversion of control" which can be used to handle those requirements. With "inversion of control", the components interact on the bases of interfaces. The components themselves do not know each other, they know only the interfaces they want to interact with. For the interaction to really take place, a component asks a registry "give me a component satisfying this interface", gets it and uses the interface. If you follow this paradigm, it is easy to switch components: just register different alternatives for the interface at hand. "zope.interface" and "zope.component" are python packages that support this paradigm. Despite the "zope" in their name, they can be used outside of "Zope". "zope.interface" models interfaces, while "zope.component" provides so called "utilities" (e.g. "database utility", "filesystem utility", ...) and "adapters" and the corresponding registries. Of course, they contain only the infrastructure for the "inversion of control" paradigm. Up to you to provide the implementation for the various mocks. -- http://mail.python.org/mailman/listinfo/python-list