So-net無料ブログ作成

コード・カバレッジ備忘録 [Oracle]

このエントリは JPOUG Advent Calendar 2014 14日目への参加記事です。
今回はPL/SQLのコード・カバレッジについて、気付いた点がありましたので、
書き留めておこうと思います。

SQL Developer 2.1よりユニット・テスト機能を使用して、パッケージや
プロシージャ(PL/SQLユニット)のコード・カバレッジが取得できるように
なりました。
ユニット・テストをスイートに纏めることにより、複数のユニット・テストの
カバレッジを1つにまとめることもでき、非常に便利です。
(ユニット・テストの作成については Oracle By Example の
  「Oracle SQL Developer 3.0でのPL/SQLユニット・テストの実行」が
  スクリーンショット付でわかりやすいと思います。)

ただし、Oracle Database 10g以降では「PL/SQLのコード最適化」というものが
自動で行われているので、カバレッジの取得には注意が必要です。
以下は、そこらへんのちょっとした備忘録です。

■注意1:PLSQL_CODE_TYPE 属性
  そもそもこいつが NATIVE だと、カバレッジ自体取得できません。
  ユニット・テストのカバレッジが表示されない場合は、
  USER_PLSQL_OBJECT_SETTINGS ディクショナリから PL/SQLユニットの
  PLSQL_CODE_TYPE 属性を確認してみてください。
  11gからお手軽に NATIVE コンパイルができるようになったため、
  DBAの与り知らぬところで NATIVE コンパイルなっていた、ということも
  あり得ます。(要はウチの現場)


■注意2:PLSQL_OPTIMIZE_LEVEL 属性
  こいつの値によって、コードの最適化のされ方が異なるそうです。
  「PLSQL_OPTIMIZE_LEVEL = 2」に設定すると、最適化の範囲が大きくなるため、
  コードの通過回数がおかしくなったように見えてしまいます。
  「PLSQL_OPTIMIZE_LEVEL = 1」に設定しておくのがよいようです。

  コード最適化の詳細は「Oracle Database PL/SQL言語リファレンス」の
  「12 PL/SQLの最適化とチューニング」を見てもらうとして、
  PLSQL_OPTIMIZE_LEVEL 属性値ごとにテストコードのコード・カバレッジを
  貼っておきます。
  サブプログラム ADD1 あたりのコード通過回数が異なっているのが
  わかると思います。

coverage01.jpg
  図1:PLSQL_OPTIMIZE_LEVEL = 1 のコード・カバレッジ

coverage02.jpg
  図2:PLSQL_OPTIMIZE_LEVEL = 2 のコード・カバレッジ

coverage03.jpg
  図3:PLSQL_OPTIMIZE_LEVEL = 3 のコード・カバレッジ


■注意3:PLSQL_DEBUG 属性
  こいつが「TRUE」だと、前述の PLSQL_OPTIMIZE_LEVEL 属性が「1」に、
  「FALSE」だと「2」になります。
  SQL Developer のコンパイルはボタンのワン・クリックで可能ですが、
  デフォルトは通常のコンパイルとなります。
  「デバッグ用にコンパイル」するには ツー・アクション必要となります。

  PL/SQLユニットの修正を繰り返すうちに熱くなって、うっかり
  「デバッグ用にコンパイルするの忘れたー」というようなことも
  あり得ます。(要はウチの現場)
  結果として、コード最適化により通過すべきコードが通過していないように
  見えてしまうため、全PL/SQLユニットのカバレッジ取り直し何てことに…
  ならないよう注意しましょう。

明日の扉は佐々木潤さんです。よろしくお願いします。

 


WITH句がまた便利になった。|- ブログトップ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。

この広告は180日新規投稿のないブログに表示されます