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:
- 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. - 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
Post a Comment