好代码是管出来的——.Net Core集成测试与数据驱动测试 (2)

  

好代码是管出来的——.Net Core集成测试与数据驱动测试

  首先为测试类添加构造方法,在构造方法中初始化数据库。

  

好代码是管出来的——.Net Core集成测试与数据驱动测试

  然后在测试方法中添加用户数量测试断言,当添加完成用户后,应该一共存在1个用户。
  执行测试方法:

  

好代码是管出来的——.Net Core集成测试与数据驱动测试

  无论执行多少次测试都是通过的,这意味着每次添加用户后用户数量均为1,这样就达到了测试的可回归性。
  但是真实的开发过程中,不可能只有一个测试类型,而且如果为每一个测试类型都添加初始化数据库的代码,那么这些单元测试将会执行的非常慢(数据库的初始化非常耗时),那么要如何解决这个问题?

使用Fixture共享测试上下文

  Fixture是xUnit.Net中的一项特性,它可以用来共享测试上下文,Fixture可以译为固定装置,换句话说就是把一个内容固定住,使该内容可以在被指定的范围内使用。xUnit.Net中Fixture有两种类型,分别是ClassFixture和CollectionFixture,它们对应的是在一个测试类型里面共享和一个测试类型集合中共享上下文,Fixture的作用有很多,下面将介绍如何使用Fixture来共享数据库被初始化这一状态(不需要重复初始化):
  1. 创建一个Fixture类型:
  Fixture实际上是一个普通的C#类型,唯一需要注意的是它使用构造方法初始化数据、使用Dispose来释放或者清理数据,简单的一个Fixture类型如下:

  

好代码是管出来的——.Net Core集成测试与数据驱动测试

  2. 为单个类型使用ClassFixture:

  

好代码是管出来的——.Net Core集成测试与数据驱动测试

  从代码中可以看到通过构造方法初始化的代码已经被注释了,实现IClassFixture接口后,再次执行测试方法,可以看到测试仍然是可回归的。
  3. 为多个类型使用ICollectionFixture:
  首先需要在DatabaseFixture的基础上添加一个实现ICollectionFixture的类型:

  

好代码是管出来的——.Net Core集成测试与数据驱动测试

  两个要点分别是需要使用CollectionDefinition特性,然后类型需要实现ICollectionFixture<T>接口。
  在测试类型上通过Collection特性,指定之前定义的Collection名称来应用该CollectionFixture:

  

好代码是管出来的——.Net Core集成测试与数据驱动测试

  然后多次执行测试方法,可以发现测试仍然是可回归的:

  

好代码是管出来的——.Net Core集成测试与数据驱动测试

  注:在共享测试上下数据时(包括共享数据库数据),可能会因为测试方法执行顺序导致测试失败,但是xUnit.Net中没有提供按顺序执行实现方式,默认是按照方法命名,如果需要按照一定顺序执行测试,可参考官方的例子:https://github.com/xunit/samples.xunit/tree/master/TestOrderExamples

测试数据的管理与初始化

  涉及到数据库的测试,很可能在测试之前数据库就会存在一些已有的测试数据,使用xUnit.Net来编写测试代码时,可以将测试数据的初始化放到Fixture类型中,但是要如何对这些数据进行管理呢?一般来说使用SQL脚本来管理数据库的测试数据是一种不错的方式,因为这样测试数据与代码解耦,维护数据时仅需要维护SQL脚本文件即可。
  下面就介绍一下如何在xUnit.Net中使用SQL脚本文件管理以及初始化数据:
  1.创建一个SQL脚本:

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wsxdxf.html