使用适配器模式包装系统对象(文件，ServiceController等)与进行单元测试绕行相比有什么优势?

问题描述

考虑以下停止服务的方法:

Consider the following method that stops a service:

Public Function StopService(ByVal serviceName As String, ByVal timeoutMilliseconds As Double) As Boolean

    Try
        Dim service As New ServiceController(serviceName)
        Dim timeout As TimeSpan = TimeSpan.FromMilliseconds(timeoutMilliseconds)

        service.[Stop]()

        If timeoutMilliseconds <= 0 Then
            service.WaitForStatus(ServiceControllerStatus.Stopped)
        Else
            service.WaitForStatus(ServiceControllerStatus.Stopped, timeout)
        End If

        Return service.Status = ServiceControllerStatus.Stopped

    Catch ex As Win32Exception
        'error occured when accessing a system API'
        Return False
    Catch ex As TimeoutException
        Return False
    End Try

End Function

为了对方法进行单元测试，我基本上有两个选择:

In order to unit test the the method I basically have two options:

1. 使用Adapter模式将所需的ServiceController类的方法包装到我可以控制的接口中.然后可以将此接口注入服务类(也称为控制反转).这样，我就有了松散耦合的代码，并且可以使用传统的模拟框架进行测试.
2. 按原样保留课程并使用Microsoft Moles(或任何其他代码绕行框架)拦截呼叫ServiceController到返回罐装结果进行测试目的.

1. Use the Adapter pattern to wrap the ServiceController class's methods I need into an interface I can control. This interface can then be injected into the service class (a.k.a Inversion of Control). This way I have a loosely coupled code and can use the traditional mocking frameworks to test.
2. Keep the class as is and useMicrosoft Moles (or any other codedetouring framework) to interceptthe calls to ServiceController toreturn canned results for testingpurposes.

我同意对于域模型代码，使用传统"单元测试方法最有意义，因为这将导致设计最易于维护.但是，对于处理Windows API相关内容(文件系统，服务等)的.net实现的代码，进行额外的工作以获得传统上"可测试的代码是否真的有优势?

I agree that for domain model code that using the "traditional" unit testing approach makes the most sense as this would lead to a design that is easiest to maintain. However, for code that deals with the .net implementation of Windows API related stuff (file system, services, etc), is there really an advantage to going thru the extra work to get "traditionally" testable code?

我很难看到将Microsoft Moles用于诸如ServiceController(或File对象)之类的缺点.在这种情况下，我真的看不到采用传统方法的任何优势.我想念什么吗?

It's hard for me to see the disadvantages of using Microsoft Moles for things such as ServiceController (or the File object). I really don't see any advantage of doing the traditional approach in this case. Am I missing anything?

推荐答案

顺带问一句..现在就看MS Moles视频.尽管我对MS单元测试工具表示怀疑，但我必须说这看起来很有趣.我的比较是:

Great question btw.. Just had a look at MS Moles video right now. Although I'm skeptical of MS Unit-testing tools, I must say this one looks interesting. My comparison stands at:

• Pro:允许您通过意图揭示方法来提取有意义的角色.例如ServiceManager.StartService(name)可以抽象细节{1. ServiceController.GetServices()，2.处理其中ServiceController.Status！=已停止的情况，3. ServiceController.Start()}.与设置3个委托相比，此处的模拟/伪造方法所需的工作更少.在这里，这种方法是通过提出有意义的协定/接口来改进设计的机会(也使您可以隐藏不需要的东西，例如Winapi语义，常量等)
• 专业版:模拟框架可以为您提供更好的诊断方法，例如参数检查，调用次数，未调用期望等.

• Pro: allows you to extract a meaningful role with intention revealing methods. e.g. ServiceManager.StartService(name) could abstract the details {1. ServiceController.GetServices(), 2. handle case where ServiceController.Status != Stopped, 3. ServiceController.Start()}. The mock/fake approach here would involve less work than setting up 3 delegates. Here this approach is an opportunity to improve your design by coming up with meaningful contracts/interfaces (also allows you to hide stuff that you don't care about -- e.g. Winapi semantics, constants, etc)
• Pro: Mocking frameworks would give you better diagnostics for argument checks, number of times called, expectations not called etc.

• Pro:如果您只想对依赖项中有问题的调用进行存续
，则工作量会减少
• 专业版:在处理遗留代码(对更改的恐惧压倒一切)时，绝对是您工具箱中的好工具
• 骗局:它具有MSTest依赖项吗?初步搜索似乎表明，如果您不使用MSTest，则需要一些插件或扩展.

• Pro: Less work if you're just interested in stubbing out a problematic call on a dependency
• Pro: definitely a good tool in your toolbox when dealing with legacy code (where the fear of change is overwhelming)
• Con: does it have a MSTest dependency? Initial searches seem to indicate that you need some plugins or extensions if you're not using MSTest.

这篇关于使用适配器模式包装系统对象(文件，ServiceController等)与进行单元测试绕行相比有什么优势?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！