我很快就会在我的公司做一个 10 分钟的关于单元测试的 Grok 演讲。我自己也一直在尝试，觉得肯定能给公司带来好处。我们已经在我们专门的 QA 团队中进行了 WebInject 测试，但我想尝试向开发人员出售单元测试。
所以只有 10 分钟，你会涵盖什么，为什么？
- 我们是 Microsoft Shop C# Web 应用程序，在我的经验中我使用过 NUnit。
danswain
问问题
459 次
15 回答
15
单元测试是关于信心的。
它使您确信您的代码是可靠的，并且其他人在编写自己的系统部分时可以依赖它。如果你能理解单元测试将有助于消除新系统首次发布时的恐惧，我希望你的听众很快就会变得非常感兴趣。
于 2009-02-04T13:14:26.187 回答
8
我会从一个很多程序员可能熟悉的问题开始：那就是害怕对现有代码进行更改，因为害怕他们可能会破坏某些东西。这如何阻止工作发生，或阻止工作正确完成（因为他们害怕重构），因此导致必须每 x 年重写一次所有内容。
单元测试 -> 重构 -> 活代码。
编辑： 顺便说一句，我不会引用 Michael Feathers 的“所有没有单元测试的代码都是遗留代码”。当我第一次听到它时，它确实让我感到防御。当人们不再感到被冒犯时，10 分钟将结束:-)（我个人认为这句话更真实而不是有用）。
于 2009-02-04T13:27:40.463 回答
4
这是一个关于技术 X 的简短演讲的好格式：
- 为什么你决定先尝试 X
- 你个人从使用 X 中获得了什么
- 你注意到了哪些限制，X 没有解决的问题
不要“推销”或在理论上花费大量时间。事先做好准备，将人们引向您认为最有帮助的书籍、文章或教程的 URL 。对您的演讲感兴趣的人可以在网上查找详细信息。
于 2009-02-04T13:19:05.177 回答
3
试着简单谈谈测试驱动开发的方面：首先编写测试和接口，然后实现所有内容。
也许还有关于持续集成，这意味着一旦您将某些内容签入源代码控制系统，项目就会被编译并运行所有测试，因此开发人员可以立即知道他是否做错了什么。
如果听众中有任何项目经理，也请公平地告诉他们单元测试将使您的项目多花费 15-30% 的时间，但从长远来看这是值得的。
于 2009-02-04T13:15:38.443 回答
2
您可能会提到这将是一个艰难的学习曲线，并且会感觉生产力受到影响，但好处是值得的：
例如，有效地创建一个自动回归测试套件，这反过来又允许您对现有的进行更大的添加或修改，而不必担心您会破坏某些现有功能。
生产代码的创建速度会更慢，但这应该被更高质量的代码所抵消，即更少的错误，从长远来看，这意味着更高的整体生产力。
于 2009-02-04T13:22:25.670 回答
1
正如 Kent Beck 所强调的，问责制是单元测试促进的另一个特征。在IT 对话中收听他的播客。（他关于问责制的观点从 30:34 开始。）
于 2009-02-04T13:31:22.313 回答
1
我认为 10 分钟就足以展示一个简单的示例，说明单元测试如何为您节省时间。
实现一个类（如果你愿意，可以进行 TDD）并展示单元测试如何捕获破坏类的修改。
此外，如果您单独测试，您可以强调如何更快地开发组件（即您不需要启动您的 Web 应用程序、登录、转到您的功能、测试）；你可以运行你的测试。
您可能可以在您公司的一段代码上执行此操作 - 并且可能显示单元测试如何捕获您最近遇到的错误。
于 2009-02-04T13:47:15.947 回答
1
如果您进行演示，请在每个人都熟悉的项目中的一段工作代码上进行演示。避免人为的例子。有关 TDD 的书籍已经充满了它们，而且它们并没有真正说明 TDD 如何在实际项目中发挥作用。
于 2009-02-04T13:59:11.710 回答
1
看在上帝的份上，强调单元测试是为了测试逻辑的“单元”。我讨厌看到没有人期望必须维护的 QA 套件 NUnit 测试，其中每个“单元测试”测试 150 个（二进制）输入文件的有效输出，然后如果一个失败，则自行拉屎，而不告诉你是哪一个。
于 2009-02-04T15:04:43.967 回答
1
我会证明：
- 它对您生成的代码的信心
- 当您更改代码时它提供的信心，因为它通过了单元测试
- 代码覆盖的好处，不再是“哦，从未测试过 else 语句！”
- 在像 Hudson 这样的 CI 平台上为每个构建运行单元测试的好处
FWIW 我们通过 MSTEST 在我们的 Hudson 机器上运行糟糕的视觉工作室测试，我有一个 xslt，Hudson 使用它来将结果转换为 nunit 格式，以便 Hudson 可以破译它们。只是把它放在那里，以防他们希望你坚持使用 Microsoft 测试平台。
于 2009-02-04T15:11:50.707 回答
0
从业务角度来看，您可能想要强调这样一个事实，即单元测试可以“降低”您对代码所做的任何更改的风险。一旦你有了一套单元测试，你就可以对代码库进行更改，并知道什么会中断，什么不会。
进行用户测试可能不是一个坏主意。如果您有一组好的测试，您可以在进行更改后将失败的测试带给用户，让他们验证新结果是否正确。此外，如果您让用户为您编写新的单元测试定义，您可以简化需求收集。他们不需要能够编码，但他们确实需要能够为您提供适当的输入和预期的输出（否则他们如何知道他们要求的更改是否有效？）。
Visual Studio 有一套非常好的单元测试工具，因此一两个示例可能有助于让您的团队了解单元测试在实践中是什么样的。
于 2009-02-04T13:24:22.577 回答
0
穿这件 T 恤;-)
于 2009-02-04T14:06:09.247 回答
0
精心准备的现场演示：
- 在您的“应用程序”中查找“错误”
- 编写一个涵盖此错误的单元测试。
- 修复此错误
- 显示，您的代码是绿色的。
所以你可以证明，没有办法，这个错误会再次发生！
于 2009-02-04T14:16:18.633 回答
0
另一种方法：
提出一个可以通过创建算法来解决的问题。当然，一些相对简单的事情。接下来，在 DLL 项目中对该算法进行编码。尝试潜入一些弱点（i <= array.Length 总是一个好的）。接下来，询问他们将如何测试这个 DLL。
大多数开发人员运行他们的应用程序来测试它们。但是您不能运行 DLL。您可能会收到一些建议，建议您创建一个控制台应用程序来创建执行算法的方法。向他们展示如何设计单元测试来做到这一点。
于 2009-02-04T14:22:33.927 回答
0
有一套很好的资源用于跟进/自主学习：
- java/c#的实用单元测试是这方面的好书
- 肯特贝克关于单元测试的论文
- 使用选择的测试框架链接到任何更大的样本
于 2009-02-04T15:27:40.253 回答