什么是单元测试？

Question

我看到许多问题询问“如何”以特定语言进行单元测试，但没有问题询问“什么”，“为什么”和“何时”。

• 它是什么？

• 它对我有什么作用？

• 我为什么要使用它？

• 我什么时候应该使用它？

• 有哪些常见的陷阱和误解

Answer 1

粗略地说，单元测试是与测试代码隔离地测试代码的各个部分。我想到的直接好处是：运行测试变得自动化且可重复与通过GUI进行点击测试相比，您可以进行更精细的测试请注意，如果您的测试代码写入文件，打开数据库连接或通过网络执行某些操作，则将其更恰当地归类为集成测试。集成测试是一件好事，但不要与单元测试相混淆。单元测试代码应该简短，优美且易于执行。查看单元测试的另一种方法是先编写测试。这就是所谓的测试驱动开发（TDD）。TDD具有其他优势：您无需编写推测性的“将来可能会需要”代码，仅足以使测试通过您编写的代码始终包含在测试中通过首先编写测试，您不得不考虑如何调用代码，从长远来看，这通常可以改善代码的设计。如果您现在不进行单元测试，建议您开始使用它。获得一本好书，几乎任何xUnit-book都可以做，因为这些概念之间可以很容易地转移。有时编写单元测试会很痛苦。当这种方式得到解决时，请尝试寻找可以帮助您的人，并抵制“只写该死的代码”的诱惑。单元测试很像洗碗。它并不总是那么令人愉快，但是可以使您的隐喻厨房保持清洁，并且您真的希望它保持清洁。:)编辑：尽管我不确定这是否如此普遍，但我想到了一个误解。我听说一个项目经理说，单元测试使团队将所有代码编写两次。如果看起来和感觉是那样，那么，您做错了。编写测试不仅通常可以加快开发速度，而且还为您提供了一个方便的“现在我已经完成”的指示符，而您本来可以没有这些。

Answer 2

我不同意Dan（尽管更好的选择可能只是不回答）...但是...单元测试是编写代码以测试系统行为和功能的过程。显然，测试可以提高代码的质量，但这只是单元测试的肤浅优势。真正的好处是：在确保不更改行为（重构）的同时，更轻松地更改技术实现。可以对经过正确单元测试的代码进行积极的重构/清理，而几乎不会在不注意的情况下破坏任何内容。在添加行为或进行修复时使开发人员充满信心。记录您的代码指示代码中紧密耦合的区域。很难对紧密耦合的代码进行单元测试提供一种使用您的API并尽早发现困难的方法指示不太紧密的方法和类您应该进行单元测试，因为这样做符合您的利益，可以为客户提供可维护的优质产品。我建议您将其用于对现实行为进行建模的任何系统或系统的一部分。换句话说，它特别适合于企业发展。我不会将其用于一次性/实用程序。我不会将其用于测试有问题的系统部分（UI是一个常见示例，但并非总是如此）最大的陷阱是开发人员测试的单元太大，或者他们将方法视为单元。如果您不了解控制反转，则尤其如此-在这种情况下，单元测试将始终转变为端到端集成测试。单元测试应该测试个体行为-大多数方法都有许多行为。最大的误解是程序员不应进行测试。只有糟糕或懒惰的程序员才会相信这一点。盖屋顶的家伙不应该测试吗？更换心脏瓣膜的医生是否应该不测试新瓣膜？只有程序员才能测试他的代码是否达到了他的预期目标（QA可以测试极端情况-告诉人们要做程序员不希望的事情时代码的行为，客户可以进行验收测试-代码可以做到吗客户为此支付了什么费用）

Answer 3

与“只是打开一个新项目并测试此特定代码”相反，单元测试的主要区别在于它是自动化的，因此可重复。如果您手动测试代码，则可能会说服您代码在当前状态下运行良好。但是大约一周后，如果您对其进行了一些修改，该怎么办？您是否愿意在代码中有任何更改时手动重新进行测试？可能不是:-(但是，如果您可以在几秒钟之内随时以完全相同的方式单击一次测试，则只要出现问题，它们就会立即向您显示。而且，如果您还将单元测试集成到自动化的构建过程中，即使在看似完全不相关的更改在代码库的遥远部分中破坏了某些内容的情况下，它们也将提醒您注意错误-当您什至不会想到需要重新测试该特定功能。这是单元测试相对于手工测试的主要优势。但是，等等，还有更多：单元测试极大地缩短了开发反馈循环：如果使用单独的测试部门，您可能要花几周的时间才能知道代码中存在错误，而此时您已经忘记了大部分上下文，因此可能要花几个小时才能完成查找并修复错误；OTOH带有单元测试，反馈周期以秒为单位，并且错误修复过程通常遵循“哦，我* t，我忘了在这里检查这种情况”的意思：-)单元测试有效地记录（对您的理解）代码的行为单元测试迫使您重新评估设计选择，从而使设计更简单，更简洁反过来，单元测试框架使您可以轻松编写和运行测试。