集成测试最佳实践

时间:2009-08-25 14:38:49

标签: integration-testing

我们的团队有数百个集成测试,可以访问数据库并验证结果。我有两个基类用于所有集成测试,一个用于仅检索测试,一个用于创建/更新/删除测试。仅检索基类在TestFixtureSetup期间重新生成数据库,因此每个测试类只执行一次。 CUD基类在每次测试之前重新生成数据库。每个存储库类都有自己相应的测试类。

你可以想象,整个过程需要相当长的时间(接近7-8分钟才能运行并快速增长)。将此运行作为我们的CI(CruiseControl.Net)的一部分运行不是问题,但在本地运行需要很长时间,并且在提交代码之前确实禁止运行它们。

我的问题是,是否有任何最佳实践可以帮助加快执行这些类型的集成测试?

我无法在内存中执行它们(la sqlite),因为我们使用sqlite不支持的某些特定于数据库的功能(计算列等)。

此外,整个团队必须能够执行它们,因此在SQL Server Express的本地实例上运行它们可能容易出错,除非这些实例的连接字符串完全相同。

你是如何在你的店铺中完成这项工作的,哪些方面有效?

谢谢!

5 个答案:

答案 0 :(得分:14)

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

快速测试应该只需要几秒钟来运行所有这些测试并且应该具有高代码覆盖率。这些测试允许开发人员无情地重构,因为他们可以进行一些小的更改并运行所有测试,并且非常确信更改不会破坏任何内容。

慢速测试可能需要很长时间才能运行,他们将确保各个组件正确地协同工作。当开发人员进行的更改可能会破坏集成测试而不是单元测试所测试的内容时,他们应该在提交之前运行这些集成测试。否则,慢速测试由CI服务器运行。

答案 1 :(得分:11)

在NUnit中,您可以使用以下属性来装饰您的测试类(或方法):

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

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

答案 2 :(得分:5)

我是一名java开发人员,但处理过类似的问题。我发现运行本地数据库实例的速度很快(没有数据通过网络发送),并且因为这样你就不会在集成测试数据库上发生争用。

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

如果可以从单个脚本创建整个数据库模式,那么它也会有很大帮助,因此每个开发人员都可以快速设置本地数据库进行测试。您甚至可以将此概念扩展到下一个级别,并将数据库设置脚本添加到构建过程,因此可以编写整个数据库设置脚本以跟上数据库架构中的更改。

答案 3 :(得分:3)

您是否已完成任何测量(使用计时器或类似工具)来确定测试在大部分时间内的用途?

如果您已经知道数据库重新创建是他们耗费时间的原因,那么不同的方法是重新生成数据库一次并使用事务来保持测试之间的状态。每个CUD类型测试都会在设置中启动事务并在拆卸时执行回滚。这可以显着减少每次测试数据库设置所花费的时间,因为事务回滚比完整数据库重新创建便宜。

答案 4 :(得分:3)

我们有一个SQL Server Express实例,它为每个开发机器运行相同的数据库定义,作为开发环境的一部分。使用Windows身份验证,连接字符串是稳定的 - 字符串中没有用户名/密码。

我们真正想做的,但还没有,看看我们是否可以让我们的系统在SQL Server Compact Edition上运行,就像SQLite的SQL Server引擎一样。然后我们可以在内存中运行它们,也可以并行运行它们(使用多个进程)。