在 1998 年，Kent Beck 编写了 sUnit，一个面向 SmallTalk 的单元测试框架。之后，他将这个框架移植到 Java，即 jUnit。从那时起，xUnit 框架扩展到那些最流行的编程语言。比较新的语言，如 Golang 和 Rust，已经将测试直接合并到编译器和标准库中。
什么是一个单元？
一个单元是逻辑上分离的最小代码块
单元测试是一种孤立地测试尽可能小的代码片段的测试。那么，什么是一个单元？
术语“单元”来自数学。数字 1 被认为是单元，因为它是最小的自然数。它是最小的正整数。以此类推，你源代码的一个单元就是逻辑上与其余代码分离的最小代码片段。它是一个完整的且逻辑上不同的代码片段，而且是最小的部分。
在大多数编程语言中，你的单元会是一个函数或方法调用。
单元测试的好处是，如果你的代码由独立的小片段组成，那么，为它们编写测试就相当容易。这种易编写性意味着你可以在开发功能时完成单元测试。
与其它形式的测试相比，单元测试的执行时间相当短。这意味着你可以频繁运行单元测试。随着软件的成熟，一套单元测试是防止回归和降低维护成本的有力工具。
追溯单元测试
| 在考虑将单元测试添加到现有软件时，需要考虑成本和收益。 |
单元测试的一个关键假设是，被测试的软件很容易分成不同的单元。在没有考虑单元测试编写的软件中，这个假设很少成立。向现有软件添加单元测试通常是一种非常好的方法，来稳定软件并防止将来回归，但是重构代码来支持简单的单元测试可能需要大量工作，甚至会引入新的缺陷。在考虑将单元测试添加到现有软件时，需要考虑成本和收益。如果你的代码正在工作，如果代码很少需要修改，如果代码不容易进行单元测试，那么加入单元测试的好处可能无法保证成本。在这些情况下，可以依靠集成测试来防止该领域的缺陷。
什么是集成测试?
集成测试聚焦于整个软件栈
如果单元测试的哲学是基于这样一种认识，即测试小的独立代码片段是防止回归的一种好方法，那么集成测试是基于这样一种理解，即事情通常在边缘状态出错。外部世界是一个混乱的地方，它与你代码交互的地方通常是意外发生的地方。
你可以通过单元测试实现 100%代码覆盖率，但仍然发现你的软件失败。你可能试图从错误的位置读取文件，或者你的软件可能从一个调用的服务得到预期之外的输出，或者它可能以一种无效的方式调用数据库。
尽管单元测试应该快速运行并且数量众多，但是一个好的集成测试策略应该关注较少数量的高影响测试。
这些测试应该跨越单元测试无法跨越的所有界限，写入文件系统，接触外部资源，等等。
当集成测试棘手时
某些外部系统确实很难集成到测试中。这是因为它们在现实世界中有着无法消除的副作用：金融交易、电子邮件发送、物理移动一个喷漆机器人等。在你在测试中放弃并避开它们之前，找找解决方案。
许多外部系统有一个文档化的方法来在集成测试中使用它们。支付处理程序通常有测试信用卡号，可以设置具有测试邮箱账户的测试用户来测试邮件发送。
集成测试越接近真实世界的交互，就越有可能发现问题并提供真正的价值。
Amazon SES——Test email addresses
Paypal——Test credit card numbers
UPS——Test api mode
一个电子商务例子
假设你正在编写一个简单的电商网站，一个简化版的 amazon.com。这里的细节很重要，所以我们假设，你会使用 PostgreSQL 作为你的数据存储，使用 PayPal 进行支付，使用 UPS 进行发货、使用 Amazon Simple Email Service 来发送电子发票邮件。
单元测试：
单元测试策略将以一种孤立的方式测试应用程序的逻辑。这可能包括：
测试税费计算逻辑是否正确地计算出各个司法管辖区的税费
测试放置到购物车数据结构中的项目是否被正确添加
测试折扣代码是否被正确使用
这些领域中的每一个都可能有几个测试。每个测试将验证一小部分功能。单元测试的能力来自它们的数量、简单性以及它们的执行速度和便捷性。
集成测试：
另一方面，你的集成测试将专注于测试你的电子商务代码与其它系统的交互。这意味着不仅要测试与数据存储的集成，还要测试与邮件发送服务的集成、与支付服务的集成等等。这些可能包括：
测试是否可以从外部运输服务中检索运输费率
测试发票是否可以生成并正确发送
测试订单信息是否可以持久化并从数据存储中正确检索
测试交易是否可以发送并被支付处理程序正确处理
这些功能中的每一个都可能需要一个或两个集成测试来验证。这些测试运行起来会比较慢，可能涉及一些安装和拆卸步骤。结果是，每个测试的代码覆盖率会相当大。这些测试将通过捕获单元测试不能捕获的问题来产生价值。然而，维护成本和执行时间可能会比较高。
集成测试 vs 单元测试
是时候正面比较了
那么，应该首选哪种类型的测试呢？单靠两者中的任一个都是不够的。这两者都是综合测试计划的一部分。让我们直接比较一下：
基于理想化测试的工作软件
每种情况都是独特的，基于在其它情况下有效的建议不应盲目遵循。
现在我们明白了，单元测试不应该触及文件系统，而集成测试应该只集成松散的组件。但实际上，将测试划分为两个明确的类别有点太简单了，如果我们只关注定义，我们就会忽略目标，即正确的工作软件。
一些非常有想法的开发者认为单元测试可以并且应该读写数据库。其它人则认为单元测试是一种浪费，粗粒度的集成测试提供的价值最大。
问题是，每种情况都是独特的，基于在其它情况下有效的建议不应盲目遵循。需要牢记的一个问题是，这个测试要捕获什么类型的缺陷。如果每个测试都是经过深思熟虑编写来提升软件可靠性的，如果测试在不再有价值时被删除，那么随着时间的推移，将发现为特定项目提供最大价值的特定测试方法。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
