对编写的代码进行单元测试_在编写代码后编写单元测试，认为这对测试驱动的开发有害...

对编写的代码进行单元测试

DevOps是一门软件工程学科，致力于缩短交付周期，以实现所需的业务影响。 尽管业务利益相关者和发起人对如何优化业务运营有想法，但这些想法需要在现场进行验证。 这意味着业务自动化（即软件产品）必须放在最终用户和付费客户的面前。 只有这样，企业才能确认最初的改进想法是否卓有成效。

软件工程是一门新兴的学科，很难交付无缺陷的产品。 因此，DevOps致力于最大限度地提高自动化程度。 任何可重复的琐事，例如测试对源代码实施的更改，都应由DevOps工程师自动化。

本文研究如何自动执行单元测试。 这些测试专注于我所谓的“小型编程”。 更重要的测试自动化（所谓的“大型编程”）必须使用不同的学科-集成测试。 但这是另一篇文章的主题。

什么是单位？

当我教单元测试方法时，我的学生常常无法清楚地确定什么是可测试单元。 也就是说，处理的粒度并不总是清楚的。

我想指出，找出有效单位的最简单方法是将其视为行为单位 。 例如（尽管是微不足道的），当经过身份验证的客户开始在线购物时，行为单位是购物车中的商品为零。 一旦大家都同意一个空的购物车中有零个商品，我们就可以集中精力进行单元测试的自动化，以确保此类购物车始终返回零个商品。

什么不是单位？

任何涉及多个行为的处理都不应视为一个单元。 例如，如果购物车处理导致计算购物车中的物品数量并计算订单总额，计算营业税并计算建议的运输方式，则该行为不是单元测试的理想选择。 这种行为是集成测试的不错选择。

何时编写单元测试

关于何时编写单元测试的争论很多。 公认的观点认为，一旦编写了代码，编写自动脚本将是一个好主意，该脚本将断言行为的实现单元是否按预期提供了功能。 这样的单元测试（或几个单元测试）不仅记录了预期的行为，而且所有单元测试的集合确保了将来的更改不会降低质量。 如果将来的更改对已经实施的行为产生不利影响，则将投诉一个或多个单元测试，这将提醒开发人员发生了回归。

常识表明，先测量然后才进行切割是更合理的。 根据这一推理，建议在编写代码之前先进行单元测试，然后再进行适当的软件工程。 从技术上讲，这种“两次测量，一次剪切”的方法称为“测试优先”方法。 我们首先编写代码的相反方法称为“测试后”。 测试优先方法是测试驱动开发 （TDD）方法论所倡导的方法。 稍后编写测试称为后期测试开发（TLD）。

为什么TLD有害？

不建议在测量前进行切割。 即便是最有才华的工匠，最终也将不进行裁切而犯错。 随着我们不断努力，缺乏测量最终将赶上我们中最有经验的人。 因此，最好在切割前制作一个蓝图（即测量值）。

但这不是TLD方法被认为有害的唯一原因。 在编写代码时，我们同时考虑了两个独立的问题：代码的预期行为和代码的最佳结构。 这两个问题非常相似。 这个事实使得要进行适当的工作来满足有关预期行为和最佳（或至少是体面的）代码结构的期望非常具有挑战性。

TDD方法通过首先集中精力关注预期的预期行为来解决这一难题。 我们首先编写单元测试。 在该测试中，我们专注于我们预期的情况发生。 在这一点上，我们并不关心，在最少的，预期的行为将如何兑现。

一旦我们描述了什么 （即，我们将要构建的单元期望什么明显的行为？），我们就会看到期望失败了。 因为这涉及预期的行为是怎么样发生的代码有没有兑现但它失败。 现在，我们被迫编写将要处理how的代码 。

编写负责代码的代码后，我们将运行单元测试，并查看刚刚编写的代码是否符合预期的行为。 如果是这样，我们就完成了。 是时候继续实现下一个期望了。 如果没有，我们将继续转换代码，直到成功通过测试为止。

如果我们选择不TDD，但是写代码第一，后来写单元测试，我们错过了机会，从如何分开的 。 换句话说，我们在编写代码的同时要注意我们期望代码做什么以及如何正确构造代码。

因此，在编写代码之后编写单元测试被认为是有害的。

翻译自: https://opensource.com/article/20/2/automate-unit-tests

对编写的代码进行单元测试