原文信息
数据库单元测试工具-SQLUnit
前言
正如之前所说，我已经改变了原有写代码方式。不是立马就写出测试用例的“测试驱动开发”(我知道这种开发理论很难站住脚)。但当我预计到这种编程方式必定存在问题时，这已经是一个好的开始了。在一条带有自动序列号的主键的 INSERT 语句下，我是否应该转换程序中异常为自己的系统的错误代码?或者仅仅让 RA-00001 传播开?我采取的办法是，仅仅弹出 Oracle 自身提示的错误码，没有必要自己为出现错误再重新创建一套错误码机制。如果你在某种情况下得到一个错误码，已经很严肃地告诉了用户当前有些事情已经出错了，并且全世界的人都应该知道系统出错了。
说说异常吧，使用它们，抛出它们，不要试图捕捉它们(大部分情况下)并且来做一些其他的事情。将异常记录下来然后把它们抛向上一层。我想：让每一个开发者都知道当前状况已经开始变坏，这是一件很好的事情。我曾花费太多的时间来通过调试代码来尝试找出系统的错误，但大部分的异常已经被捕捉了而且进程继续往下跑，导致我浪费了很多时间。至少在某些情况下，我幸运地通过记录错误的日志来解决的问题。
什么是 SQLUnit
SQLUnit 是一个回归测试数据库存储过程的单元测试工具。一个 SQLUnit 测试用例应该用 XML 文件来书写。SQLUnit工具 是用 Java 实现的，使用 JUnit 单元测试矿建转换 XML 测试信息到 JDBC 数据库连接，比较从数据库中得到的结果和测试用例中的预期结果。不幸的是，它仅仅只持续了三年的开发过程，但我想说的是：这是一个相当好的测试模型。支持存储过程、函数、游标以及用户自定义类型(尽管我还没有尝试过)。当前最新版本是 5.0.我一直在用的是 1.3 版本。一个大学同学(现在在Oracle 公司工作)，在我刚开始使用 SQLUnit 测试工具的时候，他甚至为SQLUnit 中 Oracle 数据库的测试部分贡献了代码。
我通过它来为 CABEZE 构建数据库，这是我第一次为自己的事业做的项目，尽管最终没有成功，但也很好，因为我只是在一些零零碎碎、不太重要的代码上建立起的项目，所以我可以通过 SQLUnit 来构建整个测试数据(不是测试实际上的产品数据...尽管也没有实际的设备)，建立起数据库(创建测试数据)，运行测试用例并且最后在销毁阶段回滚到原始状态(空的)。不幸的是，我工作中构建的那个系统不是空的并且是以实际产品进行测试的，或者半生产(清洗) 数据是仅仅是一种可行的替代品.
回到现在我的状态。我正尝试重新认识自己，在这个工具的帮助下为多种多样的存储过程书写测试用例。我跟进一个报出错误的测试用例中，因为我们所有的信用卡号都是杂乱的。每一次在不正确的卡号下失败。攀附之物。
为什么不创建一个例程，一个可以生产“实际”信用卡号，更精确的说是：一串已经检测了数字的合适长度的数列?所以信用卡使用 Luhn 公式用于阻止这些明显的调换错误。
这 Luhn 算法将检测任何奇数的错误，大部分的调换临近的数组。它将不是，然而，检测 调换位置两数字序列 09-90(或者副动词)。它将检测到 在 10 个可能重复数字中检测出7个(它不能检测出 22 ? 55, 33 ? 66 or 44 ? 77)。
在 CABEZE 下，我已经重写了我自己的 PL/SQL
卡号生成器(并且通过验证)，但现在我不把它公布出来，而且我好像已经丢失了那部分代码。所以，我尝试重写一遍。
从我开始使用 SQLUnit 后，我体验到这个工具演示了一个多么强大的功能呀!它拥有一些复杂(对于我来说)的公式，所以在写这些测试用例的时候能够帮我计算出结果。这是我创建坚持测试基于 Luhn 公式的数字序列。
?
1
【数据库单元测试工具-SQLUnit】相关文章：
★ 如何在SQL Server 2005数据库中导入SQL Server 2008的数据