我想开始讨论您在单元测试中涵盖的细节。
您是否测试由多种方法组成的主要功能，通过一次测试同时执行一项任务？
或者您甚至可以测试自动属性？
因为，例如，我认为编写仅测试以下内容的测试没有什么价值：
public Email
{
set
{
if(Regex.Match(/*....*/))
email = value;
}
get
{
return email;
}
}
因为它真的很清楚，但这只是浪费时间。
通常，当我进行单元测试时，我会测试整个任务 - 就像这个例子一样 - 整个注册过程。
我问这个问题是因为，目前我正在阅读吉米·尼尔森（Jimmy Nilsson）撰写的《应用领域驱动设计和模式》一书，他在书中指出，他正在通过专门的测试来测试如此小的细节。
这样的覆盖程度是否属于过度使用？
测试不仅仅是为了测试您编写的内容是否有效。测试还可以测试您编写的内容是否仍然有效。就像很多年后和许多开发人员一样。您认为非常简单的类将来可能会变得更加复杂。
例如，假设它开始时没有过滤器。只是一个简单的获取/设置。为什么要测试这个？后来其他一些开发人员添加了正则表达式过滤器，但它出现了错误。然后突然间课程被破坏了，但它未经测试，所以没有人知道。这表明调用堆栈上层存在神秘故障，现在需要更多时间进行调试。可能比编写一些测试所需的时间还要多。
然后，在未来，有人会尝试变得聪明并优化你的代码。或者重新格式化它，正则表达式往往会写成不可读的，并且通常可以进行一些清理。这对于微妙的破坏来说已经成熟了。小型有针对性的单元测试会发现这一点。
在上面的示例中，正则表达式可能是为了过滤看起来像电子邮件地址的内容。这需要检查正则表达式是否正常工作，否则您的电子邮件类将停止接受电子邮件。或者它开始胡言乱语。也许您的正则表达式没有涵盖有效的电子邮件地址，一旦您发现它就值得测试。最终，有人会用实际的解析器替换你的正则表达式。也许有效，也许无效。一个好的测试将有一个有效和无效电子邮件地址的简单列表，您可以在发现极端情况时轻松添加到该列表。
测试还可以让您测试您的界面并发现漏洞。当您输入电子邮件地址以外的内容时会发生什么？没错，什么也没有。 Email.set 默默地丢弃输入。进来的是垃圾，什么也没有出去，这是非常不礼貌的。也许它应该抛出异常。当您尝试测试它时，这一点很快就会变得清晰，因为有必要测试该集合是否有效。
测试还可以揭示不灵活性以及无法覆盖或定制的事物。在您的示例中，直接测试正则表达式过滤器会很方便，而不必每次都实例化一个对象。这是因为过滤器是最复杂的部分，并且在经过尽可能少的层时更容易测试和调试。通过将其放入Email.is_email_address您现在可以直接测试它。作为副作用，它也可以在子类中被覆盖。这很方便，因为大多数人都会进行电子邮件验证WRONG因为电子邮件讨厌生活!
最后，您希望您的测试是解耦的。在不受额外复杂性影响的情况下测试一件事，这样您就可以清楚地看到问题的根源。您的 Email 类非常适合进行简单、解耦的单元测试。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
