Best Practices
- Use one database instance per developer
- Good setup don't need cleanup!
- Use multiple small datasets
- Perform setup of stale data once for entire test class or test suite
- Connection management strategies
每个开发人员使用一个数据库
Testing can be simplified if you can get your database in a known state before a test is run. A database should only be used for one test at a time; otherwise the database state cannot be guarantied.
让你的数据库在测试运行之前处于一个已知状态可以简化测试.一个数据库在同一时间应该只用于一个测试,否则数据库状态无法保障.
So multiple developers working on the same project should have their own database instance to prevent data corruption. This also simplifies database cleanup, as you don't necessarily need needs to revert it to its initial state.
所以同一项目的多个开发人员应该有每人一个数据库,这样可以防止数据紊乱,这也可以简化数据清除,你不必在每次测试前将数据库回滚到其初始状态.
好的setup无需清除数据
You should always avoid creating tests that depends on results of preceding tests; thankfully this is the main purpose of DbUnit.
你应该始终避免产生依赖以前测试结果的测试,幸好这也是dbunit主要目标
Don't be afraid to leave your trace after a test; principally if you are using one database instance per developer. If you always put your database in a known state before a test execution, you usually don't need to clean it up.. This simplifies your tests maintenance and reduces the overhead taken by the cleanup procedure. And sometimes, this is very helpful to manually verify the database state after executing a test that fails.
原则上如果你使用"每个开发人员一个数据"的实践,不要害怕在测试之后留下你的数据.如果你在测试运行之前将数据库置于一个已知状态,那么你无需清除数据.这可以简化测试维护和减少清除操作带来的开销.有时候,如果测试失败,这有助于你手工检测数据库.
使用多个小数据集
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.
对集成测试来说,你仍然可以使用CompositeDataSet类在运行时候将多个小数据集绑定成一个大的
为整个测试类或数据集只setup不变数据一次
If several tests are using the same read-only data, this data could be initialized once for an entire test class or test suite. You need to be cautious and ensure you never modify this data. This can reduce the time required to run your tests but also introduces more risk.
如果多个测试使用相同的只读数据,那么整个测试类或测试集可以只初始化这些数据一次.你必须小心确保你从不会修改这些数据.这也能减少运行测试的时间,但也引入更多风险
连接管理策略
Here are the recommended connection management strategies depending whether you test from a remote client or an in-container strategy:
以下是推荐的连接管理策略,分为两类:远程测试和容器内测试
Remote client with DatabaseTestCase
使用DatabaseTestCase的远程客户
You should try to reuse the same connection for the entire test suite to reduce the overhead of creating a new connection for each test. Since version 1.1, DatabaseTestCase is closing every connection in setUp() and tearDown(). Override the closeConnection() method with an empty body to modify this behavior.
你应该尝试为整个测试集复用同一个连接,这样可以减少每次测试获取新连接的开销.从1,1版以来,DatabaseTestCase在setUp()和tearDown()中都会关闭连接.你可以覆盖closeConnection()方法,在方法体无需写任何代码,这样可以避免关闭连接.
In-container with Cactus or JUnitEE
容器内使用Cactus or JUnitEE做测试
If you use the in-container strategy you should use the DatabaseDataSourceConnection class to access the DataSource you configured for your application server. JDBC connections are requested on demand from the DataSource. So you can rely on the built-in connection pooling capability of your application server to achieve good performance.
IDatabaseConnection connection = new DatabaseDataSourceConnection(
new InitialContext(), "jdbc/myDataSource");
如果你使用容器内测试策略,那么你应该使用DatabaseDataSourceConnection类访问你在应用服务器
配置的数据源.你可以从数据源获取JDBC连接.所以你能依赖应用服务器内建的连接池获取更好的性能.代码如下:
IDatabaseConnection connection = new DatabaseDataSourceConnection(
new InitialContext(), "jdbc/myDataSource");
注:
以上是dbunit官方网站的最佳实践,英语水平有限,翻译的质量多包涵。
本人对于最佳实践的第一条和第二条不敢苟同,我会在我的blog阐述我的个人观点
并总结dbunit的实践经验
相关推荐
在本文中,我们将深入探讨 DBUnit 的最佳实践,聚焦于数据库的增删改查操作,帮助您优化测试流程,提升软件质量。 1. **数据初始化**: 在开始任何数据库操作之前,DBUnit 提供了 `IDatabaseConnection` 接口来...
这篇“DBUnit最佳实践之数据备份与恢复”博文中,作者分享了如何有效地利用DBUnit进行数据备份和恢复,这对于开发和测试环境中的数据管理至关重要。 首先,我们需要了解DBUnit的基本概念。DBUnit是一个JUnit扩展,...
DBUnit 是一个 Java 开发者常用的数据库测试工具,它与JUnit等测试框架配合,能够帮助开发者在测试...通过以上实践,我们可以高效地利用DBUnit与Ant集成,实现数据库的自动化测试和管理,提升项目的测试效率和质量。
通过阅读链接中的博文(https://virgoooos.iteye.com/blog/186859),可以获取更多关于如何在实际项目中使用DBUnit 的具体示例和最佳实践。 总之,DBUnit 是一个强大的工具,为Java开发者提供了一种有效的方法来...
在“DBUnit数据库测试资料.rar”中,可能包含的是DBUnit的使用指南、示例代码和最佳实践。而“dbunit_test”可能是实际的测试项目,包含配置文件、测试类和数据集文件,供学习者实践和理解DBUnit的工作原理。 总之...
- 常见问题解答和最佳实践 总之,“dbunit_jar_and_htmldoc”压缩包是DBUnit的开发和使用的重要资源,包含运行库和详细的使用指南,对于需要进行数据库测试的Java开发者来说是非常有价值的参考资料。通过学习和应用...
在编写DBUnit测试时,有几点最佳实践需要注意: - **数据准备**:创建清晰、独立的数据集,每个测试用例都应该有自己的数据环境。 - **断言**:使用适当的断言确保测试结果符合预期。 - **测试覆盖率**:尽可能覆盖...
**最佳实践** 1. **数据隔离**:为每个测试创建独立的数据集,防止测试之间相互干扰。 2. **合理使用数据类型**:XML数据集中正确表示特殊数据类型,如日期、时间戳等。 3. **维护数据集**:随着项目发展,定期更新...
**3.2.3 DBUnit的最佳实践是尽可能使用最小的数据集** 使用尽可能小的数据集可以加快测试速度,并减少测试期间的资源消耗。 **3.2.4 DatabaseOperation.CLEAN_INSERT 策略** 使用CLEAN_INSERT策略可以确保每个...
**Unitils 示例** Unitils 是一个强大的 Java 单元测试框架,它提供了丰富的功能来...通过深入理解并应用这些概念,我们可以利用 Unitils 示例工程中的最佳实践,提高测试的质量和效率,确保代码的健壮性和可维护性。
《Oracle数据库的DevOps实践》是由专家盖...盖国强的分享很可能详细探讨了这些方面,通过实际案例和最佳实践,帮助读者理解如何将DevOps理念成功应用于Oracle数据库环境,从而实现高效、安全且稳定的数据库开发和运维。
10. **最佳实践与规范**:SpringSide4项目不仅提供了技术实现,还强调了代码风格、命名规范、文档编写等最佳实践,让开发者能够按照工业标准进行开发。 通过对SpringSide4的深入学习和实践,Java开发者不仅可以掌握...
7. **最佳实践**: - 使用事务边界确保测试的隔离性,每个测试结束后回滚所有变更,保持数据库的原始状态。 - 尽量避免硬编码SQL,使用DAO接口和ORM工具进行操作,便于维护和扩展。 - 选择合适的数据集格式(如...
5. **最佳实践**: - 使用`@Transactional`注解确保每个测试都在独立的事务中运行,这样即使测试失败,也不会影响其他测试或实际数据。 - 数据集应尽可能小且具有代表性,以保持测试速度和可维护性。 - 测试应...
- **最佳实践**:结合了TDD(测试驱动开发)、BDD(行为驱动开发)、持续集成等最佳实践,帮助开发者更好地利用JUnit。 ### 5. 作者背景 - **Petar Tahchiev**:软件工程师,Jakarta Cactus项目的核心开发人员之一...