正如清单 3 所示，现在组件测试可在执行期间依赖驻留在数据库中的特定数据。另外，由于在所有测试成功执行后删除了所有的数据，因而此过程现在可重复执行。
在数据库中播种
可以将 dbunit 任务的 INSERT 和 DELETE 操作类型和一个种子文件起使用，该文件包含表示数据库表和相关行的 XML 元素。例如，清单 4 是清单 3 中引用的 seedFile.xml 文件的内容。每个 BEER 元素表示一个也叫 BEER 的数据库表，BEER 元素的每个属性和其值都映射至相应的数据库列名称和值。
清单 4. DbUnit 种子文件
<?xml version='1.0' encoding='UTF-8'?>
<dataset>
<BEER id='6'
beer_name='Guinness Extra Stout'
brewer='St.James Brewery'
date_received='2007-02-01' />
<BEER id='7'
beer_name='Smuttynose Robust Porter'
brewer='Smuttynose Brewery'
date_received='2007-02-01' />
<BEER id='8'
beer_name='Wolavers pale ale'
brewer='Wolaver Brewery'
date_received='2007-02-01' />
</dataset>
您也许已经从清单 3 中注意到，可以在不同的操作中重用 DbUnit 的种子文件。在本文的例子中，将在运行组件测试前使用清单 4 中的文件在数据库中播种，然后使用相同的文件指示测试完成时从数据库中删除哪些数据。
参与性能测试
开发人员完成编码后，常常要经过很长时间才执行性能测试，而事实通常是可以在开发周期中更早的时候发现（并且解决）性能问题。幸运地是，有一种方法可解决此问题：持续测试或更具体地、持续地运行 JUnitPerf 测试。
对性能测试来说 JUnitPerf 是完美的
JUnitPerf 是一个同 JUnit 协调工作的框架，该框架在一个预定的时间限制内执行测试用例：如果一个测试中的方法所用的时间比预期的阈值长，则认为该测试是失败的。通过将性能测试集成到自动化构建中，您能有效地监控应用程序的性能甚至能在出现性能问题时使构建失败。
但我倾向于将 JUnitPerf 用作一种发现早期性能问题的简单方法，而不是将其作为一种机制来衡量执行时间；像 profilers 这样的工具更善于提供此类衡量。在本质上，可以认为 JUnitPerf 是一个早期的警告系统。
文章来源于领测软件测试网 https://www.ltesting.net/
