敏捷词汇表 -- 敏捷联盟
# 单元测试 Unit tests
## 定义
正如敏捷团队所理解的那样，单元测试是由产品团队的开发人员编写和维护的简短程序片段，它使用产品源代码的一小部分并检查结果。单元测试的结果是二进制的：如果程序的行为与记录的期望一致，则“通过”，否则，则“失败”。开发人员通常会编写大量的单元测试（对应于大量感兴趣的程序行为），称为“测试套件”。按照惯例，至少可以追溯到JUnit工具系列，红色（如“获得红色条”所示）表示一个或多个测试失败。绿色（“绿色条”）表示成功执行与程序相关的“所有”单元测试。
## 也称为
术语“单元测试”在行业中具有不同的含义，表示传统软件开发生命周期中的活动或阶段，这使其与（例如）系统测试区分开来。这些术语不一定暗示有关自动化的任何内容。为了避免造成混淆，一些敏捷作者因此提倡使用“开发人员测试”一词，将其与“客户测试”区分开来，并强调负责各种类型测试的角色。
## 常见陷阱
上面提到的术语上的变化是造成很多混乱的根源，关于“测试”在敏捷团队中的含义的争论仍在继续。敏捷已导致开发人员高度重视自动检查程序的使用，并且这倾向于使其他形式的测试（特别是由专业测试人员进行的测试）边缘化。然而，这项工作（一些敏捷团队将其称为“ 探索性 ”测试）在敏捷环境中同样重要。还请记住，开发人员用来检查自己的代码的自动化单元测试的实践与测试驱动的开发的结构化更严格的约束之间的区别。
## 预期收益
- 依靠自动化单元测试的团队可以期望从测试驱动的开发中获得一些好处，尤其是缺陷率的降低
## 起源
- 1976年：D。Panzl撰写的一系列文章描述了功能与JUnit极为相似的工具，证明了自动单元测试的悠久历史
- 1988-1990年：事件驱动的GUI软件的兴起及其特定的测试挑战为诸如Segue或Mercury等公司提供的“捕获和重放”测试自动化工具创造了机会；这种工具将在未来十年内占领市场
- 1997年：测试工具JUnit由Beck和Gamma编写，灵感来自于Beck早期在SUnit上的工作；它在接下来的几年中越来越受欢迎，标志着“捕捉和重放”时代的结束。
点击看敏捷名词地铁线路全图