unit-testing - 单元测试的详细程度

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

8 年前关闭。




Improve this question




我想开始讨论您在单元测试中涵盖的细节。

您是否测试了主要功能，这些功能由多种方法组成，一次测试一次完成一项任务？
或者您甚至可以测试自动属性？

因为，例如，我认为编写仅测试以下内容的测试没有什么值(value):

   public Email
   {
      set
      {
         if(Regex.Match(/*....*/))
             email = value;
      }
      get
      {
        return email;
      }
   }

因为它真的很清楚，这只是浪费时间。
通常，当我进行单元测试时，我会测试整个任务——就像这个例子一样——整个注册过程。

我问这个是因为，目前我正在阅读 Jimmy Nilsson 所著的“应用领域驱动设计和模式”一书，他指出他正在通过专门的测试来测试如此小的细节。

这样的覆盖水平是不是过度使用了？

Answer 1

测试不仅仅是为了测试您编写的内容是否有效。测试也用于测试您编写的内容是否仍然有效。就像，许多年后，许多开发人员。你认为一个死简单的类在 future 可能会变得更加复杂。

例如，假设它开始时没有过滤器。只是一个简单的获取/设置。为什么要测试？后来其他一些开发人员添加了正则表达式过滤器，但它有问题。然后突然类(class)被打破了，但它未经测试所以没有人知道。这将自身表现为调用堆栈进一步向上的神秘故障，现在需要更多时间进行调试。可能比编写一些测试所需的还要多。

然后，在 future ，有人会尝试变得聪明并优化您的代码。或者重新格式化它，正则表达式有写成不可读的倾向，并且通常可以进行一些清理。这对于微妙的破坏来说已经成熟了。小型目标单元测试将捕捉到这一点。

在上面的示例中，正则表达式可能用于过滤看起来像电子邮件地址的内容。这需要检查正则表达式是否正常工作，否则您的 Email 类将停止接受电子邮件。或者它开始胡言乱语。也许您的正则表达式不包含有效的电子邮件地址，一旦您发现它就值得测试。最终，有人会用实际的解析器替换您的正则表达式。也许行得通，也许行不通。一个好的测试将有一个简单的有效和无效电子邮件地址列表，您可以在发现极端情况时轻松添加到其中。

测试还允许您练习界面并发现漏洞。当您输入不是电子邮件地址的内容时会发生什么？没错，没什么。 Email.set 默默地丢弃输入。垃圾进来，什么都不出去，这不是很有礼貌。也许它应该抛出异常。当您尝试对其进行测试时，这一点会很快变得清晰，因为有必要测试该集合是否有效。

测试还可以揭示不灵活和不能被覆盖或定制的东西。在您的示例中，直接测试正则表达式过滤器会很方便，而不必每次都实例化一个对象。这是因为过滤器是最复杂的部分，它更容易测试和调试，同时通过尽可能少的层。通过将其放入 Email.is_email_address您现在可以直接测试它。作为副作用，它也可以在子类中被覆盖。这很方便，因为大多数人都会获得电子邮件验证 错误 因为 EMAIL HATES THE LIVING !

最后，您希望您的测试解耦。测试一件事而不受其他复杂性的影响，这样您就可以清楚地看到问题的根源。您的 Email 类非常适合进行简单、分离的单元测试。