c# - 当所需代码几乎没有逻辑时，是否还会使用 TDD 编写测试？为什么？

Question

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

Answer 1

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

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

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