数据库集成测试

发布于 2024-07-05 06:52:13 字数 71 浏览 11 评论 0原文

当您仅使用数据访问层或大部分应用程序堆栈进行集成测试时。 如果在同一个数据库上运行多个测试,防止它们相互冲突的最佳方法是什么?

When you are doing integration tests with either just your data access layer or the majority of the application stack. What is the best way prevent multiple tests from clashing with each other if they are run on the same database?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

最终幸福 2024-07-12 06:52:13

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

Also run the tests at different times, so that they do not impact the performance or validity of each other.

別甾虛僞 2024-07-12 06:52:13

虽然不像此处其他答案中的 Rails 单元测试框架那么聪明,但为每个测试或测试组创建不同的数据是另一种方法。 此解决方案的乏味程度取决于您拥有的测试用例的数量以及它们彼此之间的依赖程度。 如果每个测试或一组相关测试都有一个数据库,那么乏味的情况就会发生。

运行测试套件时,您在开始时加载数据,运行测试套件,卸载/比较结果,确保实际结果符合预期结果。 如果没有,请再次循环。 加载、运行套件、卸载/比较。

While not as clever as the Rails unit test framework in one of the other answers here, creating distinct data per test or group of tests is another way of doing it. The level of tediousness with this solution depends on the number of test cases you have and how dependant they are on one another. The tediousness will hold true if you have one database per test or group of dependant tests.

When running the test suite, you load the data at the start, run the test suite, unload/compare results making sure the actual result meets the expected result. If not, do the cycle again. Load, run suite, unload/compare.

负佳期 2024-07-12 06:52:13

对于简单的数据库应用程序,我发现使用 SQLite 非常有价值。 它允许您为每个测试拥有一个独特且独立的数据库。

然而,只有当您使用简单的通用 SQL 功能或者可以轻松隐藏 SQLite 和类后面的生产数据库系统之间的细微差异时,它才有效,但我总是发现这在我的 SQL 应用程序中相当容易发达。

For simple database applications I find using SQLite invaluable. It allows you to have a unique and standalone database for each test.

However it does only work if you're using simple generic SQL functionality or can easily hide the slight differences between SQLite and your production database system behind a class, but I've always found that to be fairly easy in the SQL applications I've developed.

呆头 2024-07-12 06:52:13

只是为了添加到 Free Wildebeest 的答案中,我还使用 HSQLDB 进行类似的类型测试,其中每个测试都会获得一个干净的实例数据库的。

Just to add to Free Wildebeest's answer I have also used HSQLDB to do a similar type testing where each test gets a clean instance of the DB.

俏︾媚 2024-07-12 06:52:13

我想接受自由牛羚和猎户座爱德华兹的答案,但它不允许我。 我想这样做的原因是我得出的结论是,这是两种主要的方法,但选择哪一种取决于具体情况(主要是数据库的大小)。

I wanted to accept both Free Wildebeest's and Orion Edwards' answers but it would not let me. The reason I wanted to do this is that I'd come to the conclusion that these were the two main ways to do it, but which one to chose depends on the individual case (mostly the size of the database).

青瓷清茶倾城歌 2024-07-12 06:52:13

交易。

ruby on Rails 单元测试框架的作用是这样的:

Load all fixture data.

For each test:

  BEGIN TRANSACTION

    # Yield control to user code

  ROLLBACK TRANSACTION

End for each

这意味着

  1. 您的测试对数据库所做的任何更改都不会影响正在进行的其他线程 下
  2. 一个测试的数据不会被之前的测试污染
  3. 这大约是无数个比每次测试手动重新加载数据快了数倍。

我认为这很酷

Transactions.

What the ruby on rails unit test framework does is this:

Load all fixture data.

For each test:

  BEGIN TRANSACTION

    # Yield control to user code

  ROLLBACK TRANSACTION

End for each

This means that

  1. Any changes your test makes to the database won't affect other threads while it's in-progress
  2. The next test's data isn't polluted by prior tests
  3. This is about a zillion times faster than manually reloading data for each test.

I for one think this is pretty cool

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文