好得很程序员自学网

<tfoot draggable='sEl'></tfoot>

解剖SQLSERVER第六篇对OrcaMDF的系统测试里避免regressions(

解剖 SQLSERVER 第六篇 对OrcaMDF的 系统 测试 里 避免 regressions(译) http://improve.dk/avoiding-regressions-in-orcamdf-by-system-testing/ 当我继续添加新功能和新的数据结构支持进去OrcaMDF软件的时候,bug的风险不断增加 特别是当我开发一个很大

解剖 SQLSERVER 第六篇 对OrcaMDF的 系统 测试 里 避免 regressions (译)

http://improve.dk/avoiding-regressions-in-orcamdf-by-system-testing/

当我继续添加新功能和新的数据结构支持进去OrcaMDF软件的时候,bug的风险不断增加

特别是当我开发一个很大的未知功能时,我不能预估结构和该结构的关联,为了降低风险, 测试 是很有必要的

单元 测试

单元 测试 是在面向对象编程里 测试 源代码某一个功能的最小一部分的 测试 。一个 测试 的例子是SqlBigInt数据类型解析类,

他应该长这个样子

 using   System;
  using   NUnit.Framework;
  using   OrcaMDF.Core.Engine.SqlTypes;

  namespace   OrcaMDF.Core.Tests.Engine.SqlTypes
{
    [TestFixture]
      public   class   SqlBigIntTests
    {
        [Test]
          public   void   GetValue()
        {
              var  type =  new   SqlBigInt();
              byte  [] input;

            input  =  new   byte [] {  0xFF ,  0xFF ,  0xFF ,  0xFF ,  0xFF ,  0xFF ,  0xFF ,  0x7F   };
            Assert.AreEqual(  9223372036854775807  , Convert.ToInt64(type.GetValue(input)));

            input  =  new   byte [] {  0x82 ,  0x5A ,  0x03 ,  0x1B ,  0xD5 ,  0x3E ,  0xCD ,  0x71   };
            Assert.AreEqual(  8200279581513702018  , Convert.ToInt64(type.GetValue(input)));

            input  =  new   byte [] {  0x7F ,  0xA5 ,  0xFC ,  0xE4 ,  0x2A ,  0xC1 ,  0x32 ,  0x8E   };
            Assert.AreEqual( - 8200279581513702017  , Convert.ToInt64(type.GetValue(input)));
        }

        [Test]
          public   void   Length()
        {
              var  type =  new   SqlBigInt();

            Assert.Throws (() => type.GetValue( new   byte [ 9  ]));
            Assert.Throws (() => type.GetValue( new   byte [ 7  ]));
        }
    }
}  

这个 测试 包含了SqlBigInt 类的主入口点, 测试 long bigint 数据类型是否会造成上溢或下溢的情况,也包含长度检查。

对于像SqlBigInt这样简单的类型单元 测试 会工作得很好。有时候单元 测试 会很复杂当相关联的类需要调用相应方法,类等支持他运行的底层结构的时候(mock 测试 )

虽然这是一个工作策略, 测试 需要不断进行,特别在项目早期阶段,整个架构都是动态的

系统 测试

在 测试 范围上,我们需要更大的范围 测试 - 系统 测试 。 系统 测试 旨在 测试 系统 作为一个整体,基本上忽略 系统 内部工作原理

如果要分类的话可以被分为 黑盒 测试 。对于OrcaMDF,我估计可以捕获90%的所有的regressions 只使用10%的时间,

相比起单元 测试 使用更多时间只捕获少量的regressions 。

因此,这是一个很好的方法在开发期间的 测试 ,同时可以引入关键的单元 测试 和集成 测试 。

例如我想 测试 DatabaseMetaData 类里面的用户表名字的解析,我可以模拟SysObjects的值列表,同时对于DatabaseMetaData 类

的构造函数也能模拟MdfFile 所必须的参数,为了做到这一点,我必须从MdfFile 提取出一个接口并且在上面使用mocking framework

系统 测试 的方法执行以下流程:

1、连接到SQLSERVER实例

2、在 测试 固件(Test fixture)里创建 测试 架构

3、分离数据库

4、运行OrcaMDF 并加载分离的数据库验证结果

一个 测试 样例,创建两个用户表并且验证DatabaseMetaData类的 输出

 using   System.Data.SqlClient;
  using   NUnit.Framework;
  using   OrcaMDF.Core.Engine;

  namespace   OrcaMDF.Core.Tests.Integration
{
      public   class   ParseUserTableNames : SqlServerSystemTest
    {
        [Test]
          public   void   ParseTableNames()
        {
              using ( var  mdf =  new   MdfFile(MdfPath))
            {
                  var  metaData =  mdf.GetMetaData();

                Assert.AreEqual(  2  , metaData.UserTableNames.Length);
                Assert.AreEqual(  "  MyTable  " , metaData.UserTableNames[ 0  ]);
                Assert.AreEqual(  "  XYZ  " , metaData.UserTableNames[ 1  ]);
            }
        }

          protected   override   void   RunSetupQueries(SqlConnection conn)
        {
              var  cmd =  new  SqlCommand( @"  
                CREATE TABLE MyTable (ID int);
                CREATE TABLE XYZ (ID int);  "  , conn);
            cmd.ExecuteNonQuery();
        }
    }
}  

在实际的真实生活场景里这样可以非常快速的进行 测试 。想 测试 转发记录的解析?只需要简单地创建一个新的 测试
编写TSQL代码来生成目标数据库状态然后验证扫描到的表数据

系统 测试 的缺点

不幸的是 系统 测试 不是万能药,它也有它的缺点。最明显的一个缺点是性能。

单元 测试 通常需要运行非常快,基本上允许您在每个文件保存后在后台运行它们。从绑定CPU开始到运行 ,每一个这样的 系统 测试 都需要半秒

幸运的是,它们可以并行运行没有问题。在一台四核的机器能让我每分钟运行480个 测试 。这能够让一个完整的 测试 集合控制在合理的时间,

同时依然保持 测试 子集能够很快运行。通常代码的更改不会对 测试 造成太多的影响

第六篇完

查看更多关于解剖SQLSERVER第六篇对OrcaMDF的系统测试里避免regressions(的详细内容...

  阅读:38次