c# - What are the advantages to wrapping system objects (File, ServiceController, etc) using the Adapter pattern vs. detouring for unit testing? -


consider following method stops service:

public function stopservice(byval servicename string, byval timeoutmilliseconds double) boolean      try         dim service new servicecontroller(servicename)         dim timeout timespan = timespan.frommilliseconds(timeoutmilliseconds)          service.[stop]()          if timeoutmilliseconds <= 0             service.waitforstatus(servicecontrollerstatus.stopped)         else             service.waitforstatus(servicecontrollerstatus.stopped, timeout)         end if          return service.status = servicecontrollerstatus.stopped      catch ex win32exception         'error occured when accessing system api'         return false     catch ex timeoutexception         return false     end try  end function 

in order unit test the method have 2 options:

  1. use adapter pattern wrap servicecontroller class's methods need interface can control. interface can injected service class (a.k.a inversion of control). way have loosely coupled code , can use traditional mocking frameworks test.
  2. keep class , use microsoft moles (or other code detouring framework) intercept calls servicecontroller return canned results testing purposes.

i agree domain model code using "traditional" unit testing approach makes sense lead design easiest maintain. however, code deals .net implementation of windows api related stuff (file system, services, etc), there advantage going thru work "traditionally" testable code?

it's hard me see disadvantages of using microsoft moles things such servicecontroller (or file object). don't see advantage of doing traditional approach in case. missing anything?

great question btw.. had @ ms moles video right now. although i'm skeptical of ms unit-testing tools, must 1 looks interesting. comparison stands at:

adapter/facade

  • pro: allows extract meaningful role intention revealing methods. e.g. servicemanager.startservice(name) abstract details {1. servicecontroller.getservices(), 2. handle case servicecontroller.status != stopped, 3. servicecontroller.start()}. mock/fake approach here involve less work setting 3 delegates. here approach opportunity improve design coming meaningful contracts/interfaces (also allows hide stuff don't care -- e.g. winapi semantics, constants, etc)
  • pro: mocking frameworks give better diagnostics argument checks, number of times called, expectations not called etc.

interceptor

  • pro: less work if you're interested in stubbing out problematic call on dependency
  • pro: tool in toolbox when dealing legacy code (where fear of change overwhelming)
  • con: have mstest dependency? initial searches seem indicate need plugins or extensions if you're not using mstest.

Comments

Popular posts from this blog

python - Scipy curvefit RuntimeError:Optimal parameters not found: Number of calls to function has reached maxfev = 1000 -

c# - How to add a new treeview at the selected node? -

java - netbeans "Please wait - classpath scanning in progress..." -