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

【问题标题】：What are key points to explain Unit Testing解释单元测试的关键点是什么
【发布时间】：2010-01-29 10:37:28
【问题描述】：

我想向一些没有或很少有单元测试经验的同事介绍单元测试。我将从大约一个小时的演示开始，解释这个概念并举出很多例子。我将跟进结对编程会议和代码审查。

介绍中应该重点关注哪些重点？

【问题讨论】：

您只是在寻找单元测试吗？还是您打算帮助他们进行测试优先编程或测试驱动开发？
目标是针对任何新功能进行测试驱动开发，并向当前未测试的代码添加单元测试

标签： unit-testing

【解决方案1】：

简而言之：单元测试涉及两件事

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

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

【讨论】：

【解决方案2】：

单元测试测试小事

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

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

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

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

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

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

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

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

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

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

请记住指出，单元测试不是灵丹妙药，不应取代其他形式的传统测试（功能测试等），而应结合使用。

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

这似乎是我看到的对单元测试最大的批评之一，因为很多人似乎没有“明白”它不应该完全取代其他形式的测试。

【讨论】：

【解决方案5】：

要点：

单元测试有助于设计（通过表达意图）和回归测试（通过永不消失）代码；
单元测试适用于不想再次调试代码的懒惰程序员；
测试没有影响或影响业务逻辑和功能的业务，但它们确实对其进行了全面测试；
单元测试需要与常规代码相同的质量：theory 和 strategy、organization、patterns、smells、refactoring；

【讨论】：

【解决方案6】：

单元测试应该是公平的。

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

【讨论】：