Unit testing of integrated service methods

Question

I am writing (junit) unit tests for a class that implements an open interface using methods such as:

public Set<Setting> getUserSettings(); public Set<Setting> getOrganizationSettings(); public Set<Setting> getDefaults(); public Set<Setting> getAllSettings(); 

Methods for getting settings from a certain level make IO from different places to get their results. getAllSettings () Returns a single set of all settings at all levels, with the upper level having preference (i.e. if the parameter exists at the default level and at the user level, the setting at the user level will be used.

I already wrote unit tests for getUserSettings (), getOrganizationSettings (), getDefaults (), mocking I / O with Mocked objects.

The implementation for getAllSettings () looks something like this:

 public Set<Setting> getAllSettings(){ Set<Setting> defaults = getUserSettings(); Set<Setting> custom = getOrganizationSettings(); Set<Setting> undefined = getDefaults(); //perform some sorting and business logic //return fully sorted set } 

My question is how to unit test getAllSettings () method. Can I use mocks (using easymock / powermock) for all downstream resource calls that use user / organization / defaultSettings methods? It seems like it will be a cleaner / better / easier way to do this.

Answer 1

You can write a test in the following form

 @Test public void testGetAllSettings() { Foo fixture = new Foo() { public Set<Setting> getUserSettings() { // canned impl } public Set<Setting> getOrganizationSettings() { // canned impl } public Set<Setting> getDefaults() { // canned impl } } Assert.assertEquals(whatEverItShouldEqual, fixture.getAllSettings()); } 

This will allow you to check the logic of getting all settings independently of other methods.

Another alternative would be to mock the IO of these methods. If you have a layer that implements I / O logic, then this might be taunted. As you mentioned, it can be painful if you have a lot of addictions. Perhaps a sign that you need fewer dependencies? (perhaps the class should be broken down into smaller units, for example?)