CI/CD流水线中执行自动化单位测试
一、什么是单位测试？单位测试什么是单位测试？单位测试是一小段代码，用于测试应用步伐编写的代码的逻辑。单位测试允许对代码举行快速内存测试，闭环开发职员代码验证反馈循环。
二、C#中的单位测试示例
[*]
namespace WebDevTutor
{
public static class Calculator
{
public static int Add(int addend1, int addend2)
{
return addend1 + addend2;
}
public static int Subtract(int minuend, int subtrahend)
{
return minuend - subtrahend;
}
}
}
下面是为用 C# 编写的简朴计算器库编写的一些单位测试的简朴示例。假如你从未编写过 C#，请不要害怕这个代码示例。同样的原则实用于险些任何其他编程语言！计算器类是将要测试的类，这称为被测单位或被测类。
using Xunit;
namespace WebDevTutor.Tests
{
public class CalculatorTests
{
public void Add_ShouldReturn4When2And2AreAdded()
{
// Arrange
int expectedSum = 4;
// Act
var sum = Calculator.Add(2, 2);
// Assert
Assert.Equal(expectedSum, sum);
}
public void Subtract_ShouldReturn90When10IsSubtractedFrom100()
{
// Arrange
int expectedDifference = 90;
// Act
var difference = Calculator.Subtract(100, 10);
// Assert
Assert.Equal(expectedDifference, difference);
}
}
}
这两个测试针对 Calculator 类的 Add 和 Subtract 方法运行根本测试用例。这两个单位测试在内存中运行都在5 毫秒内！这是一个简朴的例子，但我希望它展示了编写单位测试的根本模式。
三、我需要在CI/CD 流水线中运行自动化测试吗？
是的——你需要在 CI/CD 流水线中运行自动化单位测试。在这篇文章中，我们将讨论您需要在 CI/CD 流水线中运行自动化单位测试的 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 流水线中运行它们。PS：假如6个月后返来看你刚写的代码的“另一个开发职员”是你，你会思量的！ 这个也是给本身的一个保护。
最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们假如需要可以自行免费领取【包管100%免费】
https://img-blog.csdnimg.cn/img_convert/4bef2bcc832534845b0294e084093b1c.png
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也伴随上万个测试工程师们走过最艰难的旅程，希望也能帮助到你！
https://img-blog.csdnimg.cn/5e30e29caf934e78878a37830760ae75.gif
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]