集成测试最佳实践 [英] Integration Testing best practices

问题描述

我们的团队进行了数百次集成测试，这些测试可以命中数据库并验证结果.我为所有集成测试提供了两个基类，一个针对仅检索测试，而一个针对创建/更新/删除测试.仅检索基类在TestFixtureSetup期间重新生成数据库，因此每个测试类仅执行一次. CUD基类在每次测试之前都会重新生成数据库.每个存储库类都有自己的对应测试类.

Our team has hundreds of integration tests that hit a database and verify results. I've got two base classes for all the integration tests, one for retrieve-only tests and one for create/update/delete tests. The retrieve-only base class regenerates the database during the TestFixtureSetup so it only executes once per test class. The CUD base class regenerates the database before each test. Each repository class has its own corresponding test class.

您可以想象，整个过程需要花费一些时间(大约需要7-8分钟才能运行并快速增长).将其作为CI(CruiseControl.Net)的一部分运行不是问题，但是在本地运行会花费很长时间，并且实际上在提交代码之前禁止运行它们.

As you can imagine, this whole thing takes quite some time (approaching 7-8 minutes to run and growing quickly). Having this run as part of our CI (CruiseControl.Net) is not a problem, but running locally takes a long time and really prohibits running them before committing code.

我的问题是，有什么最佳实践可以帮助加快这些类型的集成测试的执行速度?

My question is are there any best practices to help speed up the execution of these types of integration tests?

由于我们使用了sqlite不支持的某些特定于数据库的功能(计算列等)，因此我无法在内存中执行它们(按sqlite进行).

I'm unable to execute them in-memory (a la sqlite) because we use some database specific functionality (computed columns, etc.) that aren't supported in sqlite.

另外，整个团队也必须能够执行它们，因此，在SQL Server Express的本地实例上运行它们，否则可能容易出错，除非这些实例的连接字符串都相同.

Also, the whole team has to be able to execute them, so running them on a local instance of SQL Server Express or something could be error prone unless the connection strings are all the same for those instances.

您如何在商店中做到这一点，什么效果很好?

How are you accomplishing this in your shop and what works well?

谢谢！

推荐答案

将快速(单元)测试和慢速(集成)测试分开保存，以便可以分别运行它们.使用测试框架提供的任何方法对测试进行分组/分类.如果测试框架不支持对测试进行分组，则将集成测试移至仅包含集成测试的单独模块中.

Keep your fast (unit) and slow (integration) tests separate, so that you can run them separately. Use whatever method for grouping/categorizing the tests is provided by your testing framework. If the testing framework does not support grouping the tests, move the integration tests into a separate module that has only integration tests.

快速测试应该只需要几秒钟就可以运行所有测试，并且应该具有较高的代码覆盖率.这些测试使开发人员可以进行无情的重构，因为他们可以进行少量更改并运行所有测试，并对更改不会破坏任何东西非常有信心.

The fast tests should take only some seconds to run all of them and should have high code coverage. These kind of tests allow the developers to refactor ruthlessly, because they can do a small change and run all the tests and be very confident that the change did not break anything.

慢速测试可能需要花费几分钟才能运行，并且它们将确保各个组件正常工作.当开发人员进行的更改可能破坏集成测试而非单元测试所测试的某些内容时，他们应在提交之前运行那些集成测试.否则，慢速测试将由CI服务器运行.

The slow tests can take many minutes to run and they will make sure that the individual components work together right. When the developers do changes that might possibly break something which is tested by the integration tests but not the unit tests, they should run those integration tests before committing. Otherwise, the slow tests are run by the CI server.

这篇关于集成测试最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！