Implement reasonable mock objects for testing.

[stefanoborini]

At the moment, there's a lot of ad hoc patching going on to define mock for tests. We are reaching a point when it's no longer a one-shot operation, so it's probably a good idea to define mocks for some well defined, consistent objects (e.g. docker client, container manager, user, database). This will remove or reduce the need for coroutine factories that we are using right now.

[itziakos]

Since we have interfaces I agree that having virtual or dummy implementations is a goo thing. Please note that I would suggest to avoid using the word mock for such objects to avoid confusion with the mock library.

[itziakos]

@stefanoborini and @kitchoi can you compile a list of the objects (please provide the class name) that we should create dummy or virtual versions for?

[kitchoi]

I propose creating dummy and virtual objects for the following (I will update this message locally to avoid spams), some of which already exist:

Dummy:

• remoteappmanager.application.Application
• remoteappmanager.file_config.FileConfig
• remoteappmanager.command_line_config.CommandLineConfig
• remoteappmanager.db.orm.AppAccounting
• remoteappmanager.db.csv_db.CSVAccounting
• remoteappmanager.services.hub.Hub
• remoteappmanager.docker.container_manager.ContainerManager
• remoteappmanager.services.reverse_proxy.ReverseProxy

Virtual:

• docker.Client (from docker-py)
• jupyterhub.orm.Proxy
• request.post and request.get (for testing REST api and would be needed when we use the REST api in HomeHandler)

Note on terminology (at least for me):

• "Dummy" objects are created for the corresponding class, with mocked methods (etc), it can rely on virtual objects for its mocked methods.
• "Virtual" object itself is mocked (e.g. Mock(spec=Class))