DevOps 是一种软件工程学科，专注于最大限度地缩短实现预期业务影响的交付周期。虽然业务利益相关者和赞助商对如何优化业务运营有想法，但这些想法需要在实践中得到验证。这意味着业务自动化（即软件产品）必须展示在最终用户和付费客户面前。只有这样，企业才能确认最初的改进想法是否富有成效。
软件工程是一门新兴的学科，交付没有缺陷的产品可能会很困难。因此，DevOps 诉诸于最大程度的自动化。任何可重复的琐事，例如测试对源代码的已实现更改，都应由 DevOps 工程师自动化。
本文着眼于如何自动化单元测试。这些测试侧重于我喜欢称之为“小型编程”的内容。更重要的测试自动化（所谓的“大型编程”）必须使用不同的学科——集成测试。但那是另一篇文章的主题。
什么是单元？
当我教授单元测试方法时，我的学生经常无法清楚地确定什么是可测试的单元。也就是说，处理的粒度并不总是清晰的。
我想指出，发现有效单元的最简单方法是将其视为行为单元。例如（尽管是一个微不足道的例子），当经过身份验证的客户开始在线购物时，行为单元是一个购物车，其中包含零个商品。一旦我们都同意空购物车包含零个商品，我们就可以专注于自动化单元测试，以确保这样的购物车始终返回零个商品。
什么不是单元？
任何涉及多个行为的处理都不应被视为单元。例如，如果购物车处理导致统计购物车中商品的数量，并且计算订单总额，并且计算销售税，并且计算建议的运送方式，则该行为不是单元测试的好候选对象。这种行为是集成测试的良好候选对象。
何时编写单元测试
关于何时编写单元测试有很多争论。普遍的看法是，一旦代码编写完成，最好编写自动化脚本，以断言已实现的行为单元是否按预期交付功能。这样的单元测试（或几个单元测试）不仅记录了预期的行为，而且所有单元测试的集合确保了未来的更改不会降低质量。如果未来的更改对已实现的行为产生不利影响，则一个或多个单元测试将发出警告，这将提醒开发人员发生了回归。
还有另一种看待软件工程的方式。它基于传统的格言“三思而后行”。从这个角度来看，在编写测试之前编写代码相当于切割某个产品的一部分（例如，椅子腿），并且仅在切割后才测量它。如果进行切割的工匠非常熟练，则这种方法可能有效（有点）。但更有可能的是，以这种方式切割的椅子腿最终会长度不相等。因此，建议在切割之前进行测量。这对软件工程实践的意义在于，测量值在单元测试中表达。一旦我们测量了所需的值，我们就创建一个蓝图（单元测试）。然后，该蓝图用于指导代码的切割。
常识会表明，先测量，然后再切割是更合理的。根据这种推理，在编写代码之前编写单元测试是进行适当软件工程的推荐方法。从技术上讲，这种“三思而后行”的方法称为“测试先行”方法。相反的方法，我们先编写代码，称为“测试滞后”。测试先行方法是 测试驱动开发 (TDD) 方法论所倡导的方法。稍后编写测试称为测试滞后开发 (TLD)。
为什么 TLD 是有害的？
不建议在测量之前切割。即使是最有才华的工匠，最终也会因为不进行测量而犯错。当我们继续我们的工艺时，缺乏测量最终会赶上我们中最有经验的人。因此，最好在切割之前制作蓝图（即测量值）。
但这并不是认为 TLD 方法有害的唯一原因。当我们编写代码时，我们同时考虑两个独立的关注点：代码的预期行为和代码的最佳结构。这两个关注点非常不同。这一事实使得做好满足对期望行为和最佳（或至少是体面）代码结构的期望的工作非常具有挑战性。
TDD 方法通过首先将全部注意力集中在预期的期望行为上，解决了这个难题。我们从编写单元测试开始。在该测试中，我们专注于我们期望发生什么。此时，我们一点也不关心预期的行为将如何实现。
一旦我们完成了描述什么（即，我们期望从我们即将构建的单元中表现出什么行为？），我们就会看到该期望失败。它失败了，因为负责如何实现预期行为的代码尚未实现。现在，我们不得不编写代码来处理如何。
在我们编写了负责如何的代码之后，我们运行单元测试，看看我们刚刚编写的代码是否实现了预期的行为。如果实现了，我们就完成了。是时候继续满足下一个期望了。如果没有实现，我们将继续转换代码，直到它成功通过测试。
如果我们选择不进行 TDD，而是先编写代码，然后再编写单元测试，我们就会错过将什么与如何分离的机会。换句话说，我们在编写代码时，同时处理我们期望代码做什么以及如何构建代码以正确地执行它。
因此，在编写代码之后编写单元测试被认为是有害的。
5 条评论