TDD 应该具有 100% 的代码覆盖率。这是否意味着应该为属性 getter 和 setter 以及其他不包含实际逻辑的方法(例如处理外部 API 功能)编写测试?

示例 1:

下面是一个示例方法(它恰好也是 this other SO question 中的示例,它处理如何最好地测试它,如果我们要测试它的话)。这种方法作用不大。它是停止服务的 System.ServiceProcess.ServiceController 功能的一个外观。目前这段代码不是使用 TDD 编写的,但如果是,是否应该测试一下?这里的逻辑很少。测试本身并没有那么有用。

仅供引用: 如果您想回答如何最好地测试它(IoC 和适配器模式与绕道),请参阅 this other SO question

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

    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
        Return False
    Catch ex As TimeoutException
        Return False
    End Try

End Function

示例 2:

如果有人认为代码仍然有一些逻辑,因此在进行 TDD 时需要对其进行测试,那么下面的代码有 没有 逻辑呢:
Public Function GetProcess(ByVal serviceName As String) As Process
    Dim managementObject As New ManagementObject(String.Format("Win32_service.Name='{0}'", serviceName))
    Dim processID As Integer = CType(managementObject.GetPropertyValue("ProcessID"), Integer)
    Dim process As Process = process.GetProcessById(processID)
    Return process
End Function

最佳答案

TDD 不应该有 100% 的代码覆盖率。与其他方法相比,TDD 往往具有非常高的代码覆盖率。如果您在没有失败测试的情况下不编写一行代码,如果您严格遵循这一点,那么是的,您将获得 100% 的覆盖率。但是我们大多数人并没有严格遵守,完美的代码覆盖率并不是 TDD 的目标。高代码覆盖率是测试驱动开发的一个很好的副作用,但这不是重点。

我们中的大多数人不会专门作为 TDD 过程的一部分来测试驱动简单的 getter 和 setter。但是我们不会创建需要 getter 和 setter 的字段,直到我们需要它 - 其中“需要”被定义为失败的测试。因此,理所当然地会测试 getter 和 setter,因为它们是由我们正在测试驱动的方法根据需要创建的。

你的两个例子都有足够的逻辑值得测试;我会试驾他们两个。

关于c# - 当所需的代码几乎没有逻辑时,是否仍然使用 TDD 编写测试?为什么?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/4953032/

10-12 01:30
查看更多