It seems there are lots of resources on how to Mock third-party code when that code is simple. A
JSONRequest, etc. but when using a third-party library which requires the configuration of a relatively complex object graph – three or more classes for example – resources appear to dry up.
For example, say you been given a repository interface,
IRepository, and now you're tasked with Testing and Implementing a concrete repository using Acme Inc's new AcmeBase, so you begin work creating your new
AcmeBase's ORM requires configuring a relatively complex object graph in order to use it. The objects in the graph – while being organised well – are all quite tightly coupled:
StoreCoordinator, then there are all the proprietary
AcmeRecord objects themselves which of course aren't pure data objects. You could break apart the problem into multiple parts. Say, wrap the
AcmeRecord classes, but then how do you mock an operation such as
execute(request: FetchRequest) -> Set<AcmeRecord> on our
Context class? All that insulation would seem to hamper the design of the framework, create a lot more work, and ironically increase the surface area for bugs.
How do you test this kind of complex coordination if you don't own the third-party classes?
It seems creating a wrapper for every class that constitutes the graph is overkill. But then how can you test that the graph has been instantiated and is being managed as you expect?