I need (for unit testing purposes) to create adapters for external library classes.ExchangeService and ContactsFolder are Microsoft's implementations in its' EWS library.
So I created my adapters that implement my interfaces, but it seems that contactsFolder has a dependency for ExchangeService in its' constructor.
The problem is that I cannot instantiate ContactsFolderAdapter without somehow accessing the actual ExchangeService instance (I see only ExchangeServiceAdapter in scope).
Is there a better pattern for this that retains the adapter classes? Or should I "infect" ExchangeServiceAdapter with some kind of GetActualObject method?
I think the adapter pattern is the right one here. What I don't see is your interfaces having more than one concrete implementation which is the advantage of the pattern in this context. Assuming that you only want to use IContactsFolder and IExchangeService in your unit tests (Microsoft is responsible for testing their classes), you need to create a mock or stub implementation of each interface that returns predictable dummy data. There are a lot of .NET frameworks for object mocking that will automatically implement these interfaces for you.
If there is some logic you are trying to test that exists in ExchangeServiceAdapter and ContactsFolderAdapter, then that logic needs to be extracted out into a class that uses the IContactsFolder or IExchangeService interfaces. Adapters should do nothing but translate one interface into another.