PL/SQLにはいくつかの異なるテストツールがあります。 Steven Feuerstein
そのうちの2つ、utplsql
を作成しました。 および
QCTOにはGUIが付属しています。つまり、他のQuest製品（TOADなど）と同様に、Windowsのみです。テストデータの生成を正確に自動化するわけではありませんが、それをサポートするためのインターフェイスを提供します。また、他のQuest製品と同様に、フリーウェアのコピーがありますが、QCTOはライセンスされています。
Steven（開示、彼は私のOracleヒーローの1人です）は、すべてのPL/SQLテストツールの機能比較を作成しました。もちろん、QOTCがトップになりますが、比較は正直だと思います。 チェックしてください。
utplsqlのテストフィクスチャに関するアドバイス
ユニットテスト用のテストデータを管理することは、首の痛みになる可能性があります。残念ながら、utplsqlは負担を負担するために多くを提供していません。だから
- 常に既知の値に対してテストします ：
- dbms_randomの使用は避けてください;
- シーケンスの使用を、値が重要ではない列に制限するようにしてください。
- 日付も注意が必要です。日付のハードコーディングは避けてください。sysdateが入力されている変数を使用してください。
add_months()の理解を学ぶ 、last_day()、interval、trunc(sysdate, 'MM')、など。
- 他のユーザーからテストデータを分離します。ゼロから構築します。可能な限り、独自の値を使用してください。
- 必要な数のテストデータのみを作成します。体積試験は別の責任です。
- データを変更する手順をテストする場合、単体テストごとに特定のレコードを作成します。
- また、別のテストからの入力を提供するために、あるテストからの成功した出力に依存しないでください。
- 必要に応じて、単体テスト間でデータ共有レコードに対して単にレポートする手順をテストする場合。
- 可能な限り、フレームワークデータ（参照される主キーなど）を共有します。
- フリーテキストフィールド（名前、説明、コメント）を使用して、レコードを使用する1つまたは複数のテストを識別します。
- 新しいレコードの作成に伴う作業を最小限に抑えます。
- テストスイートとテーブルの制約に必要な値のみを割り当てます。
- 可能な限りデフォルト値を使用します。
- 可能な限り手続きを進めます。
その他の注意事項：
- テストフィクスチャの設定は、時間のかかる作業になる可能性があります。大量のデータがある場合は、セッションごとに1回実行できる静的データを設定する手順を作成し、
ut_setupに揮発性データのみを含めることを検討してください。 自体。これは、読み取り専用機能をテストするときに特に役立ちます。 - テストデータの作成はそれ自体がプログラミングの演習であるため、バグが発生しやすいことを忘れないでください。
- utplsqlのすべての機能を使用します。
utAssert.EqQuery、utAssert.EqQueryValue、utAssert.EqTable、utAssert.EqTabCountおよびutAssert.Eq_RefC_Query揮発性データの値を推測する場合、これらはすべて非常に便利な機能です。 - 期待どおりに進まなかったテスト実行を診断する場合は、使用されたデータがあると便利です。したがって、中空の
ut_teardownを使用することを検討してください。 手順とut_setupの開始時のテストデータのクリア 。
レガシーコードの処理
ゲイリーの投稿にコメントすることで、あなたが役立つと思うもう1つのことを思い出しました。 Steven Fは、TestFirstムーブメントのJavaの先駆者であるJUnitのPL/SQL実装としてulplsqlを作成しました。ただし、TDDの手法は、大量のレガシーコードにも適用できます（このコンテキストでは、レガシーコードは単体テストのないプログラムのセットです）。
覚えておくべき重要なことは、すべてをすぐに単体テストにかける必要がないということです。段階的に開始します。新しいものの単体テストを作成します。
この分野には多くの考えがありますが、（恥ずべきことですが）それは主にOOプログラマーからのものです。マイケルフェザーズがメインチャップです。彼の記事