第二部分：从测试开始
在编写代码前建立一个测试计划，可以节省您的时间。
在本系列的 第一篇文章 中，我决定构建一个可以对代码进行质量检查的实用工具：非凡是识别 PL/SQL 程序包中具有歧义或者潜在歧义的超载问题。
此外，我还识别数据源（ ALL_ARGUMENTS 数据字典视图）和代码（ DBMS_DESCRIBE 程序包），以帮助构建实用工具。下一步要做什么呢？
坦率地说，我自然倾向于打开我所喜爱的集成开发环境 (IDE) 并开始动指如飞地编写代码，投入激动人心的创作之中。我希望在工作时思考并得出结论，不断地应对挑战，使工作成果运行起来，然后对其进行微调。
这种方法有积极的方面（您当然不会有过度设计的风险），但也有很多缺点。首先，假如我所使用的构建方法是直通式构造非线性系统 — 常被亲切地称为 HRCLS 或 Hercules （一种 非常 轻型的方法论），我最终不会仅是微调代码。绝对不会，在我将范围缩小到最终目的、目标和实质内容时，我最终将会以重写整个程序 — 一次、两次或三次。但是，尽管可以激动地看到，经过自己的努力，实用工具成形、进步并改观，但这会浪费很多的时间。
对于 Codecheck ，我会忍住最初的诱惑。我不会在项目开始的头 60 秒内就编写代码，而是做一个简单的声明：我保证使我编写的代码适用于一个全面的测试计划。
这与避免 Hercules 综合症有什么必然的关系呢？让我们来考虑这种保证的含义：
我将制订一个测试计划，它非常全面，精心策划了数十个（甚至可能有 100 个之多）测试方案，包括参数的数量、各种数据类型的结合以及缺省值的有无。
我要设计、构建和运行测试，这些测试可确定我的代码是否满足测试计划的要求：换言之，设计、构建和运行涵盖我的全部测试方案的测试。
天哪，这听起来确实很有道理，不是吗？我的意思是，谁 会 一直做所有的这些事情？况且，我们都知道这样的事实：我们之中很少有人实际上会花时间，或在手边有必备的工具去做全面的测试。实际上我认为，世界上至少百分之九十的软件开发人员和开发团队（包括我自己）远远不会完全按上述保证去做。
对我来说，在开发初始时我表明要执着地进行测试，我发现这一点促使我实现了 Codecheck 。
定义范围，做出假设
在开发一项测试策略并构造测试之前，我需要确定项目的使用范围。用户群通常确定（并经常更改）项目的使用范围。对于 Codecheck 以及我制作的很多其他实用工具，您，开发人员，是我的用户，但我仍然需要确定使用范围，把您的需求作为我的指导。我的目标是产生一个代码体，能立即帮助开发人员提高代码质量，但也可以作为一项稳定而且可扩展的功能，开发人员可以将其加入代码中满足自己的需要。它必须能够处理现实世界中足够的复杂性，这样才有用处，但又不可太复杂，以至于将 Codecheck 开发变成一种全职工作。
当我深入查看 ALL_ARGUMENTS 的内容时，我吃惊地发现那些参数列表会变得非常复杂。例如，在 Oracle9 i 的环境中，一个参数可以将记录的结合数组（以前称为表的索引）作为其类型，其中记录的一个字段是另一个结合数组，以此类推。非常坦率地说，我实际上不希望必须编写代码来处理这些参数全部的可能情况。
与此相反， Codecheck 将只基于 “0 级 ” 参数来检查和进行分析：这是指在 ALL_ARGUMENTS 视图中的那些项目，当其出现在程序头时，它们对应于参数列表。实际上，这可能是您为分析超载而 所需 的全部要素，但是全部的具体资料可能在进行某种其他的代码检查时派上用场。（在撰写此文章时，我已确定了一种需要更多信息的情况：假如您将一个参数定义为表单 %ROWTYPE 的记录，则 ALL_ARGUMENTS 和 DBMS_DESCRIBE 都不会提供其类型的信息。您可能必须比较那些行类型（ 1 级或更多级）的 各个字段 的数据类型以识别岐义。天哪。
定义测试策略
开发 Codecheck 的下一步是探究和定义测试策略。我曾提到过，我承诺编写能够满足测试计划的代码，这种承诺影响着开发过程。例如，我在编写如 Codecheck 等实用工具时的第一个冲动是，制作一个程序，接受一个程序包的名称并在屏幕上显示代码检查的结果。为了确定实用工具是否正确工作，我需要查看屏幕上的检查结果并对其进行分析。这听起来如何？熟悉吗？可伸缩吗？通常这种方法甚至对非常简单的程序都无效。
Codecheck 测试计划无疑会有很多测试方案，而其结果并不明确。换言之，除非我记住成功对所有这些测试方案意味着什么，否则我必须依靠手动的、直观的验证（先看这个窗口；然后将其与那个窗口的内容进行比较）。我需要用很长的时间完成一项测试（这是构成责任性的一项相当重要的要素），所以我很少进行测试 — 假如曾做过测试的话。这与我的保证相违反。
我需要找到一种更快捷方便的测试方法。使用 Java 的许多开发人员转向 Junit 。 PL/SQL 开发人员则利用 utPLSQL ，一种用于 PL/SQL 开发人员的开放源单元测试框架。（申明：我是 utPLSQL 的创建者，尽管其他人现在也帮助进行实施并制作文档。）
我不会在本文中以很大的篇幅具体描述 utPLSQL 的起源、理论基础或基本工作方式。
假如您需要了解比本文内容更具体的情况，请访问 http://utplsql.sourceforge.net/ 或 http://utplsql.oracledeveloper.nl 。
utPLSQL 简介
utPLSQL 是一种用于 PL/SQL 程序的测试框架（代码以及使用这种代码的进程的集合）。使用 utPLSQL ，您可以构造包含单元测试过程的单元测试程序包，并依照 utPLSQL 的命名规范和测试机制来设计此程序包。然后您只须简单地操作 utPLSQL 来测试程序或程序包。它运行所有测试并自动检测该测试是否成功或失败。它准确指出失败的测试方案，使您更快地确定正确的测试方案并识别应用程序中错误的原因。
这种框架是基于极限编程的单元测试概念 ( www.XProgramming.com ) 以及 Junit （ Java 单元测试框架）。下面是一些该方法进行单元测试的基本原则：
在编写代码前编写单元测试。
少做编写和更改，多做测试。
自动执行测试和生成报告：红绿灯式的方法。
图 1 表示 utPLSQL 体系结构的一个简化视图，它是以强大有效的方式自动执行测试的一个往返旅程。下面对行程中的各站作一解释：
调用 utPLSQL 测试过程执行测试程序包。 utPLSQL 按照动态 PL/SQL 和命名规范来运行任何设置代码，定位并执行单元测试程序，并进行必要的清除（ “ 拆卸 ” 步骤）。
单元测试过程调用 “ 判定 API” ，它将测试结果与 “ 控制 ” 条件进行比较。
判定程序将结果（通过或失败）写到下面的结果表中。
tPLSQL 测试读出结果表中的内容，确定该测试的状态。
utPLSQL 根据结果作出报告，或者通过 DBMS_OUTPUT 送到屏幕，或者通过 UTL_FILE 送到一个文件。
让我们来看一个很简单的示例，从而大致了解单元测试程序包的内容。假设我已经创建了一个关于 SUBSTR 的封装，答应在开始和结束点之间请求一个子串（一个简单的函数）（ 列表 1 ）。
即使是简单的或看似不重要的程序（如 betwnStr ）也需要测试 — 而实际上我必须考虑大量的测试方案（包括 NULL 开始值、 NULL 结束值以及开始大于结束等）。 列表 2 显示了测试程序包的一部分（全部测试包的内容请参见 ut_betwnstr.pkb ）。关于要害部分的解释，请参见 表 1 。
也许您会想， “ 多么单调乏味！我真的必须编写所有那些代码，只是为了测试这个简单的函数吗？ ” 实际上，那些在测试领域工作的人都知道，测试一个应用程序所需要编写的代码数量经常比应用程序本身更多。对于这个特定的程序包和测试代码的 utPLSQL 风格，您在某些情况下会生成全部的测试代码。实际上， ut_betwnstr 程序包 通过 对 utGen.testpkg_from_string 过程的调用而生成， 如列表 3 所示 。
即使您不生成测试程序包，也经常可以找到其他方法，利用最少的代码运行许多基于 utPLSQL 的测试 — 这正是我用 Codecheck 所做的工作。
将 utPLSQL 应用于 Codecheck
要利用 utPLSQL ，我需要构建一个单元测试程序包并调用 utAssert 程序，以确定我的代码是否通过其测试。但是，在进行这些操作之前，我需要精心制作我的测试方案。请记住：测试方案第一，其次才是代码。
现在应该寻找灵感，暂停前进，考虑一下我所提供的实用工具。我希望它能够验证什么？那些能编译但包含歧义超载的程序包的特例是什么？我能检测到什么情况？有效超载的示例是什么？究竟我需要测试正面和负面的因素。经过一段时间以后，我给出以下的内容：
有效的超载
两个超载程序带有不同数量的非缺省参数。
两个超载程序带有相同数量的非缺省参数，并在数据类型方面具有足够的差别（如 NUMBER 对 DATE ）。
函数和过程具有相同名称和参数列表，包括不带参数的情况。区分这两者并没有问题，因为它们在代码中的使用方法不同。
无效的超载
两个超载程序具有不同数量的非缺省参数，导致歧义的参数列表。
两个程序具有单个参数，数据类型相同但参数名不同。
两个程序具有相同的名称，具有单个参数，但却是同系列中不同的数据类型。
一个程序没有参数，第二个程序具有一个带缺省值的参数。
一个程序具有 N 个参数，第二个程序具有 N+1 个参数，全部带有缺省值。
一个程序具有 N 个参数，其中 N-1 个参数有缺省值；第二个程序具有 N+1 个参数，其中最后两个缺省。
