唯一的逻辑是警卫的单元测试方法是否有用？

说我有一个这样的方法：

public void OrderNewWidget(Widget widget)
{
   if ((widget.PartNumber > 0) && (widget.PartAvailable))
   {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

我的代码中有几种这样的方法（异步Web服务调用的前半部分）。

我正在辩论将它们包含在单元测试中是否有用。是的，这里有逻辑，但这只是保护逻辑。（这意味着在允许进行Web服务调用之前，请确保已拥有所需的东西。）

我有一部分说“确保可以对它们进行单元测试，但这不值得花时间”（我在一个已经落后于进度的项目中）。

但是我的另一面说，如果您不对它们进行单元测试，并且有人更换了Guards，那么可能会有问题。

但是我的第一部分说，如果有人更换了警卫，那么您将为他们做更多的工作（因为现在他们必须更换警卫和警卫的单元测试）。

例如，如果我的服务承担检查Widget可用性的责任，那么我可能不再想要那个守护者。如果正在单元测试中，我现在必须更改两个位置。

我在两种方式上都有利弊。所以我想问一下别人做了什么。

我有一部分说“确保可以对它们进行单元测试，但这不值得花时间”（我在一个已经落后于进度的项目中）。

这是三个非常简短的测试。您花了很多时间问自己这个问题。

但是我的另一面说，如果您不对它们进行单元测试，并且有人更换了Guards，那么可能会有问题。

听这一边。

但是我的第一部分说，如果有人更换了警卫，那么您将为他们做更多的工作（因为现在他们必须更换警卫和警卫的单元测试）。

如果您的维护者是TDD螺母，那么对他们来说将变得更加困难。如果不进行任何相关更改或添加测试，我所做的任何更改都会导致我不得不认真思考。实际上，在进行更改之前，我可能会添加测试。

您的第一部分完全是错误的。轻拍第二部分的背面，然后停止思考。

如果保护逻辑和实际顺序是分开的方法，它将简化单元测试。

在Widget班上

public bool IsReadyForOrdering { get { return PartNumber > 0 && PartAvailable; } }

或其他地方的等效方法

public bool IsWidgetReadyForOrdering(Widget widget)
{
    return widget.PartNumber > 0 && widget.PartAvailable;
}

订购方法

public void OrderNewWidget(Widget widget)
{
   if (IsWidgetReadyForOrdering(widget)) {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

现在测试IsWidgetReadyForOrdering变得容易了。不要再考虑很久了。测试一下！

如果您没有时间进行单元测试，但有时间留给可靠的QA使用，请询问您是否可以抽出部分QA时间来编写单元测试，或者是否可以花一些QA时间不幸的是，无法避免的时间表会迫使您做出让步或使自己丧命，我通常建议第一种选择，因为第二种选择会导致您无法支持/在整个期限内正确维护系统。

就是说，这是关于测试保护者声明的一般问题；是! 绝对测试警卫声明！这些是该方法的行为的重要组成部分，您不想发现有人误解了某个错误，并进行了错误修复并删除了防护措施，或者将其&&改为了||吗？单元测试将确保a）您实际上使警卫正确地掌握了逻辑，并且b）以后在运行单元测试时告诉他们应该出于某种原因，没有人破坏该逻辑而没有抱怨。

上面有一些很好的答案，它们提出的要点非常重要。但是似乎遗漏的一个是您拥有一套全面的单元测试，它们看起来像是一个非常详细的代码规范。如果仅由于代码如此简单就忽略了测试验证，很难看到它可能会出错，那么说明的一部分将丢失。如果我进入的团队错过了这些测试，那么我实际上会认为您的服务没有验证其论点。

代码就是代码。测试时，您应该尝试获得100％的覆盖率。如果它不重要，那就不会在那里。