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 AcmeRepository class.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:There's the Context, the FetchRequest, the Store, the 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 Context, FetchRequest and 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?
TDD: Testing coordination of object-graphs provided by third-party libraries
unit testing;tdd;dependency injection;integration tests