所以..我需要对团队进行单元测试培训——可以在课程计划中使用 C&C

Question

所以 - 管理层正在寻求推动在所有未来的应用程序中进行单元测试 - 并最终进入完整的 TDD/持续集成/自动化构建模式（我希望如此）。然而，在这一点上，我们只关心让每个开发应用程序的人都使用单元测试向前发展。我想从基础开始。

我不会撒谎 - 我在单元测试方面无论如何都不是专家，但我确实有足够的理解来从基础开始这项计划，并让我们作为一个团队共同成长。我真的很想从你们所有的专家那里得到一些关于我对这件事的攻击计划的批评和批评。这是一个由大约 10 名开发人员组成的小商店团队，这为推进敏捷开发方法和最佳实践提供了绝佳机会。

首先 - 团队主要由中级开发人员组成，有几个初级开发人员和一个高级开发人员，他们几乎没有接触过单元测试。培训将是每半个月一次的会议，每次约 30-60 分钟（我猜可能会跑一个小时，而且可能更频繁）。我们将继续这些会议，直到有必要阻止他们让其他人赶上他们自己的“功课”和经验——但我们会一直在推动。

无论如何 - 这是我想出的课程计划。好吧，至少前两个。您的专家就课程的实际内容或结构等提供的任何建议都会很棒。非常感谢评论和批评。非常感谢。

如果这“太多”无法在此处发布或通读，我深表歉意。我认为对于希望首先进行单元测试的 SO 用户来说，这将是一个很好的线程。也许您可以直接跳到“课程计划”部分 - 再次感谢大家。

悬崖笔记 - 我意识到这篇文章非常长而且丑陋，所以这里是悬崖笔记 - 第 1 课将是“hello world 单元测试” - 第 2 课将为我最近的应用程序打开解决方案，并展示如何在现实生活中应用每个“hello world”示例......非常感谢大家迄今为止给我的反馈......只是想强调一个事实第 2 课 将包含现实生活中的生产单元测试，因为很多人建议我这样做，而这是我从一开始的计划 =)

单元测试课程计划

概述

为什么要进行单元测试？看起来像是一堆额外的工作 - 那为什么要这样做？

• 成为自己命运的主人。我们的大多数用户不做真正的 UAT，不幸的是，他们倾向于在生产中进行一次测试。通过单元测试，我们大大降低了与此相关的风险，特别是当我们创建足够的测试数据并尽可能多地考虑顶级输入时。虽然它不是防止所有错误的“灵丹妙药”——它是你的第一道防线——但它是一条巨大的前线，可与 SB 冠军巨人队相媲美。

• 单元测试强制执行良好的设计和架构实践。可以这么说，是“维护你的代码并知道你住在哪里的暴力精神病患者”。您根本无法编写经过良好单元测试的低质量代码

• 您有多少次因为太害怕破坏某些东西而没有重构臭代码？自动化测试消除了这种恐惧，使重构变得更加容易，进而使代码更具可读性和更易于维护。

• 底线 - 维护变得更容易和更便宜。现在花在编写单元测试上的时间可能很昂贵——但它为你节省的时间已经一次又一次地被证明是更有价值的。这是自动化测试代码的第一大理由。它给了我们信心，使我们能够对系统进行更雄心勃勃的更改，否则我们可能不得不减少对系统的要求，甚至可能根本不进行。

术语审查

• 单元测试 - 测试最低级别的单个工作单元。例如。 – 测试单个函数可以通过的所有可能的代码路径。

• 集成测试 - 测试您的单元如何协同工作。例如。 – 运行一个“工作”（或一系列函数调用），它使用已知输入完成大量工作 – 然后在最后查询数据库并断言这些值是您对这些已知输入的期望值（而不是必须关注- 在某处的网页上放置一个网格，例如进行功能测试）。

• 赝品——赝品是一种用于测试的对象。它允许您太容易不测试您不想测试的代码。不必调用您不想要的代码（例如数据库调用），您可以使用假对象来“伪造”该数据库调用，并可能从 XML/Excel 文件或模拟框架中读取数据。 o Mock – 一种您对其作出断言声明的假货。 o 存根 – 一种用作占位符代码的伪代码，因此您可以跳过数据库调用，但不要针对其进行断言

课程

第一课 - Hello Worlds

• Hello World 单元测试 - 我将创建一个经过单元测试的“hello world”控制台应用程序。将在会议期间即时创建此应用程序，展示 Visual Studio 2008 中的工具（测试项目、测试工具工具栏等），同时解释它们的作用。这将只有一个单元测试。 （好吧，也许我不会“即时”创建它=），必须多考虑一下）。还将解释 Assert 类及其用途以及单元测试的一般流程。

• Hello World，有点复杂。现在我们的函数有不同的路径/逻辑分支代码可以流过。我们将对此功能进行大约 3 个单元测试。这将是我在会议之前预先制定的解决方案。

• Hello World，依赖注入。 （不使用任何 DI 框架）。一种基于前一个解决方案的预写解决方案，这次使用依赖注入。将解释什么是 DI 并展示其工作原理的示例。

• Hello World，模拟对象。一个基于前一个解决方案的预写解决方案，这次使用我们新添加的 DI 代码将模拟对象注入到我们的类中，以展示模拟是如何工作的。将使用 NMock2.0，因为这是我接触过的唯一一个。非常简单的示例，仅显示模拟对象的使用。 （也许把这个放在单独的课程中？）。

• Hello World，（非自动）集成测试。在之前的解决方案的基础上，我们创建了一个集成测试，以展示如何一起测试 2 个函数，或一起测试整个类（也许将这个放在单独的课程中？）

第二课——现在我们知道了基础知识——如何在现实生活中应用它？

• 最佳实践概述 o 规则 #1 - 单一责任主体。单一责任主体。单一责任主体。开玩笑地说这是编写代码时要记住的最重要的事情。一个类应该只有一个目的；一个函数应该只做一件事。这里的关键词是“单元”测试——SRP 会将你的类和函数封装到单元中。 o 依赖注入是你第二好的朋友。 DI 允许您在运行时将行为“插入”到您拥有的类中。除此之外，这就是我们使用模拟框架使我们的更大类更容易测试的方式。

o 在编写代码时，请始终考虑“我将如何测试它”。如果它看起来“太难测试”，很可能是你的代码太复杂了。重新分解，直到它变成更多逻辑单元的类/函数 - 把一个做 5 件事的类变成 5 个类，一个调用另一个 4 个。现在你的代码将更容易测试 - 也更容易阅读和重构。

o 测试行为，而不是实施。简而言之，这意味着我们可以在大多数情况下只测试我们类上的公共函数。我们不关心测试私有的（实现），因为公共的（行为）是我们调用代码使用的。例如……我是一个百万富翁的软件开发人员，去阿斯顿马丁经销商处为自己买了一辆全新的 DB9。销售人员告诉我，它可以在 3 秒内完成 0-60。你将如何测试这个？你会举起发动机并进行诊断测试等吗？不...你会把它带到大路并以 160 英里/小时的速度行驶 =)。这是测试行为与实施。

• 审查一个真实的单元测试应用程序。在这里，我们将回顾上面的每个“hello world”示例——但以我最近的项目为例，但都是现实生活中的版本。我将打开一个简单的单元测试，一个更复杂的单元测试，一个使用 DI，一个使用 Mocks（可能与 DI 耦合）。这个项目相当小而且简单，所以它真的很适合。这还将包括测试 DAL 以及如何设置测试数据库来运行这些测试。

Answer 1

我喜欢您在这里表达的承诺和彻底性，但我的感觉是，与您直接开始、配对并编写一些实际的生产测试相比，您的采用计划将需要更长的时间。无论如何，您都需要基础设施——为什么不使用 CI 服务器和 TDD 框架引导您的实际生产代码呢？ （很多时候，这是一个比学习“断言”更大的痛点。尽早解决这部分问题）。然后坐下来和其他程序员一起解决一个实际问题。选择一个简单的错误或小功能，并尝试识别失败的测试会是什么样子并尝试编写它们。

我喜欢 Hello Worlds 作为棕色袋午餐之类的东西。但我想不出任何理由不直接介入并解决一些问题。

Answer 2

我在公司内部帮助设计和运行了针对 Java 开发人员的测试驱动开发培训。我们最终将其作为一整天的培训进行，并且我们将其分解为类似于您在这里的方式。

1. 为什么要进行测试？
2. 简单示例。
3. 更复杂的示例。

我必须强调的一点是，人们需要边做边学。

在我的培训中，我们建立了一个实验室环境，每个学生都可以从相同的代码快照开始，然后自己开发和运行测试，讲师在培训室里走来走去，帮助那些感到困惑或没有得到的人它。

对于“简单示例”，我们有一个“烹饪秀”版本的代码，它在投影仪上并逐步完成了 TDD 过程。开发人员必须经历编写测试的过程，然后创建足以通过测试的实现，然后重复。在每个阶段，在学生有时间自己尝试后，投影仪上会显示当前阶段的准备解决方案。

对于“复杂示例”，我们创建了一组要求，然后允许学生使用 TDD 提出自己的解决方案。我们甚至进行了一次练习，其中要求惊喜，惊喜在练习的过程中突然发生了变化。

我喜欢你的想法，即通过定期检查在更长的时间内这样做。我们培训的一个缺点是缺乏后续行动。我敢肯定，开发人员从培训中受益，但我认为很多人并没有将实践带回到他们的日常工作中。定期检查将有助于养成单元测试的习惯。

如需更多想法，请查看我对this question 的回复。

Answer 3

让人们对其他人的/示例代码进行单元测试并不像让人们对他们必须编写的一些新代码“从测试用例开始”那样有效。 涵盖从测试用例开始并三角测量到有效结果的基础知识（一直强调失败的测试是进步的）。

也就是说，我个人的经验是，像这样的事情最好在结对编程环境中完成。这对您来说是额外的工作，但结合一对一、一些所有权和他们可以在最后参考的工作示例将使采用变得更加容易。

在适当的环境下，稍后运行覆盖工具可以提供一种有趣、有竞争力和令人满意的方式来标记进度。以任何方式将其作为补偿/奖金的一部分是一个非常糟糕的主意。做得正确，人们会采用它，因为它有效。

Answer 4

我尝试在一个小团队（7-9 名程序员）中引入 TDD。讲座失败。人们持怀疑态度，TDD 听起来像蛇油。此外，还有众所周知的威利。

最后，团队中的人不使用 TDD，而是偶尔进行 DDT（开发驱动测试）：编写单元测试在代码之后，以确认它是否符合他们的意图。看起来完全失败了，直到您意识到这种形式的开发人员驱动的 QA 也比以前的要好得多，因为即使它并没有真正改进代码以供将来重新访问，它也会减少已部署的错误。

但是，与您的设置相比，有一个关键区别：推动并非来自管理层，他们只是足够好，让程序员自己决定。

讲座失败了，但我没有把所有的鸡蛋都放在一个篮子里。我为整个项目中使用的许多更小、更集中的函数和类编写了一堆测试。那些你偶尔需要稍微弯曲以完全适应下一个调用站点的小虫子，希望你没有破坏任何现有的（你查看了代码，更改似乎是安全的）。它在每隔一个svn up（不仅是我）之后运行测试，随后对有罪提交电子邮件的回复“你弄坏了，请尽快修复！”这最终让他们相信单元测试至少有部分效用。

无论您为讲座想出什么示例，他们都会告诉您它之所以有效，是因为 CUT 不切实际地（或异常地）与其余代码隔离开来。他们会要求你为一个复杂的、有缺陷的 God Class 编写单元测试（最好是单例，每个人都喜欢全局变量，不是吗？）因为据他们所知，这就是现实世界的代码的样子，而且他们认为使用 TDD 也会是这样。

搞砸讲座。让管理层在圣诞节给大家买几本书：至少 TDD By Example (Beck) 和 Refactoring (Fowler)。从经验来看，这些书不一定对大多数书有任何影响（更多的是“这还不够现实世界”的废话），但它一定会吸引某人，而且，无意冒犯，我打赌 1000 美元，贝克是你们两个中更好的传道者。 ;) 在与他们共享的代码中自己练习 TDD。如果它真的有效，他们会效仿。 Sss-looowww-lyyyy，但他们会的。

再一次，也许你的团队中没有那么多威利斯，也许你的同事很热心，只是需要一个领导者，我真的不知道，你没有告诉。

第一条诫命：不要因缓慢和/或部分摄入而退缩：每一英寸都很重要！ （我在这里自言自语，你知道...）

Answer 5

我认为从 test-after 类型的测试开始会更难。与 test-first 相比的一个主要区别是 test-after 不会指导您编写易于测试的代码。除非你先做过 TDD，否则很难写出code for which it's easy to write tests。

我建议从 TDD/BDD 开始，在掌握了窍门之后，继续学习如何在 legacy code（也为 PDF）上进行测试。 IMO，做好后测试比先测试要困难得多。

为了学习TDD，我建议完成this tutorial。这应该让你开始编写什么样的测试。

Answer 6

我认为这是一个或两个会话的好大纲。但我强烈建议首先建立一个测试基础架构并让开发人员为早日取得成功做好准备，而不是把开发人员一头扎进单元测试世界并大喊“准备好，准备好，开始吧！”

假设您在 IDE 中进行开发，一键式测试生成器工具将真正有助于第一步测试创建。您需要将基于 GUI 的测试运行程序与您的 IDE 集成，并且您确实需要一个与您的 CI 构建集成的自动化测试运行程序。拥有与测试运行工具集成的代码覆盖率工具将帮助开发人员增加他们的覆盖率。您需要为开发人员提供一个完整的框架来编写测试，其中包括记录如何组织测试源代码（测试命名标准、项目设置、文件夹位置等）。自动化任何手动步骤的工具都可以很长的路要走。为您所依赖的任何内部或第三方库 API 提供一个模拟框架，包括模拟对象。如果您要推荐一个充满假数据的数据库（而不是一套假数据访问对象），请创建一个包含几个关键表的数据库并用测试数据填充它，并提供在测试运行之间重置它所需的一切。如果没有，请提供一些您自己的虚假 DAO 作为示例。您应该在源代码控制系统测试生产代码中已经有一小套测试作为示例显示。您需要将所有这些记录在案，以便在会议 #1 中分发。 （别忘了测试文档！）

我们的一个团队在几年前尝试了 ad hoc 方法，但采用率很低。如果没有测试的定义或组织，个别开发人员会做他们自己的事情。缺乏命名标准使得很难确定为哪些模块运行正确的测试，而且很少有人为此烦恼。我们没有任何 IDE 集成。没有人想写 mock，我们也没有提前为我们使用的框架提供 mock。并且很难将测试添加到没有考虑依赖注入的遗留代码中。

我现在正在尝试重新组织我们的基础架构，并准备好再次完成这项任务。只有在它站起来之后，我才会努力让开发人员再次使用它。

但是，您有一个我们上次有点缺乏的东西，那就是强大的管理支持。我们以前的经理对这个想法有点冷淡，因为他们不想通过编写所有这些测试来延迟编码。我们现在有了新的管理层，他们专注于代码质量——自动化单元测试现在很流行，所以现在是我们再试一次的好时机。

Answer 7

课堂风格的方法是否会奏效？这是我想到的一个问题，因为这里可能发生的情况是知识和想法的应用之间存在很大的分离，虽然他们可能知道，但他们并不完全了解如何使用它。

只是为了提供一种不同的方法，一个人可以跳入任何正在进行的项目并开始尝试应用其中的一些，这可能需要一段时间才能渗透到每个人，因为你的想法是训练一个然后作为一对，你会训练另一对，以此类推，试图让每个人都达到同一点。这样一来，不相关的理论内容就会被提早删除。

另一个想法是看看尝试在 10 人一组中组建团队是否有意义，例如 2 组 3 人和一组 4 或 5 对，这样每个人都可以展示他们所做的事情以及他们如何使用它。

我将支持边界测试，并说明为什么使用无效输入进行测试以查看这不会导致系统翻转和死机是有用的。

最后，花时间处理人们遇到的问题和其他一对一问题可能是有意义的，因为不是每个人都想在一大群人面前提问。

编辑：关于第 2 课的注意事项，这是一个好主意，但需要注意一些危险。首先，在上这节课时要谦虚，这样你就不会被认为是想要抨击其他人的炫耀。其次，我建议在复习时保留一些不完整的测试，以便这里有一个交互方面，可以防止其他开发人员只是调整或翻白眼。第三，一个或两个其他的后续课程展示他们做了什么，或者你回顾他们做了什么，这可能更有用地表明这是一个团队的努力在某些方面。

Answer 8

如果管理层对此很认真，那么他们就必须不顾一切地采取行动，而不仅仅是接受一点培训。开始让他们要求查看代码审查中的测试。一旦这很常见并且人们知道他们不会在没有测试的情况下通过代码审查，然后让他们拒绝部署新代码，直到编写测试。只需要进行几次迭代，人们就会知道他们不能不编写测试就逃脱，然后他们会相当可靠地这样做。是的，经理第一次拒绝部署时，可能会迟到。他们必须在自己的计划中考虑到这一点。他们还需要开始在他们的任务估算中增加测试写作时间。如果他们认为自己会受到指责，那么没有人愿意这样做，因为编写测试和代码比仅仅编写代码需要更长的时间。有一个关于如何实施的发布时间表（在所有新开发都需要之前，你需要给他们一些时间来学习如何做到这一点）并且在截止日期，没有测试就没有任何东西可以刺激。

Answer 9

我喜欢。我的一条评论是，关于如何测试线程/异步代码的一些指南/建议可能值得一提。

另外，我要评论一下边界测试，即使用单元测试来陈述您对您使用的任何第 3 方 API 的假设。

Answer 10

仅仅因为我一直在做一些 TDD（以及一般的单元测试）非常宝贵的事情，并且因为它可能会成为一个很好的演示，所以我建议使用 Regex 的示例，特别是如果您不是 Regex 专家，很容易出错。

这也是一个很好的“展示，而不是告诉”演示。如果你只是：

第 1 步：告诉他们只需使用正则表达式编写一些代码来匹配特定模式。

第 2 步：将模式扩展到其他内容。

第 3 步：展示单元测试如何立即让他们确定 a) 它与新模式匹配并且 b) 它没有破坏任何先前的匹配或让不应该的结果通过。

在您评论的一般 C&C 中，很难准确了解将发生哪些序列事件。此外，如果中间只有一个空白而没有推动应用他们的知识，那么半月似乎太少见了。你最不想要的就是成为他们一离开房间就去参加的会议！

您当前的工作负载是否有足够的停机时间来解决技术债务并让团队真正结对并开始考虑向某些现有功能添加单元测试并在必要时进行重构以允许模拟？

我会说这将证明比讲座和盆栽研讨会更有效，YMMV。