当我继续添加新功能和新的数据结构支持进去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<ArgumentException>(() => type.GetValue(new byte[9])); Assert.Throws<ArgumentException>(() => 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个测试。这能够让一个完整的测试集合控制在合理的时间，
同时依然保持测试子集能够很快运行。通常代码的更改不会对测试造成太多的影响