当前位置：文江博客话题详情

许多小的 dbunit 数据集还是一个大的数据集？

发布于 2024-09-04 03:36:27 字数 85 浏览 9 评论 0原文

在我看来，每当调整架构时，将测试数据分布在多个小数据集中都会造成维护难题。有人发现创建一个更大的测试数据集有问题吗？我所说的“更大”仍然只是总共几百条记录。

原文

分享到QQ

分享到微博

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

发布评论

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

仄言 2024-09-11 03:36:27

我不会使用独特的大型数据集（如果不需要，您希望避免任何开销）并遵循 DbUnit 的最佳实践建议：

使用多个小型数据集
您的大多数测试不需要
整个数据库要重新初始化。
所以，不要把你的全部
一个大数据集中的数据库数据，
尝试把它分成许多更小的
块。
这些块大致可以
对应于逻辑单元，或
成分。这减少了开销
由初始化数据库引起的
对于每个测试。这也有利于
由于许多开发人员的团队发展
在不同的组件上工作可以
独立修改数据集。
对于集成测试，您仍然可以
使用 CompositeDataSet 类
逻辑地组合多个数据集
在运行时变成一个大的。

来自 Unitils 人员的更多反馈：

自动测试数据库维护
编写数据库测试时，请记住以下准则：
使用小组测试数据，包含尽可能少的数据。在数据文件中，仅指定在连接列或测试查询的 where 子句中使用的列。
使数据集测试类特定。不要在不同的测试类之间重复使用数据集，例如不要为所有测试类使用 1 个大域数据集。这样做将使您很难在不为另一次测试停止任何内容的情况下更改测试的测试数据。您正在编写一个单元测试，这样的测试应该独立于其他测试。
不要使用太多数据集。使用的数据集越多，需要的维护就越多。尝试为该测试类中的所有测试重用该测试类数据集。仅当方法数据集使您的测试更易于理解和清晰时才使用它。
限制预期结果数据集的使用。如果您确实使用它们，请仅包含对测试重要的表和列，而忽略其余部分。
为每个开发人员使用一个数据库架构。这使得开发人员可以插入测试数据并运行测试，而不会互相干扰。
禁用测试数据库上的所有外键和非空约束。这样，数据文件不需要包含超过绝对必要的数据

过去，使用具有足够数据的小型数据集对我们来说效果很好。当然，如果您调整数据库，则需要进行一些维护，但这对于某些组织来说是可以管理的。

I would not use a unique large dataset (you want to avoid any overhead if you don't need it) and follow DbUnit's Best Practices recommendations:

Use multiple small datasets
Most of your tests do not require the
entire database to be re-initialized.
So, instead of putting your entire
database data in one large dataset,
try to break it into many smaller
chunks.
These chunks could roughly
corresponding to logical units, or
components. This reduces the overhead
caused by initializing your database
for each test. This also facilitates
team development since many developers
working on different components can
modify datasets independently.
For integrated testing, you can still
use the CompositeDataSet class to
logically combine multiple datasets
into a large one at run time.

Some more feedback from the Unitils folks:

Automatic test database maintenance
When writing database tests, keep in mind following guidelines:
Use small sets of test data, containing as few data as possible. In your data files, only specify columns that are used in join columns or the where clause of the tested query.
Make data sets test class specific. Don't reuse data sets between different test classes, for example do not use 1 big domain data set for all your test classes. Doing so will make it very difficult to make changes to your test data for a test without braking anything for another test. You are writing a unit test and such a test should be independent of other tests.
Don't use too many data sets. The more data sets you use, the more maintenance is needed. Try to reuse the testclass data set for all tests in that testclass. Only use method data sets if it makes your tests more understandable and clear.
Limit the use of expected result data sets. If you do use them, only include the tables and columns that are important for the test and leave out the rest.
Use a database schema per developer. This allows developers to insert test data and run tests without interfering with each other.
Disable all foreign key and not null constraints on the test databases. This way, the data files need to contain no more data than absolutely necessary

Using small datasets with just enough data has worked decently for us in the past. Sure, there is some maintenance if you tweak the database but this is manageable with some organization.

回复收藏 0 原文

~没有更多了~