.net持续集成测试篇之Nunit 测试配置

简介: .net持续集成测试篇之Nunit 测试配置在开始之前我们先看一个陷阱用到的Person类如下public class Person:IPerson{ public string Name { get; set; } public int Age { get; set; }...

.net持续集成测试篇之Nunit 测试配置
在开始之前我们先看一个陷阱

用到的Person类如下

public class Person:IPerson

{
    public string Name { get; set; }
    public int Age { get; set; }
    public DateTime BirthDay { get; set; }
    /// <summary>
    /// 判断Name是否包含字母B
    /// </summary>
    /// <returns></returns>
    public bool WhetherNameContainsB()
    {
        if (this.Name == null) throw new ArgumentNullException("参数不能为null");
        if (this.Name.Contains("B")) return true;
        return false;
    }
}

这个类以前也用过,有三个属性和一个方法,其中方法用于判断Name字段是否包含大写字母B,如果包含返回true,不包含返回false,如果Name为null则抛出异常

测试类如下

[TestFixture]

public class FirstUnitTest
{
    private Person psn;
    public FirstUnitTest()
    {
     psn = new Person();
     }

    [Test]
    [Order(1)]
    public void SetPersonName()
    {
        psn.Name = "sto";
        Assert.IsNotEmpty(psn.Name);
    }
    [Test]
    [Order(2)]
    public void DemoTest()
    {
        Assert.Throws<ArgumentNullException>(() => psn.WhetherNameContainsB());
    }
   

}

第一个测试给Name赋值,然后断言用户名不为空,这显然应该是通过的

第二个测试用于断言调用WhetherNameContainsB时会抛异常,由于这里Name并没有赋值,所以会抛出异常,这里也应该能返回成功.

然而运行以上代码第二个测试返回的是失败!这是因为Nunit在运行测试类的时候会调用所有的测试方法,由于我们显式指定的运行顺序(使用order注解)则第一个方法先于第二个方法前执行,由于第一个方法把Name设置为"sto",因此这时候全局psn的Name字段便有值了.所以第二个方法再调用psn的WhetherNameContainsB方法时,是不会抛出异常的(方法的逻辑是只有Name有值便不会抛出异常).

如果不指定运行顺序,则第二个方法运行的结果是不确定的,如果它先于第一个方法执行,则就会返回成功,如果晚于第一个方法则返回失败.

我们前面说到,单元测试的结果应该是稳定的,然而这里却是不确定的,因此我们要重新设计.

当然其实解决这个问题很简单,只要把对全局的变量移动到方法里面就行了,这样每个方法的状态就不会被外部改变了.

改造后的测试类如下

[TestFixture]

public class FirstUnitTest
{
   
    public FirstUnitTest()
    {
    
     }

    [Test]
    [Order(1)]
    public void SetPersonName()
    {
        Person psn = new Person();
        psn.Name = "sto";
        Assert.IsNotEmpty(psn.Name);
    }
    [Test]
    [Order(2)]
    public void DemoTest()
    {
        Person psn = new Person();
        Assert.Throws<ArgumentNullException>(() => psn.WhetherNameContainsB());
    }
   

}

我们再运行,便都能通过了.

然而这样设计有一个问题,第一如果多个测试方法都要用到这个对象,则需要复制很多,第二如果多个方法之间共用的代码非常多,那么每个方法里都要复制很多代码,我们前面说过单元测试里的代码应力求简洁明了,并且复制同样的代码不利于维护.下面我们介绍Nunit里的Setup

Setup注释
在单元测试类中如果把一个方法加上setup注解,则这个方法会先于其它未标的方法执行,并且每个方法执行之前都会执行它,如果在setup注解的方法内初始化对象,则每个方法运行之前都会运行这个被注解的方法,则每次变量都重新初始化,不会再有数据被共享造成的各种问题了.我们用setup改造后的测试类如下

[TestFixture]
public class FirstUnitTest
{
    private Person psn;
    public FirstUnitTest()
    {
    
     }

    [SetUp]
    public void Setup()
    {
        psn = new Person();
    }
    [Test]
    [Order(1)]
    public void SetPersonName()
    {
      
        psn.Name = "sto";
        Assert.IsNotEmpty(psn.Name);
    }
    
    [Test]
    [Order(2)]
    public void DemoTest()
    {
       
        Assert.Throws<ArgumentNullException>(() => psn.WhetherNameContainsB());
    }
   

}

我们在标识为Setup的方法里初始化Person,这样测试就能通过了

被Setup注解的方法名可任意取,只要符合命名规范即可

Nunit并不限制一个测试类中有多个Setup方法,但是强烈不建议这么做.

OneTimeSetup注释
OneTimeSetup也是在所有的测试方法运行之前运行,不同的是它并不像SetUp一样每个测试方法运行之前都会运行,而是在所有测试方法运行之前之运行一次.它适用这样场景:比如说我们程序里的数据访问封闭类,这个类里面一般都是访问数据库的各种方法和一些私有的变量像连接字符串之类的,数据访问方法里只会去读取这些字段而不去修改它.最为重要的是每个测试方法运行之前都去实体化一个这样的类会很耗费资源.像这种类型便可以放在OneTimeSetup方法里,在类创建的时候运行一次.

这个方法功能很像构造函数,它能做的工作一般构造函数也能做.

Teardown
Teardown和Setup用法一样,只是它是在测试方法运行之后才运行,如果我们的测试方法里有需要释放的对象可以在这个方法里释放.

OneTimeTearDown
它是在所有的方法都运行完之后才运行一次,功能上相当于析构函数,用于在测试类所有方法都执行完以后释放掉类中使用的资源.

前面部分我们讲了如何在所在单元测试运行之前以及在每一个单元测试之前如何运行一个特定的方法.下面讲解如何在程序集运行之前和运行之后运行某一指定方法.

可能会有人怀疑这样做的意义,的确,大部分时候我们可能不需要在程序集运行之前或者之后运行某一方法,但是特定的情况下这样做确实会给测试带来很大帮助.比如以下场景

我们想要统计一下所有测试方法的运行时间,这时候我们可以在程序集之前启动StopWatch并在所有方法运行完之后获得运行时间,并写入日志.当然这样做可能显得有点傻.
在Web项目中可能会大量使用ConfigurationManager.AppSetting[xxx]来获取web项目配置,这样做给测试带来难题

由于单元测试的运行环境很多时候并非在程序的输出目录,因此web项目使用到AppSetting配置的方法在web环境运行正常,但是在单元测试环境得到的值都是Null,这将会导致测试时大量业务覆盖不到.

在测试的时候我们很难通过传参来改变这个值,因为在程序中往往都是获取AppSetting里的值,而不是设置,因此它往往不包含在方法的参数里.也就没法通过传参来修改它.

我们如果在Setup里给AppSetting赋值,比如ConfigurationManager.AppSettings["user"] = "sto";这样在运行的时候我们便可以获取到这个值了,但是AppSetting是全局的,可能程序中很多方法都用到了它,我们在每个测试方法里都写个Setup方法给它复制显然非常boring.

这时候我们可以在程序集运行之前运行一个方法,在这个方法里给AppSetting赋值,这样测试方法运行的时候使用到AppSetting的地方就可以获取到值了.

要做到这一点,我们需要新建一个类,并把类上加上SetUpFixture注解.然后方法上加上OneTimeSetUp和OneTimeTeardown注解.这样Nunit就会在程序集加载的时候扫描到这个类,然后对它处理.

我们看一下示例代码

[SetUpFixture]
public class AssemblySetup
{

  [OneTimeSetUp]
  public void RunBeforeEveryMethod()
  {
      ConfigurationManager.AppSettings["user"] = "sto";
      ConfigurationManager.AppSettings["age"] = "32";
  }

}
我们新建这个类以后RunBeforeEveryMethod便会在程序集中所有代码运行之前运行了

我们看运行结果
Avatar
我们可以看到,在测试类中随便找一个方法里面去获取值,都可以获取到了.

前面我们讲解了如何在方法运行前后,在测试类的所有方法运行前后以及如何在程序集,下面我们讲一下如何自定义一个方法在测试方法运行之前/之后运行.

自定义方法的优势在于如果每个测试类的setup里运行的代码基本相同,只是稍微有一点差异,这样就会导致代码重复的问题.比如我们要在方法运行之前和之后记录一些日志,这样我们就可以自定义一个方法实现在测试方法运行前后运行这个自定义方法,减少代码重复.

要实现自定义运行方法,我们要继承TestactionAttribute
示例代码如下

public class MyTestAction:TestActionAttribute

{
    public override void BeforeTest(ITest test)
    {
        Console.WriteLine("" + test.FullName);
    }
   
}

我们用Console.WriteLine模拟.

Itest对象由Nunit在运行时注入.

然后我们要在运行这个自定义方法的类上加上MyTestAction注解即可.

自定义运行方法非常强大,还可以提供参数,这样会在大幅度减少相似代码的重复,提高可维护性,大家要以后的测试中慢慢体会.
原文地址https://www.cnblogs.com/tylerzhou/p/11318911.html

相关文章
|
6天前
|
jenkins 测试技术 持续交付
软件测试中的自动化与持续集成:提升效率与质量的关键
在快节奏的软件开发环境中,自动化测试和持续集成已经成为不可或缺的部分。本文将探讨自动化测试和持续集成的重要性,以及它们如何协同工作以提高软件开发的效率和质量。通过分析自动化测试的策略、工具选择以及持续集成的实践,我们将揭示这些技术如何帮助开发团队快速响应变化,减少错误,并加速产品上市时间。
|
5天前
|
机器学习/深度学习 人工智能 jenkins
软件测试中的自动化与持续集成实践
在快速迭代的软件开发过程中,自动化测试和持续集成(CI)是确保代码质量和加速产品上市的关键。本文探讨了自动化测试的重要性、常见的自动化测试工具以及如何将自动化测试整合到持续集成流程中,以提高软件测试的效率和可靠性。通过案例分析,展示了自动化测试和持续集成在实际项目中的应用效果,并提供了实施建议。
|
25天前
|
测试技术 C# 数据库
C# 单元测试框架 NUnit 一分钟浅谈
【10月更文挑战第17天】单元测试是软件开发中重要的质量保证手段,NUnit 是一个广泛使用的 .NET 单元测试框架。本文从基础到进阶介绍了 NUnit 的使用方法,包括安装、基本用法、参数化测试、异步测试等,并探讨了常见问题和易错点,旨在帮助开发者有效利用单元测试提高代码质量和开发效率。
136 64
|
6天前
|
人工智能 API C#
使用Microsoft.Extensions.AI简化.NET中的AI集成
使用Microsoft.Extensions.AI简化.NET中的AI集成
使用Microsoft.Extensions.AI简化.NET中的AI集成
|
8天前
|
敏捷开发 Devops 测试技术
自动化测试中的持续集成与持续部署
在现代软件开发实践中,自动化测试是确保软件质量和快速迭代的关键。本文将探讨自动化测试如何与持续集成(CI)和持续部署(CD)流程相结合,以提高开发效率和软件质量。我们将分析CI/CD管道中自动化测试的最佳实践,以及如何克服实施过程中的挑战。
29 6
|
10天前
|
jenkins 测试技术 持续交付
探索软件测试中的自动化与持续集成
本文深入探讨了软件测试领域中自动化测试和持续集成的融合应用,分析了这种结合如何提升软件开发的效率和质量。通过具体案例分析,展示了自动化测试和持续集成在软件开发生命周期中的关键作用及其实施策略。
|
20天前
|
监控 jenkins 测试技术
探索软件测试的新篇章:自动化与持续集成
【10月更文挑战第25天】在数字化时代的浪潮中,软件已成为驱动世界的核心力量。然而,随着软件复杂性的增加,传统的测试方法已无法满足快速迭代和高质量交付的需求。本文将探讨如何通过自动化测试和持续集成(CI)来提升软件开发的效率和质量,同时确保产品的稳定性和可靠性。我们将从自动化测试的基础出发,逐步深入到持续集成的实践,并展示如何通过实际案例实现这一转变。
|
18天前
|
Web App开发 定位技术 iOS开发
Playwright 是一个强大的工具,用于在各种浏览器上测试应用,并模拟真实设备如手机和平板。通过配置 `playwright.devices`,可以轻松模拟不同设备的用户代理、屏幕尺寸、视口等特性。此外,Playwright 还支持模拟地理位置、区域设置、时区、权限(如通知)和配色方案,使测试更加全面和真实。例如,可以在配置文件中设置全局的区域设置和时区,然后在特定测试中进行覆盖。同时,还可以动态更改地理位置和媒体类型,以适应不同的测试需求。
Playwright 是一个强大的工具,用于在各种浏览器上测试应用,并模拟真实设备如手机和平板。通过配置 `playwright.devices`,可以轻松模拟不同设备的用户代理、屏幕尺寸、视口等特性。此外,Playwright 还支持模拟地理位置、区域设置、时区、权限(如通知)和配色方案,使测试更加全面和真实。例如,可以在配置文件中设置全局的区域设置和时区,然后在特定测试中进行覆盖。同时,还可以动态更改地理位置和媒体类型,以适应不同的测试需求。
17 1
|
20天前
|
jenkins 测试技术 持续交付
探索软件测试中的自动化与持续集成
【10月更文挑战第25天】在软件开发的海洋中,自动化测试和持续集成(CI)是引领航船穿越波涛的灯塔。本文将带你了解如何通过搭建自动化测试框架和实施持续集成策略来提高软件质量和开发效率。我们将以一个实际的代码示例为起点,逐步深入讲解如何整合自动化测试到你的CI/CD流程中。
|
20天前
|
jenkins 测试技术 持续交付
探索软件测试的新篇章:自动化与持续集成的融合
【10月更文挑战第25天】在软件开发的世界里,质量是王道。本文将带你领略如何通过自动化测试和持续集成(CI)的结合,提升软件交付的速度与质量,确保每一次代码提交都是一次胜利的宣言。