在“在无责 DevOps 中，失败是一种特性”中，我讨论了通过征求反馈意见来交付质量的过程中失败所起到的核心作用。 这是敏捷 DevOps 团队依赖的失败，以指导他们并推动开发。 测试驱动开发 (TDD) 是任何敏捷 DevOps 价值流交付的必要条件。 如果以失败为中心的 TDD 方法与可衡量的测试相结合，才能有效。
TDD 方法是以自然的工作方式为模型，以及自然如何在进化游戏中产生赢家和输家。
自然选择
1859 年，查尔斯·达尔文在他的著作物种起源中提出了进化论。 达尔文的论点是，自然变异是由个体生物的自发突变和环境压力共同造成的。 这些压力淘汰了适应能力较差的生物，同时有利于其他更适合的生物。 每个生物都会突变其染色体，并且这些自发突变会被带到下一代（后代）。 然后，新出现的变异在自然选择（由于环境条件的可变性而存在的环境压力）下进行测试。
此简化图说明了适应环境条件的过程。
图 1. 不同的环境压力导致由自然选择决定的不同结果。 图片是Richard Dawkins 视频的屏幕截图。
此图显示了鱼群在其自然栖息地中。 栖息地各不相同（海床或河床底部较深或较浅的砾石），每条鱼也各不相同（较深或较浅的身体图案和颜色）。
它还显示了两种情况（即，环境压力的两种变化）
- 掠食者存在
- 掠食者不存在
在第一种情况下，在砾石阴影下更容易被发现的鱼类有被掠食者挑走的更高风险。 当砾石较暗时，较浅部分的鱼类数量会减少。 反之亦然 - 当砾石的颜色较浅时，较深部分的鱼类数量会减少。
在第二种情况下，鱼类足够放松以进行交配。 在没有掠食者且存在交配仪式的情况下，可以预期会产生相反的结果：在背景中脱颖而出的鱼类更有可能被选中进行交配并将它们的特征传递给后代。
选择标准
在变异中进行选择时，该过程绝不是任意的、反复无常的、异想天开的，也不是随机的。 决定性因素始终是可以衡量的。 决定性因素通常称为测试或目标。
一个简单的数学例子可以说明这个决策过程。 （只是在这种情况下，它不受自然选择的支配，而是受人工选择的支配。）假设有人要求你构建一个小函数，该函数将接收一个正数并计算该数的平方根。 你会怎么做？
敏捷 DevOps 的方式是快速失败。 从谦卑开始，首先承认你并不真正知道如何开发该函数。 此时，你所知道的只是如何描述你想做什么。 用技术术语来说，你已准备好参与制作单元测试。
“单元测试”描述了你的具体期望。 它可以简单地表述为“给定数字 16，我希望平方根函数返回数字 4。” 你可能知道 16 的平方根是 4。但是，你不知道一些较大数字（例如 533）的平方根。
至少，你已经制定了你的选择标准、测试或目标。
实现失败的测试
.NET Core 平台可以说明实现过程。 .NET 通常使用 xUnit.net 作为单元测试框架。 （要按照编码示例进行操作，请安装 .NET Core 和 xUnit.net。）
打开命令行并创建一个文件夹，在其中实现平方根解决方案。 例如，键入
mkdir square_root然后键入
cd square_root为单元测试创建一个单独的文件夹
mkdir unit_tests移动到 unit_tests 文件夹 (cd unit_tests) 并启动 xUnit 框架
dotnet new xunit现在，向上移动一个文件夹到 square_root 文件夹，然后创建 app 文件夹
mkdir app
cd app创建 C# 代码所需的支架
dotnet new classlib现在打开你喜欢的编辑器并开始破解！
在你的代码编辑器中，导航到 unit_tests 文件夹并打开 UnitTest1.cs。
用以下内容替换 UnitTest1.cs 中的自动生成代码
using System;
using Xunit;
using app;
namespace unit_tests{
public class UnitTest1{
Calculator calculator = new Calculator();
[Fact]
public void GivenPositiveNumberCalculateSquareRoot(){
var expected = 4;
var actual = calculator.CalculateSquareRoot(16);
Assert.Equal(expected, actual);
}
}
}此单元测试描述了变量 expected 应为 4 的期望。下一行描述了 actual 值。 它建议通过向名为 calculator 的组件发送消息来计算 actual 值。 此组件被描述为能够通过接受一个数值来处理 CalculateSquareRoot 消息。 该组件尚未开发。 但这并不重要，因为这仅仅描述了期望。
最后，它描述了触发发送消息时会发生什么。 在那时，它会断言 expected 值是否等于 actual 值。 如果是，则测试通过并且达到目标。 如果 expected 值不等于 actual value，则测试失败。
接下来，要实现名为 calculator 的组件，请在 app 文件夹中创建一个新文件并将其命名为 Calculator.cs。 要实现计算数字平方根的函数，请将以下代码添加到此新文件中
namespace app {
public class Calculator {
public double CalculateSquareRoot(double number) {
double bestGuess = number;
return bestGuess;
}
}
}在你可以测试此实现之前，你需要指示单元测试如何查找此新组件 (Calculator)。 导航到 unit_tests 文件夹并打开 unit_tests.csproj 文件。 在 <ItemGroup> 代码块中添加以下行
<ProjectReference Include="../app/app.csproj" />保存 unit_test.csproj 文件。 现在你已准备好进行你的第一次测试运行。
转到命令行并 cd 进入 unit_tests 文件夹。 运行以下命令
dotnet test运行单元测试将产生以下输出
图 2. 单元测试运行失败后 xUnit 输出。
正如你所看到的，单元测试失败了。 它期望将数字 16 发送到 calculator 组件会导致数字 4 作为输出，但输出（actual 值）是数字 16。
恭喜！ 你已经创建了你的第一次失败。 你的单元测试提供了强烈、直接的反馈，敦促你修复失败。
修复失败
要修复失败，你必须改进 bestGuess。 现在，bestGuess 仅仅接收函数接收的数字并返回它。 不够好。
但是你如何找到计算平方根值的方法？ 我有一个想法 - 不如看看大自然母亲是如何解决问题的。
通过迭代来模拟大自然母亲
很难（几乎不可能）从第一次（也是唯一一次）尝试中猜出正确的值。 你必须允许多次尝试猜测，以增加解决问题的机会。 允许进行多次尝试的一种方法是迭代。
要迭代，请将 bestGuess 值存储在 previousGuess 变量中，转换 bestGuess 值，并比较两个值之间的差异。 如果差异为 0，则你解决了该问题。 否则，请继续迭代。
这是生成任何正数的平方根的正确值的函数的主体
double bestGuess = number;
double previousGuess;
do {
previousGuess = bestGuess;
bestGuess = (previousGuess + (number/previousGuess))/2;
} while((bestGuess - previousGuess) != 0);
return bestGuess;此循环（迭代）将 bestGuess 值收敛到所需的解决方案。 现在，你精心制作的单元测试通过了！
图 3. 单元测试成功，0 个测试失败。
迭代解决了问题
就像大自然母亲的方法一样，在本练习中，迭代解决了问题。 增量方法与逐步细化相结合是获得令人满意的解决方案的保证方式。 在这场游戏中，决定性因素是拥有可衡量的目标和测试。 一旦你拥有了它，你就可以不断迭代，直到你达到目标为止。
现在是妙语！
好的，这是一个有趣的实验，但是更有趣的发现来自于使用这个新铸造的解决方案。 到目前为止，你的起始 bestGuess 始终等于函数作为输入参数接收的数字。 如果你更改初始 bestGuess 会发生什么？
为了测试这一点，您可以运行几个场景。首先，观察逐步求精的过程，迭代循环会通过一系列猜测来尝试计算 25 的平方根
图 4. 迭代计算 25 的平方根。
从 25 作为 bestGuess 开始，该函数需要八次迭代才能计算出 25 的平方根。但是，如果您对 bestGuess 进行了滑稽、荒谬的错误尝试，会发生什么？ 如果您以一个毫无头绪的猜测开始，例如 100 万可能是 25 的平方根，会怎样？ 在这种明显错误的情况下会发生什么？ 您的函数能够处理这种愚蠢行为吗？
看看源头。 重新运行该场景，这次从 100 万作为 bestGuess 开始
图 5. 通过从 1,000,000 作为初始 bestGuess 开始计算 25 的平方根时的逐步求精。
哇！ 从一个荒谬的大数字开始，迭代次数仅增加了两倍（从八次迭代到 23 次）。 几乎不像您直觉上预期的那样大幅增加。
这个故事的寓意
当您意识到，迭代不仅保证可以解决问题，而且无论您对解决方案的搜索是从一个好的初始猜测开始，还是从一个糟糕透顶的初始猜测开始，都没有关系，顿悟时刻就到来了。 无论您最初的理解多么错误，迭代的过程，加上可衡量的测试/目标，都会让您走上正确的轨道并交付解决方案。 保证。
图 4 和图 5 显示了一个陡峭而急剧的下降。 从一个完全不正确的起点开始，迭代会迅速下降到绝对正确的解决方案。
简而言之，这种惊人的方法是敏捷 DevOps 的本质。
回到一些高层次的观察
敏捷 DevOps 实践源于对这样一个现实的认识：我们生活在一个从根本上建立在不确定性、模糊性、不完整性和一定程度的混乱之上的世界中。 从科学/哲学的角度来看，这些特性已被充分记录并得到 海森堡不确定性原理（涵盖不确定性部分）、维特根斯坦的《逻辑哲学论》（模糊性部分）、哥德尔不完备性定理（不完整性方面）和 热力学第二定律（由无情的熵引起的混乱）的支持。
简而言之，无论您多么努力，在尝试解决任何问题时，您都永远无法获得完整的信息。 因此，放弃傲慢的姿态，采取更谦逊的方法来解决问题会更有利。 谦逊会带来丰厚的回报，不仅会奖励您期望的解决方案，还会奖励您结构良好的解决方案的副产品。
结论
自然界不知疲倦地工作——这是一个持续的流动。 自然界没有总体规划； 一切都发生作为对先前发生事情的回应。 反馈循环非常紧密，并且明显的进步/倒退是零星的。 在大自然中，你随处可见一种或另一种形式的逐步求精。
敏捷 DevOps 是工程模型逐渐成熟的一个非常有趣的结果。 DevOps 基于这样一种认识：您拥有的信息始终是不完整的，因此最好谨慎行事。 获得可衡量的测试（例如，一个假设，一个可衡量的期望），尝试谦虚地满足它，很可能会失败，然后收集反馈，修复失败并继续。 除了同意每一步都必须有一个可衡量的假设/测试之外，没有其他计划。
在本系列的下一篇文章中，我将仔细研究突变测试如何提供驱动价值的急需反馈。
9 条评论