DbUnitTest的典型使用场景
1. 数据库脚本重构(Refactor): 原有的数据库脚本(存储过程或Sql 语句)已经经过实践检验, 逻辑正确, 但是效率有待提高. 接下的任务是重写或重构原有的脚本. 我们可以针对这个数据库脚本编写若干个测试用例, 最好做到比较高的测试覆盖率. 然后用DbUnitTest来跑一下这些测试用例, 有DbUnitTest Gui界面上若红灯出现, 就表明你新写的脚本有问题, 非常直观.
2. 回归测试(Regression Test). 模拟场景: 前几天你对数据库脚本做了一些修改, 今天Application的测试人员跑过来, 和你讲, “好像数据库脚本有些问题”. 你也许心里在骂, “有错误, 不早点告诉我, 现在告诉我, 不是明摆着叫我加班, 今天晚上我可佳人有约啊” . 其实, 我们自己也知道, 这根本不能责怪Application的测试人员, 这是典型的Bug leakage, 而且是你产生的bug. 一个好的做法是, 你先写好数据库脚本的测试用例, 每次对数据库脚本进行修改/重构后, 只需要用DbUnitTest来跑一下测试用例, 一眼就知道你的修改正不正确, 而不用等Application开发/测试人员.
3. 数据比对. 这种情形在很多软件外包公司很常见, client 发过一个excel表格和oracle数据库的dump, 里面都包含几万条记录, client的要求很简单, 就是找出excel和oracle表的数据有哪些不一致. 要求虽小, 却苦了外包公司的同胞们了, 辛苦地比对着, 一个项目做下来, 近视了好几百度.
没有评论:
发表评论