My colleagues and I are working to develop a more robust domain model for an application we are working on. The core entities that we are working with are "World", "Region", "Installation", and "Facility". The relationship to one another can be drawn as:
This means that our World object contains a collection of Regions, the Region object contains a collection of Installations, and the Installation object contains a collection of Facilities. This can be modeled as such:
With this design each collection is responsible for loading the appropriate objects. This includes executing an web service to obtain the proper objects. The owner of each collection is responsible for telling its collection when load itself. For instance:
public interface IWorld
{
loadRegions(date:Date);
}
public class World implements IWorld
{
private var _regionCollection:IRegionCollection;
public function World()
{
_regionCollection = new RegionCollection();
}
public function loadRegons(date:Date)
{
_regionCollection.update(date:Date);
}
}
However, during unit testing we noticed that there are dependencies within the domain model that we are not sure how to address. For instance, the the code to execute the web service call to retrieve regions is within the RegionCollection implementation. There is another in InstallationCollection and yet another in FacilityCollection.
This makes unit testing World (or the other objects) impossible because we cannot mock the internal collections which have dependencies on web services.
One solution that we have considered is utilizing the factory method, where a RegionCollectionFactory creates an concrete collection or a mock collection depending on the usage. While effective this would only hide the dependency from the test, we feel that this violates the intention of the unit test.
A second option would be to remove the dependent tests from the World object and pass the implementation test onto the RegionCollection. This would require us to assume that RegionCollection() always passes valid data back to the parent. Again we regard this as a bad option, one that reduces confidence in our unit tests.
Third, the World object can create the RegionCollection as we are doing, but pass in blank parameters. Then when RegionCollection.update(date:Date); is called it will return an empty set without connecting to the web service. This would cause World unit tests to validate with valid data structures. It does add extra logic to the constructor of the collection but it would encapsulate the dependency to some degree.