集成测试最佳实践

将快速(单元)和慢速(集成)测试分开,以便可以单独运行它们。使用测试框架提供的任何方法对测试进行分组/分类。如果测试框架不支持将测试分组,请将集成测试移动到只有集成测试的单独模块中。

快速测试应该只需要几秒钟就可以运行所有这些测试,并且应该具有很高的代码覆盖率。这些测试允许开发人员进行无情的重构,因为他们可以做一个小的改变,运行所有的测试,并且很有信心,这个改变并没有破坏任何东西。

缓慢的测试可能需要很多分钟才能运行,它们将确保各个组件正确地工作在一起。当开发人员做的更改可能会破坏由集成测试而不是单元测试测试的内容时,他们应该在提交之前运行这些集成测试。否则,慢测试将由ci服务器运行。

在NUnit中,可以用属性(例如:

[Category("Integration")]
public class SomeTestFixture{
    ...
}
[Category("Unit")]
public class SomeOtherTestFixture{
    ...
}

然后,可以在服务器上的构建过程中规定所有类别都会运行,并且只要求开发人员运行可用测试类别的子集。它们需要运行哪些类别取决于您比我更了解的内容。但要点是,它们能够在单元级进行测试,服务器处理集成测试。

我是Java开发人员,但也处理过类似的问题。我发现运行本地数据库实例工作得很好,这是因为速度快(没有数据要通过网络发送),而且这样您就不会对集成测试数据库产生争用。

解决此问题的一般方法是设置生成脚本以从配置文件中读取数据库连接字符串,然后为每个环境设置一个文件。例如,一个文件用于工作站,另一个用于CI。然后设置生成脚本以读取基于指定环境的配置文件。因此,在开发人员工作站上运行的生成使用工作站配置运行,在CI环境中运行的生成使用CI设置。

如果整个数据库模式可以从一个脚本创建,那么它也非常有用,因此每个开发人员都可以快速建立一个本地数据库进行测试。您甚至可以将此概念扩展到下一级,并将数据库安装脚本添加到生成过程中,从而可以对整个数据库设置进行脚本编写,以跟上数据库模式的变化。

我们有一个sql server express实例,作为开发环境的一部分,每个开发计算机都运行相同的db定义。使用Windows身份验证,连接字符串是稳定的-字符串中没有用户名/密码。

我们真正想做的,但还没有,看看我们是否能让我们的系统运行。 SQL Server Compact Edition ,它类似于sqlite和sql server的引擎。然后我们可以在内存中运行它们,也可以并行运行(使用多个进程)。

你是否做过任何测量(使用计时器或类似工具)来确定测试的大部分时间花在哪里?

如果您已经知道数据库重建是它们耗时的原因,那么另一种方法是重新生成一次数据库,并使用事务在测试之间保持状态。每个cud类型测试在setup中启动一个事务并在teardown中执行回滚。由于事务回滚比完整数据库娱乐更便宜,因此可以显著减少每次测试的数据库设置所花费的时间。