Design for using a mock connection

Question

I have a simple application with a UI with a backend connection, from which i get the data. Now, during development, I wouldn't like to connect to the backend as it slows me down. So, i have some locally stored data and i 'mock' the connection to return the locally stored data instead of making a server call.

Now, this is not for writing test cases (hence, i do not see if mocking frameworks come in the picture), but just being able to switch between between a local and remote connection during development.

There are many ways to do this, i suppose:

• Obtaining the connection from a factory (or via dependency injection) and setting a flag that returns the local connection
• Maintaining a properties file, where i set 'local=true' or something similar that returns the local connection.

Are there any other ways of achieving this?

Answer 1

There's two halves to the problem:

1. From where does the app get its connection? Factory? Clever annotations managing DI? ...
2. How does the source of the connection determine which one to use, mock, or possibly serveral different varients of live (Prod, ST, Dev etc.)

For the former there's plenty of discussion about DI techniques elsewhere. I would favour approaches that also readily enable Unit Testing too - I have found DI to be useful in that context.

As for any properties/configurations that may be used, it depends on the kind of environment you have. You don't say whether your is a stand-alone Java app or something running in a JEE environemnt. If the latter then using JNDI resources may be useful.

Answer 2

When I occasionally need to use e.g. a local database instead of the production database on the network I edit my

/etc/hosts

so that the name of the production database reolves to my own local host. Quick and dirty.

Answer 3

Don't over-complicate things. There's an obvious need to return different implementations - so use a factory. Then the factory needs to know which implementation to create. You could use a property, or even get away with a static boolean variable.

Answer 4

Have you looked in to a dependency-injection framework?

I have use Google Guice to handle this exact issue.