在 CI/CD流水线中运行自动化单元测试的4个原因

目录

什么是单元测试？

C#中的单元测试示例

我需要在CI/CD 流水线中运行自动化测试吗？

开发人员代码验证反馈循环

预验证

步步为营

减少“另一个开发人员写了这段代码”的问题

---

什么是单元测试？

单元测试
什么是单元测试？
单元测试是一小段代码，用于测试应用程序编写的代码的逻辑。单元测试允许对代码进行快速内存测试，关闭开发人员代码验证反馈循环。

C#中的单元测试示例

下面是为用 C# 编写的简单计算器库编写的一些单元测试的简单示例。如果你从未编写过 C#，请不要害怕这个代码示例。同样的原则适用于几乎任何其他编程语言！计算器类是将要测试的类，这称为被测单元或被测类。

1. namespace WebDevTutor
2. {
3. public static class Calculator
4. {
5. public static int Add(int addend1, int addend2)
6. {
7. return addend1 + addend2;
8. }
10. public static int Subtract(int minuend, int subtrahend)
11. {
12. return minuend - subtrahend;
13. }
14. }
15. }

以下是上面列出的计算器类的单元测试。

1. using Xunit;
3. namespace WebDevTutor.Tests
4. {
5. public class CalculatorTests
6. {
7. [Fact]
8. public void Add_ShouldReturn4When2And2AreAdded()
9. {
10. // Arrange
11. int expectedSum = 4;
13. // Act
14. var sum = Calculator.Add(2, 2);
16. // Assert
17. Assert.Equal(expectedSum, sum);
18. }
20. [Fact]
21. public void Subtract_ShouldReturn90When10IsSubtractedFrom100()
22. {
23. // Arrange
24. int expectedDifference = 90;
26. // Act
27. var difference = Calculator.Subtract(100, 10);
29. // Assert
30. Assert.Equal(expectedDifference, difference);
31. }
32. }
33. }

这两个测试针对 Calculator 类的 Add 和 Subtract 方法运行基本测试用例。这两个单元测试在内存中运行都在5 毫秒内！
这是一个简单的例子，但我希望它展示了编写单元测试的基本模式。

我需要在CI/CD 流水线中运行自动化测试吗？

是的——你需要在 CI/CD 流水线中运行自动化单元测试。
在这篇文章中，我们将讨论您需要在 CI/CD 流水线中运行自动化单元测试的 4 个原因。

1. 开发人员代码验证反馈循环
2. 预验证
3. 步步为营
4. 减少“另一个开发人员写了这段代码”的问题

开发人员代码验证反馈循环

通过单元测试提高开发速度
判断当前代码是否修复错误的最快方法是什么？
  也许你启动了 UI 并创建了一系列点击事件来模拟用户流。或者，启动 Postman 并开始用请求访问你的 API。这些测试习惯在需要时非常有用，但是如果只是对代码中的一个小单元进行更改怎么办？如果正在修复应用程序底层的一个简单错误，可能根本不需要运行 UI。甚至可能不需要在本地为API 启动调试会话。我们可以通过添加平均每条不到 10 毫秒的命令行运行单元测试来缩短开发人员代码验证反馈循环。在编写验证修复错误的单元测试后，可以轻松（并重复）验证更改是否符合预期结果。不需要用UI按钮单击流，这些流对于测试小更改来说是过大的，可通过编写单元测试并通过命令行在本地运行它们来获得亚秒级的自动反馈。

预验证

用单元测试保护自己
  现在是下午 4 点，刚从老板那里收到一个高优先级的错误。 但是你在下午 5 点有家庭聚餐。你快速编写错误修复并添加单元测试以验证代码更改，提交代码并在下午 4:45 创建拉取请求，正好赶上，可以在知道已成功修复错误后下班。提交更改，拉取请求部署到产品中，然后带着微笑与家人共进晚餐。第二天早上回来工作时，你会收到一堆电子邮件和 Slack 消息。修复的这个bug导致相当大的回归量。但是你对这个代码库了如指掌——这怎么可能发生？是因为修复的这个bug破坏了上周完成的另一个修复bug的代码！你深入研究代码，修复此问题很简单，只需要在一行代码中添加 null 或空检查。如何防止这种回归验证？答案在下一节“过度自信”中。

步步为营

通过单元测试添加回归测试
  修复bug导致了回归验证，但是怎么知道要回归验证呢？应该手动执行每个边界测试用例吗？不，这是不可能完成的任务。是否应该手动执行尽可能多的测试用例？当然可以，但这需要相当长的时间。 在 6 个月后，当这段代码又出现了一个另外的bug，你怎么记得再次运行相同的测试用例？简而言之，没有开发人员能够记住代码库中每个类或代码片段的测试用例。 尤其是超过 6 个月的时间！
开发人员以合理的速度对代码进行回归测试的唯一方法是使用自动化单元测试
  如果上周修复bug有单元测试来验证更改，那么这种回归验证很可能会被CI/CD 流水线捕获——单元测试会失败。在修复bug的代码分支中添加新的单元测试或修改以前的单元测试是一个表明该 bug 已被修复很好的标志，在单元测试运行时，再次复现了这个bug则会被CI/CD流水线捕获。

减少“另一个开发人员写了这段代码”的问题

用单元测试保护同事代码
“另一个开发人员写了这段代码”问题的概念：
  “另一位开发人员编写了此代码”问题是当前开发人员（你）无法完全理解另一位开发人员编写的代码中的需求、标志和模式。 这是 Web 开发的基础。 副作用是：开发速度慢，更改代码时回归的风险高，以及突然想问以前的开发人员为什么代码是这样写的。某些操作可以帮助减少此问题的影响，但此问题从未得到真正的解决。 注意：在 6 个月后，当你回过头来看自己刚刚编写的代码时，你也是“另外一个开发人员”！
你刚在一家新公司，一个全新的代码库中工作。 正在尝试拉一个分支修复一个简单bug。他们要求你在一段简单的代码中进行修复一个简单的bug。但实际上，对于新开发人员来说，这种代码更改并不简单。
你以前从未见过此代码！
  所有这些代码都是由另一位开发人员编写的。当一个项目有单元测试时，有标准化的文档和自动化测试，可以为新开发人员提供很棒的指导。查看新代码（另一位开发人员编写了此代码）时，如果你想弄懂一段代码定义过的（和测试过的）功能，单元测试是一个很好的着手点。当您成为新代码的编写者时，请牢记这一点，其他开发人员会将你的代码视为另一个开发人员编写了此代码。
为未来的新开发人员提供代码文档，为你的工程编写单元测试并在CI/CD 流水线中运行它们。

  作为一位过来人也是希望大家少走一些弯路

在这里我给大家分享一些自动化测试前进之路的必须品，希望能对你带来帮助。

（WEB自动化测试、app自动化测试、接口自动化测试、持续集成、自动化测试开发、大厂面试真题、简历模板等等）

相信能使你更好的进步！

点击下方小卡片