Open andreibancioiu opened 10 years ago
At the company I work for we make substantial use of EWS Managed API. We have created abstractions for the API with inspiration from System.Web.Abstractions, i.e. HttpContextBase, which exposes virtual methods throwing NotImplementedException and HttpContextWrapper which inherits from HttpContextBase and delegates to the real HttpContext object. For instance we have an AppointmentBase class and an AppointmentWrapper class which encapsulates the real Appointment object. This approach has been really successful for us.
Agree. In my project I have a method that accepts a Task object. Right now it is impossible to test the method because to create Task object I need a real ExchangeService object and I couldn't mock Task because all its methods aren't virtual.
Just came across this. Is there any way currently to Mock or Stub the entire exchange-service? I was unable to find anything apart from faking the entire library...
Perhaps it would be practical to gather ExchangeService's operations within an interface or so. This way, applications using the SDK may have the possibility to fake this interface for testing purposes.
Currently, a considerable amount of work should be invested into wrapping functionality of ExchangeService behind facades etc. Regarding this, there's a lot of code duplicated among the meridians :)
Best Strategy for Testing Exchange Web Services API Trying to Mock the Microsoft Exchange Web Service Unit Testing with EWS Managed API
As exposing ExchangeService as an abstraction would imply a lot of work, we may build instead some modules useful for testing right in the heart of the SDK, for example:
Any ideas and opinions? Thanks :)