unit-testing - 所以..我需要对团队进行单元测试培训 - 可以在类(class)计划中使用 C&C

Question

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

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

首先 - 该团队主要由中级开发人员和几个初级开发人员和一个高级开发人员组成，他们几乎没有接触过单元测试。培训将是每半月一次的 session ，每次大约 30-60 分钟(我猜可能会持续一个小时，而且可能更频繁)。我们将继续这些 session ，直到有必要阻止它们以让其他人 catch 他们自己的“家庭作业”和经验——但插入力将永远持续下去。

无论如何 - 这是我想出的类(class)计划。好吧，至少前两个。您的专家在类(class)的实际内容或结构等方面的任何建议都会很棒。评论和批评非常感谢。非常感谢。

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

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

单元测试类(class)计划

概述

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

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

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

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

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

术语回顾

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

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

• 假货——假货是一种用于测试的对象。它让您很容易不测试不想测试的代码。您不必调用您不想要的代码(如数据库调用)，而是使用虚假对象来“伪造”该数据库调用，并可能从 XML/Excel 文件或模拟框架中读取数据。
o Mock – 一种您对其进行断言声明的假货。
o Stub – 一种用作占位符代码的伪代码，因此您可以跳过数据库调用，但不要对它进行断言

类(class)

第一课 – Hello Worlds

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

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

• Hello World，依赖注入(inject)。 (不使用任何 DI 框架)。一个预先编写的解决方案，它建立在前一个的基础上，这次使用依赖注入(inject)。将解释什么是 DI 并展示其工作原理的示例。

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

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

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

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

o 在编写代码时总是想着“我将如何测试它”。如果看起来“太难测试了”，那很可能是你的代码太复杂了。重构直到它成为类/函数的更多逻辑单元 - 将一个做 5 件事的类变成 5 个类，一个调用其他 4 个。现在你的代码将更容易测试 - 也更容易阅读和重构也是如此。

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

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

Answer 1

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

为什么要做测试？

简单的例子。

更复杂的例子。

不过我必须强调的一件事是 人们需要通过 来学习。

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

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

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

我喜欢您通过定期检查在更长时间内完成这项工作的想法。我们培训的一个缺点是缺乏跟进。我敢肯定，开发人员从培训中受益，但我认为很多人并没有将培训带回他们的日常工作。定期检查将有助于将单元测试作为一种习惯。

有关更多想法，请查看我对 this question 的回答。