.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

相关文章
|
2天前
|
机器学习/深度学习 敏捷开发 监控
深入探索软件测试中的持续集成与持续部署(CI/CD)实践
【5月更文挑战第10天】 在现代软件开发周期中,"持续集成"(CI)与"持续部署"(CD)是提升效率、确保质量的重要环节。本文将详细探讨CI/CD在软件测试中的应用,包括其基本概念、实施策略、工具应用及面临的挑战。不同于一般性概述,本文将重点分析如何优化测试流程以适应CI/CD环境,并提出针对性的改进措施。通过实际案例分析,揭示成功实施CI/CD的最佳实践,并讨论如何在不断变化的技术环境中保持测试策略的前瞻性和灵活性。
|
6天前
|
敏捷开发 监控 jenkins
探索自动化测试在持续集成环境中的关键作用
【5月更文挑战第6天】 在快速迭代的软件开发周期中,持续集成(CI)已经成为确保代码质量和加速交付的重要实践。本文将深入探讨自动化测试作为持续集成不可或缺的组成部分,它如何通过减少人为错误、提高测试覆盖率和加快反馈周期来强化软件开发流程。通过对现代自动化测试工具的评估以及真实案例的分析,我们揭示了自动化测试在提升软件可靠性和效率方面的核心价值,并提出了实现高效自动化测试策略的最佳实践。
|
6天前
|
敏捷开发 数据管理 测试技术
探索自动化测试在持续集成环境中的优化策略
【5月更文挑战第6天】 本文旨在深入剖析自动化测试在持续集成(CI)环境中所面临的挑战,并提出一系列创新的优化策略。通过对现代软件开发过程中自动化测试角色的分析,我们揭示了在快速迭代和部署的背景下,如何通过改进测试框架、选择合适的测试工具、以及实施数据驱动测试等手段来提高测试效率和准确性。文章不仅聚焦于技术层面的解决方案,还探讨了团队协作和流程管理对提升自动化测试效能的重要性。
|
6天前
|
开发框架 JSON .NET
.Net4.0 Web.config 配置实践
.Net4.0 Web.config 配置实践
|
9天前
|
设计模式 人工智能 测试技术
深入探究持续集成中的自动化测试策略
【5月更文挑战第3天】 在现代软件开发实践中,持续集成(CI)已成为提高开发效率、确保代码质量和加速产品上市速度的关键因素。自动化测试作为CI流程的核心组成部分,它确保了快速的反馈循环和高质量的构建。本文将探讨在持续集成环境中实施高效自动化测试的策略,包括测试用例的优化、测试环境的管理、以及如何整合最新的测试工具和技术。通过具体案例分析,我们将了解如何构建一个既灵活又健壮的自动化测试系统,以支持不断变化的软件开发需求。
|
9天前
|
敏捷开发 监控 测试技术
探索自动化测试在持续集成中的关键作用
【5月更文挑战第3天】 随着敏捷开发和持续集成(CI)实践的普及,自动化测试已成为确保软件质量和加速交付过程的核心环节。本文旨在深入探讨自动化测试在持续集成环境中的作用,重点分析其在提高测试效率、降低人力成本及维护软件质量保障体系中的重要性。通过实际案例研究,本文揭示了有效实施自动化测试策略的关键因素,并提出了一系列优化建议,以帮助软件开发团队充分利用自动化测试工具,实现持续交付的高效运作。
32 6
|
12天前
|
监控 JavaScript 前端开发
【TypeScript技术专栏】TypeScript的单元测试与集成测试
【4月更文挑战第30天】本文讨论了在TypeScript项目中实施单元测试和集成测试的重要性。单元测试专注于验证单个函数、类或模块的行为,而集成测试关注不同组件的协作。选用合适的测试框架(如Jest、Mocha),配置测试环境,编写测试用例,并利用模拟和存根进行隔离是关键。集成测试则涉及组件间的交互,需定义测试范围,设置测试数据并解决可能出现的集成问题。将这些测试整合到CI/CD流程中,能确保代码质量和快速响应变化。
|
12天前
|
分布式计算 DataWorks 关系型数据库
DataWorks操作报错合集之DataWorks集成实例绑定到同一个vpc下面,也添加了RDS的IP白名单报错:数据源配置有误,请检查,该怎么处理
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
27 0
|
13天前
|
DataWorks NoSQL 关系型数据库
DataWorks操作报错合集之在使用 DataWorks 进行 MongoDB 同步时遇到了连通性测试失败,实例配置和 MongoDB 白名单配置均正确,且同 VPC 下 MySQL 可以成功连接并同步,但 MongoDB 却无法完成同样的操作如何解决
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
30 1
|
13天前
|
敏捷开发 机器学习/深度学习 Java
Java中的异常处理机制深入理解与实践:持续集成在软件测试中的应用探索自动化测试在敏捷开发中的关键作用
【4月更文挑战第29天】在Java编程中,异常处理是一个重要的概念。它允许开发者在程序执行过程中遇到错误或异常情况时,能够捕获并处理这些异常,从而保证程序的稳定运行。本文将详细介绍Java中的异常处理机制,包括异常的分类、异常的处理方式以及自定义异常等内容。 【4月更文挑战第29天】 随着敏捷开发和DevOps文化的兴起,持续集成(CI)已成为现代软件开发周期中不可或缺的一环。本文将探讨持续集成在软件测试领域内的关键作用、实施策略以及面临的挑战。通过对自动化构建、测试用例管理、及时反馈等核心要素的详细分析,揭示持续集成如何提高软件质量和加速交付过程。 【4月更文挑战第29天】 在当今快速发

热门文章

最新文章