系列目录

在开始之前我们先看一个陷阱

用到的Person类如下

  1. public class Person:IPerson
  2. {
  3. public string Name { get; set; }
  4. public int Age { get; set; }
  5. public DateTime BirthDay { get; set; }
  6. /// <summary>
  7. /// 判断Name是否包含字母B
  8. /// </summary>
  9. /// <returns></returns>
  10. public bool WhetherNameContainsB()
  11. {
  12. if (this.Name == null) throw new ArgumentNullException("参数不能为null");
  13. if (this.Name.Contains("B")) return true;
  14. return false;
  15. }
  16. }

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

测试类如下

  1. [TestFixture]
  2. public class FirstUnitTest
  3. {
  4. private Person psn;
  5. public FirstUnitTest()
  6. {
  7. psn = new Person();
  8. }
  9. [Test]
  10. [Order(1)]
  11. public void SetPersonName()
  12. {
  13. psn.Name = "sto";
  14. Assert.IsNotEmpty(psn.Name);
  15. }
  16. [Test]
  17. [Order(2)]
  18. public void DemoTest()
  19. {
  20. Assert.Throws<ArgumentNullException>(() => psn.WhetherNameContainsB());
  21. }
  22. }

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

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

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

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

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

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

改造后的测试类如下

  1. [TestFixture]
  2. public class FirstUnitTest
  3. {
  4. public FirstUnitTest()
  5. {
  6. }
  7. [Test]
  8. [Order(1)]
  9. public void SetPersonName()
  10. {
  11. Person psn = new Person();
  12. psn.Name = "sto";
  13. Assert.IsNotEmpty(psn.Name);
  14. }
  15. [Test]
  16. [Order(2)]
  17. public void DemoTest()
  18. {
  19. Person psn = new Person();
  20. Assert.Throws<ArgumentNullException>(() => psn.WhetherNameContainsB());
  21. }
  22. }

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

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

Setup注释

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

  1. [TestFixture]
  2. public class FirstUnitTest
  3. {
  4. private Person psn;
  5. public FirstUnitTest()
  6. {
  7. }
  8. [SetUp]
  9. public void Setup()
  10. {
  11. psn = new Person();
  12. }
  13. [Test]
  14. [Order(1)]
  15. public void SetPersonName()
  16. {
  17. psn.Name = "sto";
  18. Assert.IsNotEmpty(psn.Name);
  19. }
  20. [Test]
  21. [Order(2)]
  22. public void DemoTest()
  23. {
  24. Assert.Throws<ArgumentNullException>(() => psn.WhetherNameContainsB());
  25. }
  26. }

我们在标识为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就会在程序集加载的时候扫描到这个类,然后对它处理.

    我们看一下示例代码

    1. [SetUpFixture]
    2. public class AssemblySetup
    3. {
    4. [OneTimeSetUp]
    5. public void RunBeforeEveryMethod()
    6. {
    7. ConfigurationManager.AppSettings["user"] = "sto";
    8. ConfigurationManager.AppSettings["age"] = "32";
    9. }
    10. }

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

我们看运行结果



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

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

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

要实现自定义运行方法,我们要继承TestactionAttribute

示例代码如下

  1. public class MyTestAction:TestActionAttribute
  2. {
  3. public override void BeforeTest(ITest test)
  4. {
  5. Console.WriteLine("★★★★★★★★★★" + test.FullName);
  6. }
  7. }

我们用Console.WriteLine模拟.

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

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

自定义运行方法非常强大,还可以提供参数,这样会在大幅度减少相似代码的重复,提高可维护性,大家要以后的测试中慢慢体会.

.net持续集成测试篇之Nunit 测试配置的更多相关文章

  1. .net持续集成测试篇之Nunit常见断言

    系列目录 Nunit测试基础之简单断言 在开始本篇之前需要补充一些内容,通过前面搭建Nunit测试环境我们知道要使一个方法成为单元测试方法首先要在此方法所在类加上TestFixture注解,并且在该方 ...

  2. .netcore持续集成测试篇之MVC测试

    前面我们讲的很多单元测试的的方法和技巧不论是在.net core和.net framework里面都是通用的,但是mvc项目里有一种比较特殊的类是Controller,首先Controller类的返回 ...

  3. .net持续集成测试篇之Nunit参数化测试

    系列目录 在进行单元测试的时候,很多时候,很多时候我们都是在单元测试方法内部提供特定的值,但是这样测试往往造成样本数不足从而导致覆盖的结果不够全面,很多时候我们更想提供来自外部的,满足条件的一组值来进 ...

  4. .net持续集成测试篇之Nunit文件断言、字符串断言及集合断言

    使用前面讲过的方法基本上能够完成工作中的大部分任务了,然而有些功能实现起来还是比较麻烦的,比如说字符串相等性比较不区分大小写,字符串是否匹配某一正则规则,集合中的每一个(某一个)元素是否符合特定规则等 ...

  5. .net持续集成测试篇之Nunit that断言

    系列目录 that是Nunit的新语法,语义上不如简单断言,使用上也更加复杂,但是其功能更加强大. 其基本语法如下代码片段示: [Test] public void DemoTest() { bool ...

  6. .netcore持续集成测试篇之Xunit数据驱动测试一

    系列目录 Nunit里提供了丰富的数据测试功能,虽然Xunit里提供的比较少,但是也能满足很多场景下使用了,如果数据场景非常复杂,Nunit和Xunit都是无法胜任的,有不少测试者选择自己编写一个数据 ...

  7. .netcore持续集成测试篇之开篇简介及Xunit基本使用

    系列目录 为了支持跨平台,微软为.net平台提供了.net core test sdk,这样第三方测试框架诸如Nunit,Xunit等只需要按照sdk提供的api规范进行开发便可以被dotnet cl ...

  8. .netcore持续集成测试篇之搭建内存服务器进行集成测试一

    系列目录 在web项目里,我们把每一层的代码的单元测试都通过并不代表程序能正常运行,因为这个过程缺失了http管道,很多时候我们还还需要把项目布在iis环境中或者在vs里启动iis express服务 ...

  9. .netcore持续集成测试篇之测试方法改造

    系列目录 通过前面两节讲解,我们的测试类中已经有两个测试方法了,总体上如下 public class mvc20 { private readonly HttpClient _client; publ ...

随机推荐

  1. django的阶段总结

    Django回顾 1 web应用 本质是基于socket实现的应用程序 浏览器-----------服务器 2 http协议:应用层协议 1 基于TCP协议 2 基于请求响应 3 短连接 4 无状态保 ...

  2. 【深入浅出-JVM】(34):CMS 回收器

    概念 Concurrent Mark Sweep 并发标记清除(多线程并且用的标记清除算法),会造成大量的内存碎片,离散的可用空间无法分配较大的对象 流程 参数 -XX:-CMSPrecleaning ...

  3. 嵊州D3T3 light

    嵊州D3T3 light 光恰似水 兄弟俩曾经 k 次受到过父母的物质激励. 一开始,兄弟俩的能力值为 1,最后,兄弟俩的能力值是 1 + (2 ^k−1)/ n . 当兄弟俩受到价值为 mi 的物质 ...

  4. .Net Core 创建和使用中间件

    1. 定义中间内容 1.1 必须有一个RequestDelegate 委托用了进入一个中间件 1.2 通过构造函数设置这个RequestDelegate委托 1.3 必须有一个方法Task Invok ...

  5. 20140115-SqlHelper为什么是静态的

    为什么SqlHelper(或工具类)是静态的? 静态构造函数仅调用一次(即只是在程序生命周期中实例一次),在程序驻留的应用程序域的生存期内,静态类一直保留在内存中 这样可以减少每次使用的实例过程,就是 ...

  6. Python 爬虫:煎蛋网妹子图

    使用 Headless Chrome 替代了 PhatomJS. 图片保存到指定文件夹中. import requests from bs4 import BeautifulSoup from sel ...

  7. DML语言DDL

    DML(data manipulation language): 它们是SELECT.UPDATE.INSERT.DELETE,就象它的名字一样,这4条命令是用来对数据库里的数据进行操作的语言 . D ...

  8. java中this 和 super关键字的作用

    emmmmmm也真的是好久没有写过java了,因为项目需要, 最近又必须重新拾起来了,虽然好多东西也都忘得差不多了.... 然后发现 竟然把super和this傻傻分不清.... 开个帖子记录一下: ...

  9. Netty-解码器架构与常用解码器

    任何数据类型想在网络中进行传输,都得经过编解码转换成字节流 在netty中,服务端和客户端进行通信的其实是下面这样的 程序 ---编码--> 网络 网路 ---解码--> 程序 对应服务端 ...

  10. 简单题[期望DP]

    也许更好的阅读体验 \(\mathcal{Description}\) 桌面上有R张红牌和B张黑牌,随机打乱顺序后放在桌面上,开始一张一张地翻牌,翻到红牌得到1美元,黑牌则付出1美元.可以随时停止翻牌 ...