关于tdd：数据库集成测试

Database integration tests

在仅使用数据访问层或大多数应用程序堆栈进行集成测试时。如果在同一数据库上运行多个测试，最好的方法是防止它们相互冲突？

交易。

Ruby on Rails单元测试框架的作用是这样的：

1
2
3
4
5
6
7
8
9
10
11

Load all fixture data.

For each test:

BEGIN TRANSACTION

# Yield control to user code

ROLLBACK TRANSACTION

End for each

这意味着

测试对数据库所做的任何更改都不会影响正在进行的其他线程

下一个测试的数据不会被先前的测试污染

这比手动为每个测试重新加载数据快约十亿倍。

我认为这很酷

对于简单的数据库应用程序，我发现使用SQLite很有用。它使您可以为每个测试拥有唯一的独立数据库。

但是，仅当您使用简单的通用SQL功能或可以轻松地将SQLite和生产数据库系统之间的细微差别隐藏在类后面时，它才起作用，但是我一直发现，在SQL应用程序中这相当容易我已经开发了。

只需添加到Free Wildebeest的答案中，我还使用HSQLDB进行了类似的类型测试，其中每个测试都获得一个干净的DB实例。

尽管在其他答案之一中不如Rails单元测试框架那么聪明，但为每个测试或一组测试创建不同的数据是另一种方法。此解决方案的乏味程度取决于您拥有的测试用例的数量以及它们之间的依赖性。如果每个测试或一组相关测试有一个数据库，那么繁琐的工作将适用。

运行测试套件时，首先要加载数据，运行测试套件，然后卸载/比较结果，以确保实际结果符合预期结果。如果不是，请再次执行该循环。加载，运行套件，卸载/比较。

还要在不同的时间运行测试，以使它们不会影响彼此的性能或有效性。

我想同时接受Free Wildebeest和Orion Edwards的回答，但我不接受。我之所以想这样做，是因为我得出的结论是，这是完成此操作的两种主要方法，但是选择哪种方法取决于具体情况(主要是数据库的大小)。