解释单元测试的关键点是什么？

Question

我想向一些没有或几乎没有单元测试经验的同事介绍单元测试。我将首先介绍大约一个小时的时间来解释这个概念，然后给出很多例子。我将跟进结对编程会话和代码审查。

引导时应该关注哪些关键点？

Answer 1

要保持简短：单元测试大约是两件事

• 验证意图的工具
• 重构的必要安全网

显然，它远不止于此，但对我来说，几乎总结了它。

Answer 2

单元测试测试小东西

要记住的另一件事是单元测试测试小东西，“单位”。因此，如果您的测试针对的是像实时服务器或数据库这样的资源，那么大多数人都称之为系统或集成测试。要单独测试与这样的资源进行对话的代码，人们经常使用mock objects（通常称为模拟）。

单元测试应该快速运行并经常运行

当单元测试测试小东西时，测试运行得很快。这是好事。经常运行的单元测试可以帮助您在发生后立即发现问题。经常运行的单元测试的最终目标是将它们自动化为continuous integration的一部分。

单位测试在覆盖率高时效果最佳

人们有different views关于是否需要100％单元测试覆盖率。我相信高覆盖率是好的，但是有一个收益递减点。作为一个非常粗略的经验法则，我会对代码库感到满意，该代码库具有85％的覆盖率和良好的单元测试。

单元测试不能替代其他类型的测试

与单元测试一样重要的是，其他类型的测试（如集成测试，验收测试等）也可以被视为经过良好测试的系统的一部分。

对现有代码进行单元测试会带来特殊挑战

如果您希望将单元测试添加到现有代码中，您可能需要查看Michael Feathers的Working Effectively with Legacy Code。未考虑测试而设计的代码可能有characteristics that make testing difficult，而Feathers则撰写有关仔细重构代码以便于测试的方法。当您熟悉使测试代码变得困难的某些模式时，您和您的团队可以编写试图避免/最小化这些模式的代码。

Answer 3

你也可能在这里获得一些灵感https://stackoverflow.com/questions/581589/introducing-unit-testing-to-a-wary-team/581610#581610

Answer 4

请记住，单元测试不是银弹，不应取代其他形式的传统测试（功能测试等），但应结合使用。

单元测试在某些方面比其他方面更好，因此进行真正全面测试的唯一方法是将其与其他形式结合使用。

这似乎是我对单元测试的最大批评之一，因为很多人似乎并没有“得到”它不应该替换其他形式的测试。

Answer 5

要点：

• 单元测试有助于设计（通过表达意图）和回归测试（永不消失）代码;
• 单元测试适用于 lazy 程序员，他们不想再调试代码 ;
• 测试没有影响或影响业务逻辑和功能的业务，但他们会对其进行全面测试;
• 单元测试需要与常规代码相同的质量：theory和strategy，organization，patterns，smells，refactoring; < / LI>

Answer 6

单元测试应该是公平的。

• F 快速
• A 可轻松自动
• 我可以独立
运行
• R 可重复