如何编写数据库调用的unit testing

我接近一个新项目的开始,并且第一次尝试将unit testing包括在我的一个项目中(gasp!)。

我在devise一些unit testing时遇到了麻烦。 我有几个方法已经很容易testing(传入两个值,并检查预期的输出)。 我有其他部分的代码正在做更复杂的事情,如针对数据库运行查询,我不知道如何testing它们。

public DataTable ExecuteQuery(SqlConnection ActiveConnection, string Query, SqlParameterCollection Parameters) { DataTable resultSet = new DataTable(); SqlCommand queryCommand = new SqlCommand(); try { queryCommand.Connection = ActiveConnection; queryCommand.CommandText = Query; if (Parameters != null) { foreach (SqlParameter param in Parameters) { queryCommand.Parameters.Add(param); } } SqlDataAdapter queryDA = new SqlDataAdapter(queryCommand); queryDA.Fill(resultSet); } catch (Exception ex) { //TODO: Improve error handling Console.WriteLine(ex.Message); } return resultSet; } 

这个方法基本上需要从数据库中提取一些数据,并将数据返回到DataTable对象中。

第一个问题可能是最复杂的:我应该在这样的情况下testing什么?

一旦解决了这个问题,是否需要模拟数据库组件或尝试对实际的数据库进行testing。

你在testing什么?

有三种可能性,我的头顶:

答:您正在testingDAO(数据访问对象)类,确保它正确地编组传递到数据库的值/参数,并正确封送/转换/打包从数据库获得的结果。

在这种情况下,根本不需要连接到数据库; 你只需要一个unit testing,用模拟replace数据库(或中间层,例如JDBC,(N)Hibernate,iBatis)。

B.您正在testing(生成的)SQL的语法正确性。

在这种情况下,由于SQL方言有所不同,因此您需要针对RDBMS的正确版本运行(可能生成的)SQL,而不是尝试模拟RDBMS的所有怪癖(以及任何更改function的RDBMS升级都会被你的testing)。

C.您正在testingSQL的语义正确性,即对于给定的基准数据集,您的操作(访问/select和突变/插入和更新)会生成预期的新数据集。

为此,您需要使用dbunit(它允许您设置基线并将结果集与预期的结果集进行比较),或者使用我在此概述的技术完全在数据库中进行testing: 最佳方式testingSQL查询 。

这就是为什么(恕我直言)unit testing有时会造成开发人员的虚假安全感。 根据我使用与数据库交互的应用程序的经验,错误通常是数据处于意外状态(exception或缺失值等)的结果。 如果您经常在unit testing中模拟数据访问,那么当您的代码实际上仍然容易受到这种错误的影响时,您会认为自己的代码运行良好。

我认为你最好的办法是有一个方便的testing数据库,充满了糟糕的数据,并运行你的数据库组件testing。 一直以来,记住你的用户将比你在搞数据上好得多。

unit testing的重点是单独testing一个单元 (duh)。 数据库调用的要点是与另一个单元(数据库) 集成 。 Ergo:unit testing数据库调用没有意义。

但是,应该集成testing数据库调用(如果需要,可以使用与unit testing相同的工具)。

为了爱上帝,不要试试一个已经存在的人口数据库。 但你知道这一点。

一般来说,您已经知道每个查询将要检索的数据types,无论您是对用户进行身份validation,查找电话簿/组织结构图条目或其他任何内容。 你知道你感兴趣的领域,你知道他们有什么约束(例如, UNIQUENOT NULL ,等等)。 你是unit testing你的代码与数据库交互,而不是数据库本身,所以思考如何testing这些function。 如果字段可能为NULL ,则应该进行testing,确保代码正确处理NULL值。 如果其中一个字段是string( CHARVARCHARTEXT ,&c),请确保正确处理转义字符。

假设用户将尝试将任何*放入数据库,并相应地生成testing用例。 你会想用这个模拟对象。

*包括不良的,恶意的或无效的input。

你可以unit testing一切,除了:queryDA.Fill(resultSet);

只要你执行queryDA.Fill(resultSet),你必须模拟/伪造数据库,或者你正在进行集成testing。

我认为集成testing不是坏事,只是它会遇到不同types的错误,有不同的假阴性和假阳性的可能性,不可能经常这样做,因为它太慢了。

如果我是unit testing这个代码,我会validation参数是否正确构build,命令生成器是否创build了正确数量的参数? 他们都有价值吗? 空值,空string和DbNull得到正确处理?

实际上,填充数据集是testing你的数据库,这是你的DAL范围之外的片状组件。

严格来说,从数据库或文件系统写入/读取的testing不是unit testing。 (虽然它可能是一个集成testing,它可能使用NUnit或JUnit编写)。 unit testing应该testing一个类的操作,隔离它的依赖关系。 所以,当你为接口和业务逻辑层编写unit testing时,根本不需要数据库。

好的,但是如何对数据库访问层进行unit testing呢? 我喜欢本书的build议: xUnit Test Patterns (链接指向本书的“Testing w / DB”一章),关键是:

  • 使用往返testing
  • 不要在数据访问testing夹具中编写太多的testing,因为它们的运行速度要远远低于“真正的”unit testing
  • 如果您可以避免使用真正的数据库进行testing,请在没有数据库的情况

对于unit testing,我通常会嘲笑或伪造数据库。 然后通过dependency injection来使用你的模拟或假实现来testing你的方法。 你也可能有一些集成testing,将testing数据库中的约束,外键关系等。

至于你要testing什么,你要确保该方法使用来自参数的连接,查询string被分配给该命令,并且返回的结果集与通过期望提供的结果集相同在填充方法。 注意 – testing一个返回值的Get方法比修改参数的Fill方法更容易。

为了做到这一点,虽然你应该使用一些dependency injection(DI),而对于.NET有几个。 我目前正在使用Unity框架,但还有其他的更容易。

这里是一个从这个网站上的这个主题的链接,但也有其他的: .NET中的dependency injection与例子?

这将使你更容易地模拟出你的应用程序的其他部分,只需要一个模拟类实现接口,所以你可以控制它将如何响应。 但是,这也意味着devise到一个接口。

既然你问到最好的做法,这将是一个国际海事组织。

然后,除非你需要,否则不要去分贝,因为build议是另一个。

如果你需要testing某些行为,比如与级联删除的外键关系,那么你可能希望为此编写数据库testing,但是通常不会去真正的数据库是最好的,尤其是因为不止一个人可能会运行一个unit testing一次,如果他们要去相同的数据库testing可能会失败,因为预期的数据可能会改变。

编辑:通过数据库unit testing我的意思是,因为它只是使用t-sql来做一些设置,testing和拆卸。 http://msdn.microsoft.com/en-us/library/aa833233%28VS.80%29.aspx

在基于JDBC的项目上,可以模拟JDBC连接,以便在没有实时RDBMS的情况下执行testing,每个testing用例都是独立的(没有数据冲突)。

它允许validation,持久性代码传递适当的查询/参数(例如https://github.com/playframework/playframework/blob/master/framework/src/anorm/src/test/scala/anorm/ParameterSpec.scala )并处理如预期的那样,JDBC结果(parsing/映射)(“需要从数据库中提取一些数据,并返回DataTable对象中的数据”)。

像jOOQ或Acolyte这样的框架可以用于: https : //github.com/cchantep/acolyte 。