diff --git a/.github/workflows/build_pages.yml b/.github/workflows/build_pages.yml new file mode 100644 index 0000000..6304cfc --- /dev/null +++ b/.github/workflows/build_pages.yml @@ -0,0 +1,25 @@ +# Based on: https://blog.elmah.io/deploying-a-mkdocs-documentation-site-with-github-actions/ +name: build +on: + push: + branches: + - main +jobs: + deploy: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + with: + fetch-depth: 0 + - uses: actions/setup-python@v2 + with: + python-version: 3.x + - name: Setup MkDocs + run: | + pip install mkdocs-material + pip install mkdocs-git-revision-date-localized-plugin + pip install mkdocs-include-markdown-plugin + pip install mike + pip install mkdocs-git-committers-plugin-2 + - name: Build website + run: mkdocs gh-deploy --verbose diff --git a/.gitignore b/.gitignore index 45c1505..3195cfd 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,7 @@ _site .sass-cache .jekyll-metadata +.idea +/.jekyll-cache/ +/Gemfile.lock +/site \ No newline at end of file diff --git a/CNAME b/CNAME new file mode 100644 index 0000000..c9c61f1 --- /dev/null +++ b/CNAME @@ -0,0 +1 @@ +www.utplsql.org \ No newline at end of file diff --git a/README.md b/README.md index 18a1b16..eefe1a3 100644 --- a/README.md +++ b/README.md @@ -1,41 +1,45 @@ -# Maintainging the utPLSQL Website - -The [utPLSQL website](https://utplsql.github.io) is powered by [Jekyll](https://jekyllrb.com/). Which generated HTML when you push a commit to [utplsql.github.io](https://github.com/utPLSQL/utPLSQL.github.io). - -This also works in harmony with the gh-pages branches on the various other repository to create a single website. For example the [utpsql](https://github.com/utPLSQL/utPLSQL) repositories [gh-pages](https://github.com/utPLSQL/utPLSQL/tree/gh-pages) branch, is visible at [https://utplsql.github.io/utPLSQL/](https://utplsql.github.io/utPLSQL/). - -This allows for documentation from each sub repository to host it's own documentation without having to modify the utpsql.github.io repsitory directly. - +# Maintaining the utPLSQL Website +The [utPLSQL website](https://utplsql.github.io) is generated using [MkDocs](https://www.mkdocs.org/) and [material theme](https://squidfunk.github.io/mkdocs-material) +[Mike](https://github.com/jimporter/mike) is used for versioning of documentation see also [this page](https://squidfunk.github.io/mkdocs-material/setup/setting-up-versioning/) ## How to make an announcement post. -Create a File in the [_posts](https://github.com/utPLSQL/utPLSQL.github.io/tree/master/_posts) directory with the file name of `YYYY-MM-DD-Blog-Post-Name.md` +- Create a new post file in the [docs/_posts](https://github.com/utPLSQL/utPLSQL.github.io/tree/main/docs/_posts) directory with the file name of `YYYY-MM-DD-Blog-Post-Name.md` This file will be a standard [Markdown file](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) which can be editing with any text editor although there are many offline and online editors for Markdown. +- Add new entry pointing to new announcement file to the start of `nav` section in `mkdocs.yml` +- Add new entry to the top of `index.md` +- Commit and push changes to develop branch -This file will be a standard [Markdown file](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) which can be editing with any text editor although there are many offline and online editors for Markdown. +## Local setup -The file will also need a YAML Front Matter section at the top of the file. +If you want to generate and preview the website locally, you will need to have [python and pip installed](https://squidfunk.github.io/mkdocs-material/getting-started/)) - --- - layout: post - title: "Title of Blog Post" - date: 2016-06-20 15:00:00 -0600 - categories: moving - --- +To install mkdocs required components, you need to execute the below commands from command line: +``` +pip install mkdocs-material +pip install mkdocs-git-revision-date-localized-plugin +pip install mike -Look at an existing post if you want an example. +``` -## How to preview site locally - -Jekyll will allow you to preview the site locally doing the following: - -1. [Install Jekyll 3](https://jekyllrb.com/docs/installation/) -2. [Use Jekyll Serve](https://jekyllrb.com/docs/usage/) +Once installed you can use following commands from command line: +`mkdocs serve` - will stat a local server, so you can see the web page generated locally and tet real-time updates to documentation +The pages are automatically generated on every commit to the `main` branch. +If however you would need to generate pages manually from your local copy, use the command: +`mkdocs gh-deploy`. +The generated web pages are hen visible at [utplsql.org](https://utPLSQL.org). +Individual project documentation pages are deployed separately from the main organization page. +Each corresponding project repository needs to have its own gh-pages branch. + +utPLSQL-framework repository uses `mike` to deploy documentation for specific project version. +Example commands to use are: +- `mike deploy develop` - to deploy documentation for develop branch +- `mike deploy -p develop` - to deploy and push documentation for develop branch +- `mike deploy -p -u v3.1.12 latest` - to deploy and push documentation for version v3.1.12 and update the `latest` alias to point to that version - diff --git a/_config.yml b/_config.yml deleted file mode 100644 index 123152f..0000000 --- a/_config.yml +++ /dev/null @@ -1,21 +0,0 @@ -# Welcome to Jekyll! -# -# This config file is meant for settings that affect your whole blog, values -# which you are expected to set up once and rarely need to edit after that. -# For technical reasons, this file is *NOT* reloaded automatically when you use -# 'jekyll serve'. If you change this file, please restart the server process. - -# Site settings -title: utPLSQL -google_analytics: UA-80445365-1 -email: -description: > # this means to ignore newlines until "baseurl:" - utPLSQL
- Unit Testing Framework for Oracle PL/SQL. -baseurl: "" # the subpath of your site, e.g. /blog -url: "https://utPLSQL.github.com" # the base hostname & protocol for your site -twitter_username: utplsql -github_username: utplsql -# Build settings -markdown: kramdown -exclude: ["README.md","dl-files"] \ No newline at end of file diff --git a/_includes/analytics.html b/_includes/analytics.html deleted file mode 100644 index d63436d..0000000 --- a/_includes/analytics.html +++ /dev/null @@ -1,11 +0,0 @@ - - diff --git a/_includes/footer.html b/_includes/footer.html deleted file mode 100644 index 3e45918..0000000 --- a/_includes/footer.html +++ /dev/null @@ -1,29 +0,0 @@ - diff --git a/_includes/head.html b/_includes/head.html deleted file mode 100644 index e77b434..0000000 --- a/_includes/head.html +++ /dev/null @@ -1,16 +0,0 @@ - - - - - - {% if page.title %}{{ page.title | escape }}{% else %}{{ site.title | escape }}{% endif %} - - - - - - -{% if jekyll.environment == 'production' %} -{% include analytics.html %} -{% endif %} - diff --git a/_includes/header.html b/_includes/header.html deleted file mode 100644 index b3f86db..0000000 --- a/_includes/header.html +++ /dev/null @@ -1,27 +0,0 @@ - diff --git a/_includes/icon-github.html b/_includes/icon-github.html deleted file mode 100644 index e501a16..0000000 --- a/_includes/icon-github.html +++ /dev/null @@ -1 +0,0 @@ -{% include icon-github.svg %}{{ include.username }} diff --git a/_includes/icon-github.svg b/_includes/icon-github.svg deleted file mode 100644 index 4422c4f..0000000 --- a/_includes/icon-github.svg +++ /dev/null @@ -1 +0,0 @@ - diff --git a/_includes/icon-twitter.html b/_includes/icon-twitter.html deleted file mode 100644 index e623dbd..0000000 --- a/_includes/icon-twitter.html +++ /dev/null @@ -1 +0,0 @@ -{% include icon-twitter.svg %}{{ include.username }} diff --git a/_includes/icon-twitter.svg b/_includes/icon-twitter.svg deleted file mode 100644 index dcf660e..0000000 --- a/_includes/icon-twitter.svg +++ /dev/null @@ -1 +0,0 @@ - diff --git a/_layouts/default.html b/_layouts/default.html deleted file mode 100644 index e4ab96f..0000000 --- a/_layouts/default.html +++ /dev/null @@ -1,20 +0,0 @@ - - - - {% include head.html %} - - - - {% include header.html %} - -
-
- {{ content }} -
-
- - {% include footer.html %} - - - - diff --git a/_layouts/page.html b/_layouts/page.html deleted file mode 100644 index ce233ad..0000000 --- a/_layouts/page.html +++ /dev/null @@ -1,14 +0,0 @@ ---- -layout: default ---- -
- -
-

{{ page.title }}

-
- -
- {{ content }} -
- -
diff --git a/_layouts/post.html b/_layouts/post.html deleted file mode 100644 index 3a0fb52..0000000 --- a/_layouts/post.html +++ /dev/null @@ -1,15 +0,0 @@ ---- -layout: default ---- -
- -
-

{{ page.title }}

- -
- -
- {{ content }} -
- -
diff --git a/_sass/_base.scss b/_sass/_base.scss deleted file mode 100644 index 0883c3c..0000000 --- a/_sass/_base.scss +++ /dev/null @@ -1,206 +0,0 @@ -/** - * Reset some basic elements - */ -body, h1, h2, h3, h4, h5, h6, -p, blockquote, pre, hr, -dl, dd, ol, ul, figure { - margin: 0; - padding: 0; -} - - - -/** - * Basic styling - */ -body { - font: $base-font-weight #{$base-font-size}/#{$base-line-height} $base-font-family; - color: $text-color; - background-color: $background-color; - -webkit-text-size-adjust: 100%; - -webkit-font-feature-settings: "kern" 1; - -moz-font-feature-settings: "kern" 1; - -o-font-feature-settings: "kern" 1; - font-feature-settings: "kern" 1; - font-kerning: normal; -} - - - -/** - * Set `margin-bottom` to maintain vertical rhythm - */ -h1, h2, h3, h4, h5, h6, -p, blockquote, pre, -ul, ol, dl, figure, -%vertical-rhythm { - margin-bottom: $spacing-unit / 2; -} - - - -/** - * Images - */ -img { - max-width: 100%; - vertical-align: middle; -} - - - -/** - * Figures - */ -figure > img { - display: block; -} - -figcaption { - font-size: $small-font-size; -} - - - -/** - * Lists - */ -ul, ol { - margin-left: $spacing-unit; -} - -li { - > ul, - > ol { - margin-bottom: 0; - } -} - - - -/** - * Headings - */ -h1, h2, h3, h4, h5, h6 { - font-weight: $base-font-weight; -} - - - -/** - * Links - */ -a { - color: $brand-color; - text-decoration: none; - - &:visited { - color: darken($brand-color, 15%); - } - - &:hover { - color: $text-color; - text-decoration: underline; - } -} - - - -/** - * Blockquotes - */ -blockquote { - color: $grey-color; - border-left: 4px solid $grey-color-light; - padding-left: $spacing-unit / 2; - font-size: 18px; - letter-spacing: -1px; - font-style: italic; - - > :last-child { - margin-bottom: 0; - } -} - - - -/** - * Code formatting - */ -pre, -code { - font-size: 15px; - border: 1px solid $grey-color-light; - border-radius: 3px; - background-color: #eef; -} - -code { - padding: 1px 5px; -} - -pre { - padding: 8px 12px; - overflow-x: auto; - - > code { - border: 0; - padding-right: 0; - padding-left: 0; - } -} - - - -/** - * Wrapper - */ -.wrapper { - max-width: -webkit-calc(#{$content-width} - (#{$spacing-unit} * 2)); - max-width: calc(#{$content-width} - (#{$spacing-unit} * 2)); - margin-right: auto; - margin-left: auto; - padding-right: $spacing-unit; - padding-left: $spacing-unit; - @extend %clearfix; - - @include media-query($on-laptop) { - max-width: -webkit-calc(#{$content-width} - (#{$spacing-unit})); - max-width: calc(#{$content-width} - (#{$spacing-unit})); - padding-right: $spacing-unit / 2; - padding-left: $spacing-unit / 2; - } -} - - - -/** - * Clearfix - */ -%clearfix { - - &:after { - content: ""; - display: table; - clear: both; - } -} - - - -/** - * Icons - */ -.icon { - - > svg { - display: inline-block; - width: 16px; - height: 16px; - vertical-align: middle; - - path { - fill: $grey-color; - } - } -} diff --git a/_sass/_layout.scss b/_sass/_layout.scss deleted file mode 100644 index 3f80312..0000000 --- a/_sass/_layout.scss +++ /dev/null @@ -1,246 +0,0 @@ -/** - * Site header - */ -.site-header { - /*border-top: 5px solid $grey-color-dark; - border-bottom: 1px solid $grey-color-light; */ - background-color: $header-background; - min-height: 56px; - - // Positioning context for the mobile navigation icon - position: relative; -} - -.site-title { - font-size: 26px; - font-weight: 300; - line-height: 56px; - letter-spacing: -1px; - margin-bottom: 0; - float: left; - color: $header-text; - &, - &:visited { - color: $header-text; - } -} - -.site-nav { - float: right; - line-height: 56px; - - .menu-icon { - display: none; - } - - .page-link { - color: $header-text; - line-height: $base-line-height; - - // Gaps between nav items, but not on the last one - &:not(:last-child) { - margin-right: 20px; - } - } - - @include media-query($on-palm) { - position: absolute; - top: 9px; - right: $spacing-unit / 2; - background-color: $header-background; - border: 1px solid $grey-color-light; - border-radius: 5px; - text-align: right; - - .menu-icon { - display: block; - float: right; - width: 36px; - height: 26px; - line-height: 0; - padding-top: 10px; - text-align: center; - - > svg { - width: 18px; - height: 15px; - - path { - fill: $header-text; - } - } - } - - .trigger { - clear: both; - display: none; - } - - &:hover .trigger { - display: block; - padding-bottom: 5px; - } - - .page-link { - display: block; - padding: 5px 10px; - - &:not(:last-child) { - margin-right: 0; - } - margin-left: 20px; - } - } -} - - - -/** - * Site footer - */ -.site-footer { - border-top: 1px solid $grey-color-light; - padding: $spacing-unit 0; -} - -.footer-heading { - font-size: 18px; - margin-bottom: $spacing-unit / 2; -} - -.contact-list, -.social-media-list { - list-style: none; - margin-left: 0; -} - -.footer-col-wrapper { - font-size: 15px; - color: $grey-color; - margin-left: -$spacing-unit / 2; - @extend %clearfix; -} - -.footer-col { - float: left; - margin-bottom: $spacing-unit / 2; - padding-left: $spacing-unit / 2; -} - -.footer-col-1 { - width: -webkit-calc(35% - (#{$spacing-unit} / 2)); - width: calc(35% - (#{$spacing-unit} / 2)); -} - -.footer-col-2 { - width: -webkit-calc(20% - (#{$spacing-unit} / 2)); - width: calc(20% - (#{$spacing-unit} / 2)); -} - -.footer-col-3 { - width: -webkit-calc(45% - (#{$spacing-unit} / 2)); - width: calc(45% - (#{$spacing-unit} / 2)); -} - -@include media-query($on-laptop) { - .footer-col-1, - .footer-col-2 { - width: -webkit-calc(50% - (#{$spacing-unit} / 2)); - width: calc(50% - (#{$spacing-unit} / 2)); - } - - .footer-col-3 { - width: -webkit-calc(100% - (#{$spacing-unit} / 2)); - width: calc(100% - (#{$spacing-unit} / 2)); - } -} - -@include media-query($on-palm) { - .footer-col { - float: none; - width: -webkit-calc(100% - (#{$spacing-unit} / 2)); - width: calc(100% - (#{$spacing-unit} / 2)); - } -} - - - -/** - * Page content - */ -.page-content { - padding: $spacing-unit 0; -} - -.page-heading { - font-size: 20px; -} - -.post-list { - margin-left: 0; - list-style: none; - - > li { - margin-bottom: $spacing-unit; - .post-excerpt { - font-size: 16px; - font-style: italic; - } - } -} - -.post-meta { - font-size: $small-font-size; - color: $grey-color; -} - -.post-link { - display: block; - font-size: 24px; -} - - -/** - * Posts - */ -.post-header { - margin-bottom: $spacing-unit; -} - -.post-title { - font-size: 42px; - letter-spacing: -1px; - line-height: 1; - - @include media-query($on-laptop) { - font-size: 36px; - } -} - -.post-content { - margin-bottom: $spacing-unit; - - h2 { - font-size: 32px; - - @include media-query($on-laptop) { - font-size: 28px; - } - } - - h3 { - font-size: 26px; - - @include media-query($on-laptop) { - font-size: 22px; - } - } - - h4 { - font-size: 20px; - - @include media-query($on-laptop) { - font-size: 18px; - } - } -} diff --git a/_sass/_syntax-highlighting.scss b/_sass/_syntax-highlighting.scss deleted file mode 100644 index 8fac597..0000000 --- a/_sass/_syntax-highlighting.scss +++ /dev/null @@ -1,71 +0,0 @@ -/** - * Syntax highlighting styles - */ -.highlight { - background: #fff; - @extend %vertical-rhythm; - - .highlighter-rouge & { - background: #eef; - } - - .c { color: #998; font-style: italic } // Comment - .err { color: #a61717; background-color: #e3d2d2 } // Error - .k { font-weight: bold } // Keyword - .o { font-weight: bold } // Operator - .cm { color: #998; font-style: italic } // Comment.Multiline - .cp { color: #999; font-weight: bold } // Comment.Preproc - .c1 { color: #998; font-style: italic } // Comment.Single - .cs { color: #999; font-weight: bold; font-style: italic } // Comment.Special - .gd { color: #000; background-color: #fdd } // Generic.Deleted - .gd .x { color: #000; background-color: #faa } // Generic.Deleted.Specific - .ge { font-style: italic } // Generic.Emph - .gr { color: #a00 } // Generic.Error - .gh { color: #999 } // Generic.Heading - .gi { color: #000; background-color: #dfd } // Generic.Inserted - .gi .x { color: #000; background-color: #afa } // Generic.Inserted.Specific - .go { color: #888 } // Generic.Output - .gp { color: #555 } // Generic.Prompt - .gs { font-weight: bold } // Generic.Strong - .gu { color: #aaa } // Generic.Subheading - .gt { color: #a00 } // Generic.Traceback - .kc { font-weight: bold } // Keyword.Constant - .kd { font-weight: bold } // Keyword.Declaration - .kp { font-weight: bold } // Keyword.Pseudo - .kr { font-weight: bold } // Keyword.Reserved - .kt { color: #458; font-weight: bold } // Keyword.Type - .m { color: #099 } // Literal.Number - .s { color: #d14 } // Literal.String - .na { color: #008080 } // Name.Attribute - .nb { color: #0086B3 } // Name.Builtin - .nc { color: #458; font-weight: bold } // Name.Class - .no { color: #008080 } // Name.Constant - .ni { color: #800080 } // Name.Entity - .ne { color: #900; font-weight: bold } // Name.Exception - .nf { color: #900; font-weight: bold } // Name.Function - .nn { color: #555 } // Name.Namespace - .nt { color: #000080 } // Name.Tag - .nv { color: #008080 } // Name.Variable - .ow { font-weight: bold } // Operator.Word - .w { color: #bbb } // Text.Whitespace - .mf { color: #099 } // Literal.Number.Float - .mh { color: #099 } // Literal.Number.Hex - .mi { color: #099 } // Literal.Number.Integer - .mo { color: #099 } // Literal.Number.Oct - .sb { color: #d14 } // Literal.String.Backtick - .sc { color: #d14 } // Literal.String.Char - .sd { color: #d14 } // Literal.String.Doc - .s2 { color: #d14 } // Literal.String.Double - .se { color: #d14 } // Literal.String.Escape - .sh { color: #d14 } // Literal.String.Heredoc - .si { color: #d14 } // Literal.String.Interpol - .sx { color: #d14 } // Literal.String.Other - .sr { color: #009926 } // Literal.String.Regex - .s1 { color: #d14 } // Literal.String.Single - .ss { color: #990073 } // Literal.String.Symbol - .bp { color: #999 } // Name.Builtin.Pseudo - .vc { color: #008080 } // Name.Variable.Class - .vg { color: #008080 } // Name.Variable.Global - .vi { color: #008080 } // Name.Variable.Instance - .il { color: #099 } // Literal.Number.Integer.Long -} diff --git a/about.md b/about.md deleted file mode 100644 index 1e36137..0000000 --- a/about.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -layout: page -title: About -permalink: /about/ ---- - -utPLSQL is a very versatile open source unit testing framework for Oracle PL/SQL. - -It allow for automated testing of: - -* Packages -* Functions -* Procedures -* Anything that can be execute or observed in PL/SQL such as: - * Table Default Values - * Table Triggers - * View Triggers - * Objects - - -utPLSQL was originally developed by [Steven Feuerstein](http://stevenfeuerstein.com/) and is now maintained by active team of developers. - -Feel free to [try it out](/downloads) you won't regret it. Additional information can be found in the [documentation](/documentation) diff --git a/contributing.md b/contributing.md deleted file mode 100644 index 14cbc64..0000000 --- a/contributing.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -layout: page -title: Contributing -permalink: /contributing/ ---- - -utPLSQL project team is always willing to work with the community. - -- Feel free post [bugs or issues](https://github.com/utPLSQL/utPLSQL/issues). We also have discussions in the issues feel to to post questions there. -- Join developers the [utPLSQL team](http://utplsql-slack-invite.herokuapp.com) on [Slack](https://slack.com/) -- Contribute to and learn from the [wiki](https://github.com/utPLSQL/utPLSQL/wiki). -- [Make and submit changes](https://github.com/utPLSQL/utPLSQL/blob/master/CONTRIBUTING.md) to the code base. - -You can find the source code for the utpsql on GitHub: -{% include icon-github.html username="utplsql" %} diff --git a/css/main.scss b/css/main.scss deleted file mode 100644 index 64c8146..0000000 --- a/css/main.scss +++ /dev/null @@ -1,59 +0,0 @@ ---- -# Only the main Sass file needs front matter (the dashes are enough) ---- -@charset "utf-8"; - - - -// Our variables -$base-font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; -$base-font-size: 16px; -$base-font-weight: 400; -$small-font-size: $base-font-size * 0.875; -$base-line-height: 1.5; - -$spacing-unit: 30px; - -$text-color: #111; -$background-color: #fdfdfd; -$brand-color: #2a7ae2; - -$grey-color: #828282; -$grey-color-light: lighten($grey-color, 40%); -$grey-color-dark: darken($grey-color, 25%); - -$violet-color: #800080; -$white-color: #FFFFFF; - -$header-background: $violet-color; -$header-text: $white-color; - -// Width of the content area -$content-width: 800px; - -$on-palm: 600px; -$on-laptop: 800px; - - - -// Use media queries like this: -// @include media-query($on-palm) { -// .wrapper { -// padding-right: $spacing-unit / 2; -// padding-left: $spacing-unit / 2; -// } -// } -@mixin media-query($device) { - @media screen and (max-width: $device) { - @content; - } -} - - - -// Import partials from `sass_dir` (defaults to `_sass`) -@import - "base", - "layout", - "syntax-highlighting" -; diff --git a/docs/CNAME b/docs/CNAME new file mode 100644 index 0000000..c9c61f1 --- /dev/null +++ b/docs/CNAME @@ -0,0 +1 @@ +www.utplsql.org \ No newline at end of file diff --git a/docs/about.md b/docs/about.md new file mode 100644 index 0000000..4257cfd --- /dev/null +++ b/docs/about.md @@ -0,0 +1,71 @@ +--- +layout: page +title: About +permalink: /about/ +menuInclude: true +--- + +{% + include-markdown "https://raw.githubusercontent.com/utPLSQL/.github/main/profile/README.md" + rewrite-relative-urls=true + start="" + end="" +%} + + +## History + +### Framework history + +While the framework exists since 1999, +the current version is a consequence of a complete rewrite done in 2016 by passionate developers, +using the object-oriented capabilities of the Oracle database to make it more aligned with other testing frameworks (e.g. JUnit for Java, RSpec for Ruby). + +This had significant impact on the test code syntax and how the framework is used. + + +### Major Contributors + + +| Name | GitHub | Comments | +|-------------------------------------------------------------------|-----------------------------------------------|-----------------------------------------------------------------------------------------------------| +| [Jacek Gebal](https://twitter.com/GebalJacek/) | [jgebal](https://github.com/jgebal) | Project lead, admin, core PL/SQL framework, pipelines, expectations, reporters, annotations, cache | +| [Pavel Kaplya](https://twitter.com/Pazus) | [Pazus](https://github.com/Pazus) | Core PL/SQL framework, design, annotations | +| [Lukasz Wasylow](https://twitter.com/Baalowy) | [lwasylow](https://github.com/lwasylow/) | Core PL/SQL framework, demo project | +| [Samuel Nitsche](https://twitter.com/Der_Pesse) | [pesse](https://github.com/pesse/) | utPLSQL-java-api, utPLSQL-cli | +| [Philipp Salvisberg](https://twitter.com/phsalvisberg) | | utPLSQL-SQLDeveloper-extension | +| [Simon Martinelli](https://www.linkedin.com/in/simonmartinelli/) | | utPLSQL-PLSQL-Developer plugin, utPLSQL-cli | +| [Vinicius Avellar](https://twitter.com/mrvmoreira) | [viniciusam](https://github.com/viniciusam/) | utPLSQL-java-api, maven-plugin, utPLSQL-cli | +| Robert Love | [rlove](https://github.com/rlove) | | +| David Pyke | [Shoelace](https://github.com/Shoelace) | | + + +Many thanks to [all contributors](https://github.com/utPLSQL/utPLSQL/graphs/contributors) across utPLSQL projects. + + +### Prior versions creators + +| Name | Comments | +| -------------------------------------------------- | ---------------- | +| [Steven Feuerstein](http://stevenfeuerstein.com/) | Original Author | +| Chris Rimmer | | +| Patrick Barel | | +| Paul Walker | | + + +## Supporters + +The utPLSQL project is community-driven and is not commercially motivated. Nonetheless, donations and other contributions are always welcome, and are detailed below. + +### Active supporters + +There are currently no active supporters. If your company would like to support the project, please reach out on +[GitHub Discussions](https://github.com/utPLSQL/utPLSQL/discussions). + +### Past supporters + + +| Supporter | Details | +|--------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------| +| [![supported_by_redgate](assets/supported_by_redgate_100.png)](https://www.red-gate.com/hub/events/open-source-projects) | In 2019, Redgate supported utPLSQL by sponsoring stickers and t-shirts | + diff --git a/docs/admin.html b/docs/admin.html deleted file mode 100644 index 23edfa0..0000000 --- a/docs/admin.html +++ /dev/null @@ -1,254 +0,0 @@ - - - - - - - - - - - Administrative Topics - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: The Four Step Program to using utPLSQL | Next Section: Build Test Packages >

- - -

Administrative Topics

- -

Configuring UTL_FILE

- -

Join the Project Team

- -

Reporting Bugs and Enhancement Requests

- -

Administrative Topics

- -

Configuring UTL_FILE

-

- If you want utPLSQL to automatically recompile your test packages, you - will need to make sure that UTL_FILE is enabled in your database (this - allows you to read/write operating system files). The database initialization - parameter file (aka, the "init.ora" file) must have at least one utl_file_dir - parameter in it for this to work. Here is some background and guidelines - for working with UTL_FILE: -

-

- UTL_FILE lets you read and write files accessible from the server on - which your database is running. So, theoretically, you could use UTL_FILE - to write right over your tablespace data files, control files and so on. - That is, of course, a very bad idea. Server security requires the ability - to place restrictions on where you can read and write your files. -

-

- UTL_FILE implements this security by limiting access to files that reside - in one of the directories specified in the init.ora file (parameter initialization - file) for the database instance on which UTL_FILE is running. -

-

- When you call UTL_FILE.FOPEN to open a file, you must specify both the - location and the name of the file, in separate arguments. This file location - is then checked against the list of accessible directories. -

-

- The format of the parameter for file access in the init.ora file is: -

-
-utl_file_dir = <directory>
-
-

- Include a parameter for utl_file_dir for each directory you want to make - accessible for UTL_FILE operations. The following entries, for example, - enable four different directories in Unix: -

- -
-utl_file_dir = /tmp
-utl_file_dir = /ora_apps/hr/time_reporting
-utl_file_dir = /ora_apps/hr/time_reporting/log
-utl_file_dir = /users/test_area
-
- -

- To bypass server security and allow read/write access to all directories, - you can use this special syntax: -

- -
-utl_file_dir = *
-
- -

- You should not use this option on production systems. In a development - system, this entry certainly makes it easier for developers to get up and - running on UTL_FILE and test their code. You should, however, only allow - access to a few specific directories when you move the application to production. -

-

Some observations on working with and setting up accessible directories with UTL_FILE:

-

- Access is not recursive through subdirectories. If the following lines - were in your init.ora file, for example, -

- -
-utl_file_dir = c:\group\dev1
-utl_file_dir = c:\group\prod\oe
-utl_file_dir = c:\group\prod\ar
-
- -

- then you would not be able to open a file in the c:\group\prod\oe\reports - subdirectory. -

-

- Do not include the following entry in Unix systems: -

- -
-utl_file_dir = .
-
- -

- This would allow you to read/write on the current directory in the operating - system. -

-

- Do not enclose the directory names within single or double quotes. -

-

- In the UNIX environment, a file created by UTL_FILE.FOPEN has as its - owner the shadow process running the Oracle instance. This is usually the - oracle owner. If you try to access these files outside of UTL_FILE, you - will need to have the correct privileges (or be logged in as oracle) to - access or change these files. -

-

- You should not end your directory name with a delimiter, such as the - forward slash in Unix. The following specification of a directory will - result in problems when trying to read from or write to the directory: -

- -
-utl_file_dir = /tmp/orafiles/
-
- -

- After you modify your parameter initialization file, you will need to stop - and then restart your database instance. -

-

Test UTL_FILE Access

-

- If you have never before used or relied on UTL_FILE, you should write - a simple test to verify that UTL_FILE is now working. You can use the code - shown below (after changing your directory names and names for existing - and new files) to make sure you've got it running properly. -

- -
-SET SERVEROUTPUT ON
-
-DECLARE
-   fid UTL_FILE.FILE_TYPE;
-   v VARCHAR2(32767);
-   PROCEDURE recNgo (str IN VARCHAR2)
-   IS
-   BEGIN
-      DBMS_OUTPUT.PUT_LINE ('UTL_FILE error ' || str);
-
-      UTL_FILE.FCLOSE (fid);
-   END;
-BEGIN
-   /* Change the directory name to one to which you at least 
-   || THINK you have read/write access.
-   */
-   fid := UTL_FILE.FOPEN ('e:\demo', 'existing_file', 'R');
-   UTL_FILE.GET_LINE (fid, v);
-   dbms_output.put_line (v);
-
-   UTL_FILE.FCLOSE (fid);
-
-   fid := UTL_FILE.FOPEN ('e:\demo', 'new_file', 'W');
-
-   UTL_FILE.PUT_LINE (fid, v);
-
-   UTL_FILE.FCLOSE (fid);
-EXCEPTION
-   WHEN UTL_FILE.INVALID_PATH
-      THEN recNgo ('invalid_path');
-   WHEN UTL_FILE.INVALID_MODE
-      THEN recNgo ('invalid_mode');
-   WHEN UTL_FILE.INVALID_FILEHANDLE
-      THEN recNgo ('invalid_filehandle');
-   WHEN UTL_FILE.INVALID_OPERATION
-      THEN recNgo ('invalid_operation');
-   WHEN UTL_FILE.READ_ERROR
-      THEN recNgo ('read_error');
-   WHEN UTL_FILE.WRITE_ERROR
-      THEN recNgo ('write_error');
-   WHEN UTL_FILE.INTERNAL_ERROR
-      THEN recNgo ('internal_error');
-END;
-/
-
-

- If an error occurs, it will be displayed on your screen (note: the "set - serveroutput on" is not required for UTL_FILE to work, but simply to display - any errors which might occur). -

- -

Join the utPLSQL Project Team

- -

- To take part in the utPLSQL project, have a look round the - utPLSQL project site, - in particular the CONTRIBUTING.md - and issues tracker. - Once you are up to speed on the project, you can choose a issue and begin to contribute. -

- -

Reporting Bugs and Enhancement Requests

- -

- To identify the version of utPLSQL you are running, - you can execute the following program in SQL*Plus: -

- -
-SQL> set serveroutput on
-SQL> exec dbms_output.put_line (utPLSQL.version)
-
- -

- You can also look inside the utPLSQL package (utPLSQL.pkb) - and check the value of the g_version private variable. -

- - -

< Previous Section: The Four Step Program to using utPLSQL | Next Section: Build Test Packages >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/announcements/index.md b/docs/announcements/index.md new file mode 100644 index 0000000..a7a6c48 --- /dev/null +++ b/docs/announcements/index.md @@ -0,0 +1 @@ +# Announcements diff --git a/_posts/2016-06-20-welcome-to-new-website.md b/docs/announcements/posts/2016-06-20-welcome-to-new-website.md similarity index 90% rename from _posts/2016-06-20-welcome-to-new-website.md rename to docs/announcements/posts/2016-06-20-welcome-to-new-website.md index c588d4c..cd3ed50 100644 --- a/_posts/2016-06-20-welcome-to-new-website.md +++ b/docs/announcements/posts/2016-06-20-welcome-to-new-website.md @@ -1,8 +1,10 @@ --- layout: post title: "Welcome to new web site" -date: 2016-06-20 15:00:00 -0600 -categories: moving +date: + created: 2016-06-20 +categories: + - "version2-moving" --- Welcome to the new utPLSQL website. We are still in the early stages of moving to GitHub. diff --git a/_posts/2016-06-24-documentation-now-hosted.md b/docs/announcements/posts/2016-06-24-documentation-now-hosted.md similarity index 86% rename from _posts/2016-06-24-documentation-now-hosted.md rename to docs/announcements/posts/2016-06-24-documentation-now-hosted.md index ac14ece..d273242 100644 --- a/_posts/2016-06-24-documentation-now-hosted.md +++ b/docs/announcements/posts/2016-06-24-documentation-now-hosted.md @@ -1,8 +1,10 @@ --- layout: post title: "Documentation is now hosted." -date: 2016-06-24 10:00:00 -0600 -categories: moving +date: + created: 2016-06-24 +categories: + - "version2-moving" --- [Issue #19](https://github.com/utPLSQL/utPLSQL/issues/19) to link documentation to the website has been completed. diff --git a/_posts/2016-07-07-version-2-3-1-released.md b/docs/announcements/posts/2016-07-07-version-2-3-1-released.md similarity index 83% rename from _posts/2016-07-07-version-2-3-1-released.md rename to docs/announcements/posts/2016-07-07-version-2-3-1-released.md index d4fa4ef..c95098d 100644 --- a/_posts/2016-07-07-version-2-3-1-released.md +++ b/docs/announcements/posts/2016-07-07-version-2-3-1-released.md @@ -1,8 +1,10 @@ --- layout: post title: "Version 2.3.1 has been released." -date: 2016-07-07 10:00:00 -0600 -categories: moving +date: + created: 2016-07-07 +categories: + - "version2-moving" --- [Version 2.3.1](https://github.com/utPLSQL/utPLSQL/releases/tag/utplsql-2-3-1) has been released. diff --git a/_posts/2016-10-10-Version3-pre-alpha.md b/docs/announcements/posts/2016-10-10-Version3-pre-alpha.md similarity index 77% rename from _posts/2016-10-10-Version3-pre-alpha.md rename to docs/announcements/posts/2016-10-10-Version3-pre-alpha.md index 35e2ce9..78fd3a4 100644 --- a/_posts/2016-10-10-Version3-pre-alpha.md +++ b/docs/announcements/posts/2016-10-10-Version3-pre-alpha.md @@ -1,8 +1,11 @@ --- layout: post title: "Version 3 - pre-alpha" -date: 2016-10-10 11:00:00 -0600 -categories: version3 +date: + created: 2016-10-10 +categories: + - "releases" + - "utplsql-core" --- Version 3 in pre-alpha state @@ -12,7 +15,5 @@ Nearly every day version 3 has commits to repository with multiple developers co It won't be long until we are in an alpha status. If your interested in following along or helping out with the project check out the [version 3 readme.md](https://github.com/utPLSQL/utPLSQL/blob/version3/readme.md) -Feel free to join us in our [slack chat room](http://utplsql-slack-invite.herokuapp.com/) where we communicate daily about the project. - We welcome support requests and discussions, feature requests, and bug reports in the [GitHub issues log](https://github.com/utPLSQL/utPLSQL/issues). \ No newline at end of file diff --git a/_posts/2017-01-17-Version3.0.0.0-Alpha1.md b/docs/announcements/posts/2017-01-17-Version3.0.0.0-Alpha1.md similarity index 73% rename from _posts/2017-01-17-Version3.0.0.0-Alpha1.md rename to docs/announcements/posts/2017-01-17-Version3.0.0.0-Alpha1.md index 4a23670..743c71f 100644 --- a/_posts/2017-01-17-Version3.0.0.0-Alpha1.md +++ b/docs/announcements/posts/2017-01-17-Version3.0.0.0-Alpha1.md @@ -1,8 +1,11 @@ --- layout: post title: "Version 3.0.0.0-Alpha1 released" -date: 2017-01-17 18:00:00 -0600 -categories: version3 +date: + created: 2017-01-17 +categories: + - "releases" + - "utplsql-core" --- Version 3 has reached alpha state. @@ -11,7 +14,5 @@ It can be downloaded from the [releases page.](https://github.com/utPLSQL/utPLSQ It's being used now in multiple organizations with great success. The documentation work is progressing. However, we realize that quite a bit of work needs to be done in this area. -Feel free to join us in our [slack chat room](http://utplsql-slack-invite.herokuapp.com/) where we communicate daily about the project. - We welcome support requests and discussions, feature requests, and bug reports in the [GitHub issues log](https://github.com/utPLSQL/utPLSQL/issues). diff --git a/_posts/2017-04-01-Version3Beta1.md b/docs/announcements/posts/2017-04-01-Version3Beta1.md similarity index 75% rename from _posts/2017-04-01-Version3Beta1.md rename to docs/announcements/posts/2017-04-01-Version3Beta1.md index 16f9fe1..3efcdf4 100644 --- a/_posts/2017-04-01-Version3Beta1.md +++ b/docs/announcements/posts/2017-04-01-Version3Beta1.md @@ -1,8 +1,11 @@ --- layout: post title: "Version v3.0.0-beta has been released" -date: 2017-04-01 12:00:00 -0600 -categories: version3 +date: + created: 2017-04-01 +categories: + - "releases" + - "utplsql-core" --- @@ -12,8 +15,6 @@ It can be downloaded from the [releases page.](https://github.com/utPLSQL/utPLSQ It's being used now in multiple organizations with great success. The documentation work is progressing. However, we realize that quite a bit of work needs to be done in this area. -Feel free to join us in our [slack chat room](http://utplsql-slack-invite.herokuapp.com/) where we communicate daily about the project. - We welcome support requests and discussions, feature requests, and bug reports in the [GitHub issues log](https://github.com/utPLSQL/utPLSQL/issues). This is not an April Fools Day Joke, we really release it. diff --git a/_posts/2017-05-18-version3.0.0-released.md b/docs/announcements/posts/2017-05-18-version3.0.0-released.md similarity index 93% rename from _posts/2017-05-18-version3.0.0-released.md rename to docs/announcements/posts/2017-05-18-version3.0.0-released.md index be3bd2b..4598abe 100644 --- a/_posts/2017-05-18-version3.0.0-released.md +++ b/docs/announcements/posts/2017-05-18-version3.0.0-released.md @@ -1,8 +1,11 @@ --- layout: post title: "utPLSQL v3.0.0 - released!" -date: 2017-05-18 06:52:00 +0000 -categories: version3 +date: + created: 2017-05-18 +categories: + - "releases" + - "utplsql-core" --- diff --git a/_posts/2017-06-14-version3.0.1-released.md b/docs/announcements/posts/2017-06-14-version3.0.1-released.md similarity index 90% rename from _posts/2017-06-14-version3.0.1-released.md rename to docs/announcements/posts/2017-06-14-version3.0.1-released.md index c6dffb7..c21ac6c 100644 --- a/_posts/2017-06-14-version3.0.1-released.md +++ b/docs/announcements/posts/2017-06-14-version3.0.1-released.md @@ -1,8 +1,12 @@ --- layout: post title: "utPLSQL v3.0.1 - released" -date: 2017-06-14 23:05:00 +0000 -categories: version3 +date: + created: 2017-06-14 +categories: + - "releases" + - "utplsql-core" + --- diff --git a/_posts/2017-07-18-version3.0.2-released.md b/docs/announcements/posts/2017-07-18-version3.0.2-released.md similarity index 95% rename from _posts/2017-07-18-version3.0.2-released.md rename to docs/announcements/posts/2017-07-18-version3.0.2-released.md index 72834bd..d4808a8 100644 --- a/_posts/2017-07-18-version3.0.2-released.md +++ b/docs/announcements/posts/2017-07-18-version3.0.2-released.md @@ -1,8 +1,12 @@ --- layout: post title: "utPLSQL v3.0.2 - released" -date: 2017-07-18 19:45:00 +0000 -categories: version3 +date: + created: 2017-07-18 +categories: + - "releases" + - "utplsql-core" + --- diff --git a/docs/announcements/posts/2017-08-30-version3.0.3-released.md b/docs/announcements/posts/2017-08-30-version3.0.3-released.md new file mode 100644 index 0000000..48c4b65 --- /dev/null +++ b/docs/announcements/posts/2017-08-30-version3.0.3-released.md @@ -0,0 +1,49 @@ +--- +layout: post +title: "utPLSQL v3.0.3 - released" +date: + created: 2017-08-30 +categories: + - "releases" + - "utplsql-core" + +--- + + +# Changes in this release + +## New features + +- Added ability to exclude columns/attributes for cursor/object/collection comparison. Xpath can be used for column/attribute exclusion +- Added reporting to module, action, client_info fields of the v$session. +- Calling ut_runner.run procedures can now raise exception if any test failed +- Added ability to check version compatibility ut_runner.version_compatibility_check + +## Improvements and fixes + +- Fixed bug with framework executing multiple packages with similar names when using suitepaths +- Cursor comparison now supports cursors on Global Temporary Table +- Increased allowed chars for annotation name to 250 +- Cursor comparison now supports cursors with more than 1000 rows +- dba_ views are now used (if available), increasing performance of the framework +- Changed how version number reporting in functions ut_runner.version, ut_run.version +- Improved warning message when implicit commit occurs +- Fixed Sonar Unit Test reporting for test suites with suitepth +- Fixed problem with identifying annotations when windows newline is used in package sources + +## Documentation fixes + +- Moved CONTRIBUTING.md to project root and updated content +- Fixed coverage format documentation +- Small documentation fixes + +## Internal improvements + +- Added self-testing using released version of utPLSQL +- Sonar reporting disabled for PRs +- Moved to project-owned Docker images created by scripts from utPLSQL/docker-scripts project +- Added source_path and test_path parameters for coverage reporters +- Changed the way ut_file_mapper handles default parameters +- Improved performance and stability of access to internal framework tables +- Updated myStats library to v3 +- ut_output_buffer is now abstracted from caller diff --git a/docs/announcements/posts/2017-11-03-version3.0.4-released.md b/docs/announcements/posts/2017-11-03-version3.0.4-released.md new file mode 100644 index 0000000..bb5e1ab --- /dev/null +++ b/docs/announcements/posts/2017-11-03-version3.0.4-released.md @@ -0,0 +1,30 @@ +--- +layout: post +title: "utPLSQL v3.0.4 - released" +date: + created: 2017-11-03 +categories: + - "releases" + - "utplsql-core" + +--- + + +# Changes in [this release](https://github.com/utPLSQL/utPLSQL/releases/tag/v3.0.4) + +## Improvements and fixes + +- Removed overloaded procedures `ut_runner.run` +- utPLSQL will not not open new transaction when running tests +- Added buffering of dbms_output before the run +- Removed `ut_expectation` sub-types +- Restructured annotations and added caching to improve framework start-up time +- Savepoint name is now generated from sys_guid to avoid issues on Windows-based Oracle instances +- Fixed XML/HTML special characters in reporters +- Unified handling of failure reporting across reporters + +## Documentation fixes + +- Fixed link to contributing guide in the doc +- Added example of handling exceptions to documentation +- Added example for custom expectation-fail message in docs diff --git a/docs/announcements/posts/2017-11-23-cli-version3.0.4-released.md b/docs/announcements/posts/2017-11-23-cli-version3.0.4-released.md new file mode 100644 index 0000000..90e94e4 --- /dev/null +++ b/docs/announcements/posts/2017-11-23-cli-version3.0.4-released.md @@ -0,0 +1,41 @@ +--- +layout: post +title: "We've released utPLSQL-cli" +date: + created: 2017-11-22 +categories: + - "releases" + - "utplsql-core" + +--- + + +First official release of command line client for utPLSQL. +------------------------------------ + +You may find the client on the [download page](https://github.com/utPLSQL/utPLSQL-cli/releases/tag/v3.0.4) + +### Requirements + +- [Java8](http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html) +- Oracle JDBC driver file (ojdbc8.jar) is required +- Oracle i18n driver file (orai18n.jar) is required for national character-set support + +Both driver files need to be [downloaded](http://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html) and placed in `utPLSQL-cli/lib` folder + +### Key features + +- connectivity to Oracle database without Oracle client software (needs JDBC driver) +- support for multiple reporters and multiple output files +- real-time reporting to screen (depends on reporter implementation) +- documentation reporting in color +- mapping of project files to database objects (needed for Sonar reporting) +- support for customized project file-mapping rules + +### Supported utPLSQL versions + +- utPLSQL v3.0.0 +- utPLSQL v3.0.1 +- utPLSQL v3.0.2 +- utPLSQL v3.0.3 +- utPLSQL v3.0.4 diff --git a/docs/announcements/posts/2018-03-29-cli-version3.1.0-released.md b/docs/announcements/posts/2018-03-29-cli-version3.1.0-released.md new file mode 100644 index 0000000..897f30c --- /dev/null +++ b/docs/announcements/posts/2018-03-29-cli-version3.1.0-released.md @@ -0,0 +1,45 @@ +--- +layout: post +title: "utPLSQL-cli v3.1.0 released" +date: + created: 2018-03-29 +categories: + - "releases" + - "utplsql-core" + +--- + + +utPLSQL-cli v3.1.0 released +------------------------------------ + +[Release download page](https://github.com/utPLSQL/utPLSQL-cli/releases/tag/v3.1.0) +[Readme](https://github.com/utPLSQL/utPLSQL-cli/blob/v3.1.0/README.md) + +### Requirements + +- [Java8](http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html) +- Oracle JDBC driver file (ojdbc8.jar) is required +- Oracle i18n driver file (orai18n.jar) is required for national character-set support + +Both driver files need to be [downloaded](http://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html) and placed in `utPLSQL-cli/lib` folder + + +### Compatibility + +This version of java-api is compatible with all versions of utPLSQL from 3.0.0 to 3.1.0. +We encourage you to always use the latest version of cli to communicate with a v3 core. + +### Changes in this release + +*Enhancements* +- Support for custom reporters. Just call utplsql run user/pass@connstr -f=my_custom_reporter and cli will try to use a database-reporter with the given name +- Assets necessary for CoverageHTMLReporter are written to $outputFileName-assets folder ([utPLSQL/utPLSQL-java-api#39](https://github.com/utPLSQL/utPLSQL-java-api/issues/39)) +- Realtime-Feedback: Output to screen is immediate, output to files is in bulks ([#68](https://github.com/utPLSQL/utPLSQL-cli/issues/68)) +- NLS-Support from environment ([#56](https://github.com/utPLSQL/utPLSQL-cli/issues/56)) + +*Bugfixes* +- The correct usage is now stated in help message ([#63](https://github.com/utPLSQL/utPLSQL-cli/issues/63)) +- Several small improvements + +For more info on improvements and fixes, check out the [blog post from Samuel Nitsche](https://cleandatabase.wordpress.com/2018/03/29/open-source-engagement-for-utplsql/) diff --git a/docs/announcements/posts/2018-07-20-version3.1.1-delayed_announcement.md b/docs/announcements/posts/2018-07-20-version3.1.1-delayed_announcement.md new file mode 100644 index 0000000..d908302 --- /dev/null +++ b/docs/announcements/posts/2018-07-20-version3.1.1-delayed_announcement.md @@ -0,0 +1,81 @@ +--- +layout: post +title: "Better late than never" +date: + created: 2018-07-20 +categories: + - "releases" + - "utplsql-core" + +--- + + +# Announcing utPLSQL 3.1.0 and 3.1.1 + + +On April 25th, a major release 3.1.0 of utPLSQL was published on github and the information was not published on our site. + +Right after the release two issues were found resulting in bug fixes and release 3.1.1 + +## Version 3.1.1 bug-fixes +- Block coverage reporting doesn't work on schema other than framework owner ([https://github.com/utPLSQL/utPLSQL/issues/653](#653)) +- Reporter threads timeout and do not produce outputs when running with `utplsql-cli` and idle time exceeds 1 minute ([https://github.com/utPLSQL/utPLSQL/issues/652](#652)) + +[Release 3.1.1 download page](https://github.com/utPLSQL/utPLSQL/releases/tag/v3.1.1) + + +## Version 3.1.0 release notes + +**Important Notice** +> **Starting with this release, `utPLSQL-sql-cli` is no longer supported.** +> **Use [`utPLSQL-cli` release 3.1.0](https://github.com/utPLSQL/utPLSQL-cli/releases) or above to interact with this and upcoming versions of utPLSQL.** + +### Enhancements + +#### Reporting +* Added support for extended block coverage on Oracle 12.2 and above. Coverage reporters will now indicate partly covered lines (where applicable by coverage format). +* Added new `ut_tfs_junit_reporter` for MS Team Foundation Server to support old JUnit xml format +* Added new [coverage reporter](https://github.com/utPLSQL/utPLSQL/blob/develop/docs/userguide/coverage.md) `ut_coverage_cobertura_reporter` +* Fixed compatibility issues with `ut_xunit_reporter`. The reporter now conforms to the format specification. +* Added `ut_junit_reporter` as a base for `ut_xunit_reporter`. The `ut_xunit_reporter` remains active for backward compatibility but is considered depreciated +* Added reporting of differences when comparing cursors, oracle object and table types +* Aligned `ut_documentation_reporter` to display tests annotated`--%disabled` as `DISABLED` +* Added support for reporters that don't provide output to the API (reporters saving data to DB) +* Improved API so that it's possible to support custom reporters from `utPLSQL-java-api` without code changes + +#### Annotations +* added [`throws` annotation](https://github.com/utPLSQL/utPLSQL/blob/develop/docs/userguide/annotations.md#throws) to simplify writing tests for code that throws an exception +* added [`context`](https://github.com/utPLSQL/utPLSQL/blob/develop/docs/userguide/annotations.md#context) to enable grouping of tests into sub-suite in a test suite package +* added warnings on invalid/misplaced annotations +* added support for multiple declarations of before/after procedures +* added propagation of rollback type defined on parent suite within suitepath + +#### Expectations +* Added [`have_count` matcher](https://github.com/utPLSQL/utPLSQL/blob/develop/docs/userguide/expectations.md#have_count) for checking cursor rows/collection elements count +* Added [`include()` and `exclude()` extensions](https://github.com/utPLSQL/utPLSQL/blob/develop/docs/userguide/advanced_data_comparison.md#excluding-elements-from-data-comparison) to cursor and object/collection data comparison +* Added [`diff` functionality](https://github.com/utPLSQL/utPLSQL/blob/develop/docs/userguide/expectations.md#diff-functionality-for-compound-data-types) for cursor, object and collection data +* When comparing cursors, column data-type is now also checked for equality +* Changed behavior of execution of `ut.expect()` on closed cursor ([#548](https://github.com/utPLSQL/utPLSQL/issues/548)) +* Added support for cursors with implicitly named columns + +#### General improvements +* Output buffer for reporting is now reporter-agnostic. +* cli is no longer not interacting with output buffer but uses reporters to retrieve data instead. +* Added ability to mark expectation syntax as deprecated and report warnings on deprecation +* Added ability to get a list of annotations for a schema +* Refactoring of annotation parsing +* Refactoring of suite building +* Migrated part of old script-based tests to new utPLSQL v3 tests +* Documentation fixes and improvements +* Reporters now provide a method to get description +* Test execution continues even when encountered `Existing state of packages was discarded/invalidated` exceptions (`ORA-04068`/`ORA-04061`). The whole suite will execute, test result reports will be available and the exception will be re-thrown to the user after the run was finished. ([#504](https://github.com/utPLSQL/utPLSQL/issues/504)) + +### Bug-fixes +* Coverage schema had to be explicitly provided, even when using `a_include_objects` ([#511](https://github.com/utPLSQL/utPLSQL/issues/511)) +* utPLSQL fails to run, when one of suite packages has no newline between `--%suite` and procedure-specific annotations. ([#514](https://github.com/utPLSQL/utPLSQL/issues/514) / [#516](https://github.com/utPLSQL/utPLSQL/issues/516)) +* Fixed false-negative code coverage reporting on labelled `end loop ` elements ([#539](https://github.com/utPLSQL/utPLSQL/issues/539)) +* Fixed issue with invalid suite grouping when running `xunit_reporter` ([#547](https://github.com/utPLSQL/utPLSQL/issues/547)) +* Code coverage was always showing first report gathered in a session ([#562](https://github.com/utPLSQL/utPLSQL/issues/562)) +* Wrong format of time in XUnit_reporter when running on German locale (using comma as decimal separator) ([#572](https://github.com/utPLSQL/utPLSQL/issues/572)) +* Fixed issue with wrong exception getting thrown when suite failed and there was a pending distributed transaction ([#601](https://github.com/utPLSQL/utPLSQL/issues/601)) +* Fixed file-mapper issue where two files were mapped into the same object and caused `ORA-00001: unique constraint (UTP3.UT_COVERAGE_SOURCES_TMP_PK) violated` ([#568](https://github.com/utPLSQL/utPLSQL/issues/568)) diff --git a/docs/announcements/posts/2018-07-22-version3.1.2-released.md b/docs/announcements/posts/2018-07-22-version3.1.2-released.md new file mode 100644 index 0000000..c1d0ea0 --- /dev/null +++ b/docs/announcements/posts/2018-07-22-version3.1.2-released.md @@ -0,0 +1,51 @@ +--- +layout: post +title: "utPLSQL v3.1.2 released" +date: + created: 2018-07-21 +categories: + - "releases" + - "utplsql-core" + +--- + +# Changes in release 3.1.2 + +## New features + +- Added ability to join and compare cursor content by specific columns (PK/UK) ([#453](https://github.com/utPLSQL/utPLSQL/issues/453)) +- Added support for comma separated list of suite paths/packages when calling `ut.run` ([#479](https://github.com/utPLSQL/utPLSQL/issues/479)) +- Added ability to run a test package that got invalidated due to dependency invalidation ([#489](https://github.com/utPLSQL/utPLSQL/issues/489)) +- Added support for package level constants and predefined exceptions in `--%throws` annotation ([#685](https://github.com/utPLSQL/utPLSQL/issues/685)) +- Added support for standalone `--%beforeall`, `--%beforeeach`, `--%afterall`, `--%aftereach` annotations with list of procedures to execute ([#649](https://github.com/utPLSQL/utPLSQL/issues/649)) +- Added support for list of procedure names in before/after annotations ([#649](https://github.com/utPLSQL/utPLSQL/issues/649)) +- Added support for BLOB/CLOB in `is_empty()` matcher ([#707](https://github.com/utPLSQL/utPLSQL/issues/707)) + + +## Enchancements + +- utPLSQL will now provide additional warnings, when unsupported annotations are found in a unit test suite package ([#624](https://github.com/utPLSQL/utPLSQL/issues/624)) +- utPLSQL will now produce valid XML in UT_JUNIT_REPORTER when dbms_output or test results contain ` You can take advantage of our efforts and build your own small Docker images (non-PDB) using our [docker-scripts](https://github.com/utPLSQL/docker-scripts). + +# Continuous testing of utPLSQL + +utPLSQL is now getting tested against *five* database versions: +- Oracle 11g XE +- Oracle 12c R1 +- Oracle 12c R2 +- Oracle 18c +- Oracle 19c + +You can see our build process & test results on [travis-ci.org/utPLSQL](https://travis-ci.org/utPLSQL) + +All of our deliverable projects use set of tools that are free to sue for Open-Source: +- static code analysis using [sonarcloud](https://sonarcloud.io/organizations/utplsql/projects) +- publishing code coverage using [coveralls](https://coveralls.io/github/utPLSQL/utPLSQL) +- deploying java-api artifacts to [packagecloud](https://packagecloud.io/utPLSQL/utPLSQL-java-api) +- deploying utPLSQL-cli artifacts to [bintray](https://bintray.com/utplsql/utPLSQL-cli/utPLSQL-cli-develop) +- maven plugin publishing into [maven repository](https://mvnrepository.com/artifact/org.utplsql/utplsql-maven-plugin) + +All of our builds must pass quality gates (code quality/tests/code coverage) before we approve and merge pull requests. + + diff --git a/docs/announcements/posts/2019-05-09-sqlcl-integration-for-utPLSQL.md b/docs/announcements/posts/2019-05-09-sqlcl-integration-for-utPLSQL.md new file mode 100644 index 0000000..99b2166 --- /dev/null +++ b/docs/announcements/posts/2019-05-09-sqlcl-integration-for-utPLSQL.md @@ -0,0 +1,27 @@ +--- +layout: post +title: "Auto-run utPLSQL tests with Oracle sqlcl" +date: + created: 2019-05-09 +categories: + - "tips-n-tricks" +--- + +Today at [#apexConn19](https://twitter.com/search?q=%23apexConn19&src=typd). + +[Sam Nitsche](https://twitter.com/Der_Pesse) (blogger, presenter, testing & compassionate-coding advocate, utPLSQL-cli & utPLSQL-api developer) met with [Kris Rice](https://twitter.com/krisrice) (Oracle SQLDeveloper, sqlcl, ORDS rock-star, developer, advocate, presenter, mentor) + +As a result, something amazing happened. Within an hour or so, Kris created a fully functional auto-runner for utPLSQL tests within Oracle sqlcl. + + +![utPSLQL-sqlcl](../../assets/sqlcl-utplsql.jpg) + +[See for yourself](https://twitter.com/krisrice/status/1126467712211988480) + +If you want to use sqlcl to run your tests, each time you compile a package, have a look at [this script](https://github.com/krisrice/sqlcl-utplsql) for sqlcl. + + +**Huge thank you to Kris and Sam!** + +>*Amazing things can happen when right people meet at right time in right place.* + diff --git a/docs/announcements/posts/2019-06-18-version3.1.7-released.md b/docs/announcements/posts/2019-06-18-version3.1.7-released.md new file mode 100644 index 0000000..352ef50 --- /dev/null +++ b/docs/announcements/posts/2019-06-18-version3.1.7-released.md @@ -0,0 +1,53 @@ +--- +layout: post +title: "utPLSQL v3.1.7 released" +date: + created: 2019-06-18 +categories: + - "releases" + - "utplsql-core" + +--- + +- # Changes in release 3.1.7 + + ## New features + + - Added support for [comparing `json`](https://github.com/utPLSQL/utPLSQL/blob/v3.1.7/docs/userguide/expectations.md#comparing-json-objects) in Oracle 12.2 and above [#924](https://github.com/utPLSQL/utPLSQL/issues/924) + - Introduced [`tag` annotation](https://github.com/utPLSQL/utPLSQL/blob/v3.1.7/docs/userguide/annotations.md#tags) to enable tagging of tests and suites [#66](https://github.com/utPLSQL/utPLSQL/issues/66) + - Added support for [random order](https://github.com/utPLSQL/utPLSQL/blob/v3.1.7/docs/userguide/running-unit-tests.md#random-order) of test execution [#422](https://github.com/utPLSQL/utPLSQL/issues/422) + + ## Enhancements + + - Added optional [install with DDL trigger](https://github.com/utPLSQL/utPLSQL/blob/v3.1.7/docs/userguide/install.md#installation-with-ddl-trigger) to speed up framework start [#901](https://github.com/utPLSQL/utPLSQL/issues/901) + - Removed dependency on `dbms_utility.name_resolve` [#569](https://github.com/utPLSQL/utPLSQL/issues/569) [#885](https://github.com/utPLSQL/utPLSQL/issues/885) + - New output buffer table structures improving performance and addressing timeout issues [#915](https://github.com/utPLSQL/utPLSQL/issues/915) + + ## Bug fixes + + - Fixed `ut_realtime_reporter` missing warnings in test and suite output structures [#936](https://github.com/utPLSQL/utPLSQL/issues/936) + - Fixed output_buffer purging error [#934](https://github.com/utPLSQL/utPLSQL/issues/934) + - Fixed `join_by / exclude / include` invalid syntax on collection in anydata compare [#912](https://github.com/utPLSQL/utPLSQL/issues/912) + - Fixed `ut_junit_reporter` producing invalid output on failing tests with long failure message [#927](https://github.com/utPLSQL/utPLSQL/issues/927) + - Fixed `ut_sonar_test_reporter` producing invalid output on failing tests with long failure message [#925](https://github.com/utPLSQL/utPLSQL/issues/925) + - Fixed `ut_coverage_cobertura_reporter` producing wrong line breaks which breaks the xml validation against DTD [#917](https://github.com/utPLSQL/utPLSQL/issues/917) + - Fixed `exclude` option for ref cursor where column order was not resolved correctly [#911](https://github.com/utPLSQL/utPLSQL/issues/911) + - Fixed `unordered` option for ref cursor with null values [#914](https://github.com/utPLSQL/utPLSQL/issues/914) + - Fixed number precision when selecting from dual [#907](https://github.com/utPLSQL/utPLSQL/issues/907) + - Fixed ref cursor errors with generated column names [#902](https://github.com/utPLSQL/utPLSQL/issues/902) + - Fixed `ORA-00907` when comparing ref cursors with BINARY_ columns [#899](https://github.com/utPLSQL/utPLSQL/issues/899) + - Fixed wrong results when comparing CLOBs with `to_be_like` in Oracle Database 11.2.0.4 due to Oracle Bug 14402514 [#891](https://github.com/utPLSQL/utPLSQL/issues/891) + - Fixed performance issue with code coverage report on huge PL/SQL code base [#882](https://github.com/utPLSQL/utPLSQL/issues/882) + + ## Documentation improvements + + - Added install instructions for DDL trigger [#874](https://github.com/utPLSQL/utPLSQL/issues/874) + + ## Internal enhancements + + - Fixed SQL vulnerability on all input parameters used in dynamic SQL and PL/SQL [#921](https://github.com/utPLSQL/utPLSQL/issues/921) + - Fixed message id in output buffer [#916](https://github.com/utPLSQL/utPLSQL/issues/916) + - Included 19c database in self testing [#909](https://github.com/utPLSQL/utPLSQL/issues/909) + - Introduced testing with multiple schemas and different grants [#893](https://github.com/utPLSQL/utPLSQL/issues/893) + - Fixed installation script warnings [#879](https://github.com/utPLSQL/utPLSQL/issues/879) + diff --git a/docs/announcements/posts/2019-07-12-cli-version3.1.7-released.md b/docs/announcements/posts/2019-07-12-cli-version3.1.7-released.md new file mode 100644 index 0000000..7f00931 --- /dev/null +++ b/docs/announcements/posts/2019-07-12-cli-version3.1.7-released.md @@ -0,0 +1,31 @@ +--- +layout: post +title: "utPLSQL-cli v3.1.7 released" +date: + created: 2019-07-12T15:00:00 +categories: + - "releases" + - "utplsql-cli" +--- + + +# Changes in release 3.1.7 + +## New Features +* CLI is now runnable from Java 8-12 (and probably also upcoming versions) +* CLI now uses Picocli instead of JCommander. __This might have some impact on how parameters are interpreted__, for example on windows machines when you define `-f=ut_documentation_reporter -o="output.txt"` you will have to enclose the "output.txt" part as shown +* Support for [Tags](https://github.com/utPLSQL/utPLSQL/blob/v3.1.7/docs/userguide/annotations.md#tags) via `--tags=tag1[,tag2[,tag3]]`parameter ([#157](https://github.com/utPLSQL/utPLSQL-cli/issues/157)) +* Support for [random order](https://github.com/utPLSQL/utPLSQL/blob/v3.1.7/docs/userguide/running-unit-tests.md#random-order) of test execution via `-r`/`--random-test-order` and `-seed`/`--random-test-order-seed` ([#139](https://github.com/utPLSQL/utPLSQL-cli/issues/139)) +* Ability to enable DBMS_OUTPUT from cli via `-D`/`--dbms_output` ([#137](https://github.com/utPLSQL/utPLSQL-cli/issues/137)) + +## Enhancements +* Completely removed HikariCP ([#158](https://github.com/utPLSQL/utPLSQL-cli/issues/158)) +* A warning is shown if `orai18n.jar` is not on the classpath. This is highly recommended due to some strange behaviour of the jdbc-driver otherwise ([#146](https://github.com/utPLSQL/utPLSQL-cli/issues/146), [#153](https://github.com/utPLSQL/utPLSQL-cli/issues/153)) + +## Bugfixes +* Type mapping (`-type_mapping`) parameter is now interpreted correctly ([#143](https://github.com/utPLSQL/utPLSQL-cli/issues/143)) + +## Internal enhancements +* Improvement of tests +* Refactoring towards immutability +* Added some more debug information \ No newline at end of file diff --git a/docs/announcements/posts/2019-07-12-java-api-version3.1.7-released.md b/docs/announcements/posts/2019-07-12-java-api-version3.1.7-released.md new file mode 100644 index 0000000..67e1c59 --- /dev/null +++ b/docs/announcements/posts/2019-07-12-java-api-version3.1.7-released.md @@ -0,0 +1,47 @@ +--- +layout: post +title: "utPLSQL-java-api v3.1.7 released" +date: + created: 2019-07-12T09:00:00 +categories: + - "releases" + - "utplsql-java-api" +--- + + +# Changes in release 3.1.7 +## Highlights + +* utPLSQL java-api now supports JDK 8-12 +* Support to call [Tags](https://github.com/utPLSQL/utPLSQL/blob/v3.1.7/docs/userguide/annotations.md#tags) +* Support for [random order](https://github.com/utPLSQL/utPLSQL/blob/v3.1.7/docs/userguide/running-unit-tests.md#random-order) of test execution + +## Changes in public API + +* `CompatibilityProxy` + * It's possible to instantiate it with an optional `assumedUtPlsql` version. This replaces the former `skipCompatibilityCheck` parameter + * Method `getDatabaseVersion` is now deprecated in favor of `getUtPlsqlVersion` and `getRealDbPlsqlVersion` +* `TestRunner` + * `getOptions` returns the current `TestRunnerOptions` now + +## Internal changes +* Added several new tests +* Several small refactorings +* Additional logging +* Preparations to completely rewrite the api + +# Download +https://packagecloud.io/utPLSQL/utPLSQL-java-api/packages/java/org.utplsql/java-api-3.1.7.jar + +## Maven +``` + + org.utplsql + java-api + 3.1.7 + +``` +## Gradle +``` +compile 'org.utplsql:java-api:3.1.7' +``` \ No newline at end of file diff --git a/docs/announcements/posts/2019-08-01-resources-section.md b/docs/announcements/posts/2019-08-01-resources-section.md new file mode 100644 index 0000000..85179a5 --- /dev/null +++ b/docs/announcements/posts/2019-08-01-resources-section.md @@ -0,0 +1,18 @@ +--- +layout: post +title: "New Resources section" +date: + created: 2019-09-04 +categories: + - "website" +--- + +# New Resources section + +We just added a new section to our website: [Resources](/resources). + +We will keep adding all kinds of examples, tutorials, videos, blog posts and other stuff related to +utPLSQL to this page, but we might not know everything. + +So please, if you find something related to utPLSQL which is publicly (without a paywall) available or if you created something +yourself, __please let us know!__ diff --git a/docs/announcements/posts/2019-09-04-version3.1.8-released.md b/docs/announcements/posts/2019-09-04-version3.1.8-released.md new file mode 100644 index 0000000..5b2e8d9 --- /dev/null +++ b/docs/announcements/posts/2019-09-04-version3.1.8-released.md @@ -0,0 +1,35 @@ +--- +layout: post +title: "utPLSQL v3.1.8 released" +date: + created: 2019-09-04 +categories: + - "releases" + - "utplsql-core" + +--- + +# Changes in release 3.1.8 + +[Download from GitHub](https://github.com/utPLSQL/utPLSQL/releases/tag/v3.1.8) + +## New features + +- Added support for [session context](https://github.com/utPLSQL/utPLSQL/blob/v3.1.8/docs/userguide/annotations.md#sys_context) to provide test and suite information during test run [#963](https://github.com/utPLSQL/utPLSQL/issues/963) [#781](https://github.com/utPLSQL/utPLSQL/issues/781) +- Added ability to [invoke expectations without running framework](https://github.com/utPLSQL/utPLSQL/blob/v3.1.8/docs/userguide/expectations.md#running-expectations-outside-utplsql-framework) [#956](https://github.com/utPLSQL/utPLSQL/issues/956) [#963](https://github.com/utPLSQL/utPLSQL/issues/963) +- Failing expectations are now reported with call stack [#967](https://github.com/utPLSQL/utPLSQL/issues/967) [#963](https://github.com/utPLSQL/utPLSQL/issues/963) + +## Enhancements + +- Improved framework table private data protection [#922](https://github.com/utPLSQL/utPLSQL/issues/922) [#954](https://github.com/utPLSQL/utPLSQL/issues/954) +- Improved install process. It is now unified for installation with both public and private synonyms [#957](https://github.com/utPLSQL/utPLSQL/issues/957) [#954](https://github.com/utPLSQL/utPLSQL/issues/954) +- Improved reporting of warnings for integration with SQLDeveloper [#964](https://github.com/utPLSQL/utPLSQL/issues/964) +- Improved query to retrieve coverage sources [#981](https://github.com/utPLSQL/utPLSQL/issues/981) [#970](https://github.com/utPLSQL/utPLSQL/issues/970) +- Improved security around malicious utPLSQL owner name [#920](https://github.com/utPLSQL/utPLSQL/issues/920) + +## Bug fixes + +- Fixed cursor comparison on Oracle 11.2 [#947](https://github.com/utPLSQL/utPLSQL/issues/947) +- Fixed issue with retrieving suite data [#977](https://github.com/utPLSQL/utPLSQL/issues/977) [#974](https://github.com/utPLSQL/utPLSQL/issues/974) [#978](https://github.com/utPLSQL/utPLSQL/issues/978) +- Application context is now reset in session after test run [#951](https://github.com/utPLSQL/utPLSQL/issues/951) + diff --git a/docs/announcements/posts/2019-11-10-version3.1.9-released.md b/docs/announcements/posts/2019-11-10-version3.1.9-released.md new file mode 100644 index 0000000..fb58e9e --- /dev/null +++ b/docs/announcements/posts/2019-11-10-version3.1.9-released.md @@ -0,0 +1,46 @@ +--- +layout: post +title: "utPLSQL v3.1.9 released" +date: + created: 2019-11-10 +categories: + - "releases" + - "utplsql-core" + +--- + +# Changes in release 3.1.9 + +## New features + +- Added ability to define [nested contexts](https://github.com/utPLSQL/utPLSQL/blob/v3.1.9/docs/userguide/annotations.md#context) within test suite [#938](https://github.com/utPLSQL/utPLSQL/issues/938) +- Added ability to [exclude tests/suites by tags](https://github.com/utPLSQL/utPLSQL/blob/v3.1.9/docs/userguide/annotations.md#excluding-testssuites-by-tags) when invoking a test-run [#1007](https://github.com/utPLSQL/utPLSQL/issues/1007) [#983](https://github.com/utPLSQL/utPLSQL/issues/983) +- Added new annotation [`--%name`](https://github.com/utPLSQL/utPLSQL/blob/v3.1.9/docs/userguide/annotations.md#name) to allow for providing custom name for contexts [#1016](https://github.com/utPLSQL/utPLSQL/issues/1016) + +## Important changes + +The value of `--%context` annotation is no longer representing context `name`. +This value is now context description (displayname). +With this change, the `--%context` annotation is now aligned with `--%test` and `--%suite` annotation syntax. + +New annotation `--%name` was introduced to facilitate naming of contexts. + + +## Enhancements + +- Improved documentation for running tests +- Improved documentation for tags [#1003](https://github.com/utPLSQL/utPLSQL/issues/1003) +- Improved documentation for annotations + +## Bug fixes + +- Fixed bug with bad stacktrace showing in failing/erroring test [#1000](https://github.com/utPLSQL/utPLSQL/issues/1000) +- Fixed issue with lack of validation for context name [#966](https://github.com/utPLSQL/utPLSQL/issues/966) +- Fixed problem with install script privilege check for installation with DDL trigger [#992](https://github.com/utPLSQL/utPLSQL/issues/992) +- Fixed issue with some common column names causing cursor comparison to fail [#997](https://github.com/utPLSQL/utPLSQL/issues/997) +- Fixed issue with invocation of standalone expectations on cursor [#998](https://github.com/utPLSQL/utPLSQL/issues/998) + +## Internal improvements + +- Fixed runability of utplsql self-tests [#968](https://github.com/utPLSQL/utPLSQL/issues/968) + diff --git a/docs/announcements/posts/2020-02-23-version3.1.10-released.md b/docs/announcements/posts/2020-02-23-version3.1.10-released.md new file mode 100644 index 0000000..b337d78 --- /dev/null +++ b/docs/announcements/posts/2020-02-23-version3.1.10-released.md @@ -0,0 +1,35 @@ +--- +layout: post +title: "utPLSQL v3.1.10 released" +date: + created: 2020-02-23 +categories: + - "releases" + - "utplsql-core" + +--- + +# Changes in release 3.1.10 + + +## Enhancements + +- utPLSQL test runner is now validating arguments of `--%throws` annotations at runtime [#721](https://github.com/utPLSQL/utPLSQL/issues/721) [#1033](https://github.com/utPLSQL/utPLSQL/issues/1033) +- Documented limitations of insignificant spaces comparison in compound data [#880](https://github.com/utPLSQL/utPLSQL/issues/880) +- utPLSQL will now detect empty annotation cache for schema even with DLL trigger enabled [#975](https://github.com/utPLSQL/utPLSQL/issues/975) +- Order of procedures and annotation now determines default order of tests in suite [#1036](https://github.com/utPLSQL/utPLSQL/issues/1036) + + +## Bug fixes + +- Nested contexts are now properly identified [#1034](https://github.com/utPLSQL/utPLSQL/issues/1034) +- TeamCity test reporter is now including error message [#1045](https://github.com/utPLSQL/utPLSQL/issues/1045) + +## Internal improvements + +- All self-tests for utPLSQL framework can now be executed using test-owner schema [#969](https://github.com/utPLSQL/utPLSQL/issues/969) +- Misleading rollback warning is no longer showing when running self-tests for utPLSQL [#982](https://github.com/utPLSQL/utPLSQL/issues/982) + +# Downloads + +Download `v3.1.10` release version [here](https://github.com/utPLSQL/utPLSQL/releases/tag/v3.1.10) \ No newline at end of file diff --git a/docs/announcements/posts/2021-01-01-PLSQL-Developer-plugin-version-1.0.0-released.md b/docs/announcements/posts/2021-01-01-PLSQL-Developer-plugin-version-1.0.0-released.md new file mode 100644 index 0000000..100ee46 --- /dev/null +++ b/docs/announcements/posts/2021-01-01-PLSQL-Developer-plugin-version-1.0.0-released.md @@ -0,0 +1,30 @@ +--- +layout: post +title: "PL/SQL Developer plugin version 1.0.0 released" +date: + created: 2021-01-01 +categories: + - "releases" + - "utplsql-plsql-developer-plugins" +--- + +# PL/SQL Developer plugin released! + + +Happy new year! Thanks to [Simon Martinelli](https://github.com/simasch) utPLSQL v3+ is now integrated with [PL/SQL Developer](https://www.allroundautomations.com/products/pl-sql-developer/) IDE + + +## Features + +- The Plugin enables PL/SQL Developer to run tests and code coverage with utPLSQL +- Tests and code coverage can be run for the current user from the tool ribbon or from the context menu on a package or a user +- Test results shown in a test runner window and the code coverage report will be opened in the default browser + +## Documentation + +See details of plugin usage in [readme file](https://github.com/utPLSQL/utPLSQL-PLSQL-Developer/blob/develop/README.md) + +## Downloads + +- Download the plugin release from [releases page](https://github.com/utPLSQL/utPLSQL-PLSQL-Developer/releases) +- Copy `PlsqlDeveloperUtPlsqlPlugin.dll` or `PlsqlDeveloperUtPlsqlPlugin_x86.dll` to the PlugIns directory of your PL/SQL Developer installation diff --git a/docs/announcements/posts/2021-11-18-version3.1.11-released.md b/docs/announcements/posts/2021-11-18-version3.1.11-released.md new file mode 100644 index 0000000..36fdf0a --- /dev/null +++ b/docs/announcements/posts/2021-11-18-version3.1.11-released.md @@ -0,0 +1,48 @@ +--- +layout: post +title: "utPLSQL v3.1.11 released" +date: + created: 2021-11-18 +categories: + - "releases" + - "utplsql-core" + +--- + +# Changes in release 3.1.11 + + +## Enhancements + +- utPLSQL can now be used to generate coverage reports for external tools. See [documentation](https://github.com/utPLSQL/utPLSQL/blob/955de5c2dc527a98a6f5dc0dd8bd8d81a44c459f/docs/userguide/coverage.md#reporting-coverage-outside-of-utplsql) + Implemented in: [#1079](https://github.com/utPLSQL/utPLSQL/pull/1079), resolves [#1025](https://github.com/utPLSQL/utPLSQL/issues/1025) +- Enhanced UT_COVERAGE_COBERTURA_REPORTER to better support TFS and GitLab. Implemented in [#1137](https://github.com/utPLSQL/utPLSQL/pull/1137) and [#1140](https://github.com/utPLSQL/utPLSQL/pull/1140), resolves [#1107](https://github.com/utPLSQL/utPLSQL/issues/1107) +- Added support for installation on Oracle 21c - removed dependency on DBMS_OBFUSCATION_TOOLKIT. Implemented in [#1112](https://github.com/utPLSQL/utPLSQL/pull/1112), resolves [#1111](https://github.com/utPLSQL/utPLSQL/issues/1111) and [#1127](https://github.com/utPLSQL/utPLSQL/issues/1127) +- Added support for running utPLSQL framework in parallel-enabled database. Implemented in [#1160](https://github.com/utPLSQL/utPLSQL/pull/1160), resolves [#1134](https://github.com/utPLSQL/utPLSQL/issues/1134) + + + +## Bug fixes + +- Suite structure is built properly even with other than English TNS settings. Implemented in [#1061](https://github.com/utPLSQL/utPLSQL/pull/1061), resolves [#1060](https://github.com/utPLSQL/utPLSQL/issues/1060) +- Fixed XML content reporting (CDATA) in UT_REALTIME_REPORTER used by SQLDeveloper plugin. Implemented in [#1075](https://github.com/utPLSQL/utPLSQL/pull/1075), resolves [#1073](https://github.com/utPLSQL/utPLSQL/issues/1073) +- Fixed XML content reporting (CDATA) in JUnit reporter - regression. Implemented in [#1085](https://github.com/utPLSQL/utPLSQL/pull/1085), resolves [#1084](https://github.com/utPLSQL/utPLSQL/issues/1084) +- Fixed issue with utPLSQL failing to run coverage reporting when trigger has overlapping name with procedure/function/package/type. Implemented in [#1091](https://github.com/utPLSQL/utPLSQL/pull/1091), resolves [#1086](https://github.com/utPLSQL/utPLSQL/issues/1086) +- Fixed issue with parsing utPLSQL suites with DDL trigger when usign AUTHID clause. Implemented in [#1093](https://github.com/utPLSQL/utPLSQL/pull/1093), resolves [#1088](https://github.com/utPLSQL/utPLSQL/issues/1088) + + +## Internal improvements + +- Improved how privilege checks are handled by framework installation. Implemented in [#1056](https://github.com/utPLSQL/utPLSQL/pull/1056), resolves [#1050](https://github.com/utPLSQL/utPLSQL/issues/1050) +- Restructured installation instructions to make it more readable. Implemented in [#1063](https://github.com/utPLSQL/utPLSQL/pull/1063), resolves [#1062](https://github.com/utPLSQL/utPLSQL/issues/1062) +- Updated database requirements in documentation. Implemented in [#1065](https://github.com/utPLSQL/utPLSQL/pull/1065), resolves [#1064](https://github.com/utPLSQL/utPLSQL/issues/1064) +- Removed duplicated call to install profiler tables. Implemented in [#1164](https://github.com/utPLSQL/utPLSQL/pull/1164), resolves [#1149](https://github.com/utPLSQL/utPLSQL/issues/1149) +- Fixed failing internal framework tests on Oracle 21c. Implemented in [#1158](https://github.com/utPLSQL/utPLSQL/pull/1158), resolves [#1151](https://github.com/utPLSQL/utPLSQL/issues/1151) +- Fixed confusing typo in documentation. Resolves [#1154](https://github.com/utPLSQL/utPLSQL/issues/1154) +- Moved build process from travis-ci.org to travis-ci.com. Implemented in [#1152](https://github.com/utPLSQL/utPLSQL/pull/1152) +- Added an example of reporter reporting all expectations, not only the failing ones. Implemented in [#1092](https://github.com/utPLSQL/utPLSQL/pull/1092) + + +# Downloads + +Download `v3.1.11` release version [here](https://github.com/utPLSQL/utPLSQL/releases/tag/v3.1.11) \ No newline at end of file diff --git a/docs/announcements/posts/2022-02-24-version3.1.12-released.md b/docs/announcements/posts/2022-02-24-version3.1.12-released.md new file mode 100644 index 0000000..ffff12a --- /dev/null +++ b/docs/announcements/posts/2022-02-24-version3.1.12-released.md @@ -0,0 +1,38 @@ +--- +layout: post +title: "utPLSQL v3.1.12 released" +date: + created: 2022-02-24 +categories: + - "releases" + - "utplsql-core" + +--- + +# Changes in release 3.1.12 + +## New features + - Added support for description in the `--%disabled` annotation. See [documentation](https://github.com/utPLSQL/utPLSQL/blob/4515e0b5a3b4b0de0c2198db3235ef8614bff4d8/docs/userguide/annotations.md#disabled). Implemented in: [#1183](https://github.com/utPLSQL/utPLSQL/pull/1183), resolves [#610](https://github.com/utPLSQL/utPLSQL/issues/610). + - Added support for native `JSON` datatype on Oracle `21c`. Implemented in [#1181](https://github.com/utPLSQL/utPLSQL/pull/1181), resolves [#1114](https://github.com/utPLSQL/utPLSQL/issues/1114). + - Added new mather `to_be_within( distance|pct ).of_(expoected)`. See [documentation](https://github.com/utPLSQL/utPLSQL/blob/fd7ef9c14111a48e03fff7851f990c7192539170/docs/userguide/expectations.md#to_be_within-of). Implemented in [#1076](https://github.com/utPLSQL/utPLSQL/pull/1076), resolves [#77](https://github.com/utPLSQL/utPLSQL/issues/77). + +## Enhancements + +- Improved performance of SQL used to retrieve Coverage sources. Implemented in [#1187](https://github.com/utPLSQL/utPLSQL/pull/1187), resolves [#1169](https://github.com/utPLSQL/utPLSQL/issues/1169). +- Added ability for utPLSQL to gather coverage on code invoking DBMS_STATS package. Implemented in [#1184](https://github.com/utPLSQL/utPLSQL/pull/1184), resolves [#1097](https://github.com/utPLSQL/utPLSQL/issues/1097), [#1094](https://github.com/utPLSQL/utPLSQL/issues/1094). +- Fixed typos and improved documentation. Implemented in [#1173](https://github.com/utPLSQL/utPLSQL/pull/1173), [#1171](https://github.com/utPLSQL/utPLSQL/pull/1171) + +## Bug fixes + +- Actual and Expected are now correctly reported when comparing `JSON` data. Implemented in [#1181](https://github.com/utPLSQL/utPLSQL/pull/1181), resolves [#1113](https://github.com/utPLSQL/utPLSQL/issues/1113). +- Packages with removed annotations are now correctly recognized as non-utPLSQL packages. Implemented in [#1180](https://github.com/utPLSQL/utPLSQL/pull/1180), resolves [#1177](https://github.com/utPLSQL/utPLSQL/issues/1177). +- Fixed issues with comparison of nested object structures. Implemented in [#1179](https://github.com/utPLSQL/utPLSQL/pull/1179), resolves [#1082](https://github.com/utPLSQL/utPLSQL/issues/1082), [#1083](https://github.com/utPLSQL/utPLSQL/issues/1083), [#1098](https://github.com/utPLSQL/utPLSQL/issues/1098). + + +## Internal improvements + +- Moved build and test process for utPLSQL from Travis to GithubActions. Implemented in [#1175](https://github.com/utPLSQL/utPLSQL/pull/1175) + +# Downloads + +Download `v3.1.12` release version [here](https://github.com/utPLSQL/utPLSQL/releases/tag/v3.1.12) \ No newline at end of file diff --git a/docs/announcements/posts/2022-06-10-maven-plugin-version3.1.10-released.md b/docs/announcements/posts/2022-06-10-maven-plugin-version3.1.10-released.md new file mode 100644 index 0000000..39a5d46 --- /dev/null +++ b/docs/announcements/posts/2022-06-10-maven-plugin-version3.1.10-released.md @@ -0,0 +1,15 @@ +--- +layout: post +title: "utPLSQL-maven-plugin v3.1.10 released" +date: + created: 2022-06-10 +categories: + - "releases" + - "utplsql-maven-plugin" +--- + + +# Changes in release 3.1.10 + +## What's Changed +* Add new `` parameter - resolves [#70](https://github.com/utPLSQL/utPLSQL-maven-plugin/issues/70) diff --git a/docs/announcements/posts/2022-06-13-cli-version3.1.9-released.md b/docs/announcements/posts/2022-06-13-cli-version3.1.9-released.md new file mode 100644 index 0000000..33ab9df --- /dev/null +++ b/docs/announcements/posts/2022-06-13-cli-version3.1.9-released.md @@ -0,0 +1,20 @@ +--- +layout: post +title: "utPLSQL-cli v3.1.9 released" +date: + created: 2022-06-13 +categories: + - "releases" + - "utplsql-cli" +--- + + +# Changes in release 3.1.9 + +## What's Changed +* Bugfix/Locale-Info and Nullpointer by [@pesse](https://github.com/pesse) in [#171](https://github.com/utPLSQL/utPLSQL-cli/pull/171) +* Feature/cleanup maven jdbc by [@jgebal](https://github.com/jgebal) in [#176](https://github.com/utPLSQL/utPLSQL-cli/pull/176) +* Support `a_coverage_schemes` option of utPLSQL by [@pesse](https://github.com/pesse) in [#180](https://github.com/utPLSQL/utPLSQL-cli/pull/180) +* Feature/GitHub actions by [@jgebal](https://github.com/jgebal) in [#202](https://github.com/utPLSQL/utPLSQL-cli/pull/202) +* Add new --ora-stuck-timeout parameter by [@pesse](https://github.com/pesse) in [#198](https://github.com/utPLSQL/utPLSQL-cli/pull/198) +* Update dependencies by [@pesse](https://github.com/pesse) in [#204](https://github.com/utPLSQL/utPLSQL-cli/pull/204) diff --git a/docs/announcements/posts/2022-10-11-new-website-design.md b/docs/announcements/posts/2022-10-11-new-website-design.md new file mode 100644 index 0000000..0ce1f92 --- /dev/null +++ b/docs/announcements/posts/2022-10-11-new-website-design.md @@ -0,0 +1,27 @@ +--- +layout: post +title: "New website design" +date: + created: 2022-10-12 +categories: + - "website" +--- + + +Today is [#JoelKallmanDay](https://twitter.com/hashtag/JoelKallmanDay?f=live). + +As memorial of Joel Kallman, on this day utPLSQL launched its new website using different engine. + +We have moved away from using [Jekyll](https://jekyllrb.com/) with GitHub Pages to host project and organization sites. +[Jekyll](https://jekyllrb.com/) was simply too much hussle and we used [MkDocs](https://www.mkdocs.org/) to generate offline documentation for utPLSQL that was packaged into the release zip file. + +So instead of using two different methods, wei will now use only one. [MkDocs](https://www.mkdocs.org/) is now used for both utPSLQL offline and for online organization and project pages. + +Thanks to wonderful [material](https://squidfunk.github.io/mkdocs-material/) theme and [mike](https://github.com/jimporter/mike)(versioning plugin) for MkDocs you may now enjoy the following new features: + +- dark & light theme +- better navigation and menu in utPLSQL documentation +- documentation version dropdown +- powerful and fast search within documentation + +Hopefully, you will like the changes and enhancements. All the permanent links to old site should still be working. \ No newline at end of file diff --git a/docs/announcements/posts/2022-12-11-version3.1.13-released.md b/docs/announcements/posts/2022-12-11-version3.1.13-released.md new file mode 100644 index 0000000..2e57cd4 --- /dev/null +++ b/docs/announcements/posts/2022-12-11-version3.1.13-released.md @@ -0,0 +1,41 @@ +--- +layout: post +title: "utPLSQL v3.1.13 released" +date: + created: 2022-12-11 +categories: + - "releases" + - "utplsql-core" + +--- + +# Changes in release 3.1.13 + + +## New features + + - Add ability to run tests by part of a name. Fixed in [#1203](https://github.com/utPLSQL/utPLSQL/pull/1203), resolves [#470](https://github.com/utPLSQL/utPLSQL/issues/470) + +## Enhancements + + - Added documentation section on creating a custom reporter. Fixed in [#1225](https://github.com/utPLSQL/utPLSQL/pull/1225), resolves [#710](https://github.com/utPLSQL/utPLSQL/issues/701) + - Add ability to specify code coverage objects include/exclude masks as regular expressions. Fixed in [#1186](https://github.com/utPLSQL/utPLSQL/issues/1186), resolves [#1053](https://github.com/utPLSQL/utPLSQL/issues/1053) + + +## Bug fixes + + - Comparing collection that have long type names. Fixed in [#1238](https://github.com/utPLSQL/utPLSQL/issues/1238), resolves [#1235](https://github.com/utPLSQL/utPLSQL/issues/1235). + - Code coverage reporting on code with long lines. Fixed in [#1240](https://github.com/utPLSQL/utPLSQL/issues/1240), resolves [#1232](https://github.com/utPLSQL/utPLSQL/issues/1232), [#1087](https://github.com/utPLSQL/utPLSQL/issues/1087). + - Code coverage reporting does not exclude tests. Fixed in [#1226](https://github.com/utPLSQL/utPLSQL/issues/1226), resolves [#1222](https://github.com/utPLSQL/utPLSQL/issues/1222). + - Uninstall script buffer overflow. Fixed in [#1221](https://github.com/utPLSQL/utPLSQL/issues/1221), resolves [#1220](https://github.com/utPLSQL/utPLSQL/issues/1220). + + +## Internal improvements + + - Improved process of generating utPLSQL documentation. Implemented in [689bbd0](https://github.com/utPLSQL/utPLSQL/commit/689bbd0e365ed919315c29727bc10fbfc0dadce8), resolves [#1237](https://github.com/utPLSQL/utPLSQL/issues/1237). + - Removed username env variables for internal development. Implemented in [#1201](https://github.com/utPLSQL/utPLSQL/issues/1221), resolves [#1200](https://github.com/utPLSQL/utPLSQL/issues/1200). + - Test execution data of utPLSQL project not showing on SonarCloud. Implemented in [#1199](https://github.com/utPLSQL/utPLSQL/issues/1199), resolves [#1198](https://github.com/utPLSQL/utPLSQL/issues/1198). + +## Downloads + +Download `v3.1.13` release version [here](https://github.com/utPLSQL/utPLSQL/releases/tag/v3.1.13) diff --git a/docs/announcements/posts/2024-02-19-version3.1.14-released.md b/docs/announcements/posts/2024-02-19-version3.1.14-released.md new file mode 100644 index 0000000..6f3b35e --- /dev/null +++ b/docs/announcements/posts/2024-02-19-version3.1.14-released.md @@ -0,0 +1,32 @@ +--- +layout: post +title: "utPLSQL v3.1.14 released" +date: + created: 2024-02-19 +categories: + - "releases" + - "utplsql-core" + +--- + +## What's Changed +* Added support for `and` and `or` operators when running tests by tags by [@lwasylow](https://github.com/lwasylow) in [#1250](https://github.com/utPLSQL/utPLSQL/pull/1250) +* Allow for test runs over 4 hours by [@jgebal](https://github.com/jgebal) in [#1243](https://github.com/utPLSQL/utPLSQL/pull/1243) +* Framework performance improvements by [@jgebal](https://github.com/jgebal) in [#1249](https://github.com/utPLSQL/utPLSQL/pull/1249) +* Support multiple expectation failures with teamcity reporter by [@jgebal](https://github.com/jgebal) in [#1251](https://github.com/utPLSQL/utPLSQL/pull/1251) +* Address issue where the not_to(contain) not run correctly by [@lwasylow](https://github.com/lwasylow) in [#1246](https://github.com/utPLSQL/utPLSQL/pull/1246) +* Fix regex to be NLS_SORT independent by [@jgebal](https://github.com/jgebal) in [#1253](https://github.com/utPLSQL/utPLSQL/pull/1253) +* Fix output length error and output buffer. by [@jgebal](https://github.com/jgebal) in [#1255](https://github.com/utPLSQL/utPLSQL/pull/1255) +* (docs): Update running-unit-tests.md - remove example by [@gassenmj](https://github.com/gassenmj) in [#1261](https://github.com/utPLSQL/utPLSQL/pull/1261) +* The line-rate is not recorded for packages and classes in cobertura coverage reporter by [@lwasylow](https://github.com/lwasylow) in [#1269](https://github.com/utPLSQL/utPLSQL/pull/1269) +* (docs): Fix nested list issue by [@iamrachid](https://github.com/iamrachid) in [#1274](https://github.com/utPLSQL/utPLSQL/pull/1274) +* Update TFS reporter to correct format by [@lwasylow](https://github.com/lwasylow) in [#1270](https://github.com/utPLSQL/utPLSQL/pull/1270) + +## New Contributors +* [@gassenmj](https://github.com/gassenmj) made their first contribution in [#1261](https://github.com/utPLSQL/utPLSQL/pull/1261) +* [@iamrachid](https://github.com/iamrachid) made their first contribution in [#1274](https://github.com/utPLSQL/utPLSQL/pull/1274) + +**Full Changelog**: [v3.1.13...v3.1.14](https://github.com/utPLSQL/utPLSQL/compare/v3.1.13...v3.1.14) + +---------------------------- +[Download utPLSQL release `v3.1.14` here](https://github.com/utPLSQL/utPLSQL/releases/tag/v3.1.14) diff --git a/docs/announcements/posts/2026-04-22-version3.2.01-released.md b/docs/announcements/posts/2026-04-22-version3.2.01-released.md new file mode 100644 index 0000000..b60e6cc --- /dev/null +++ b/docs/announcements/posts/2026-04-22-version3.2.01-released.md @@ -0,0 +1,26 @@ +--- +layout: post +title: "utPLSQL v3.2.01 released" +date: + created: 2026-04-22 +categories: + - "releases" + - "utplsql-core" + +--- + +## Important + - Dropped support for Oracle Database versions older than 19c + +## New features + - Add TAP reporter by @WayneNani in [#1305](https://github.com/utPLSQL/utPLSQL/pull/1305) + +## Enhancements and bug fixes + - Added duplicate detection on cursor comparison using `join_by` by @lwasylow in [#1295](https://github.com/utPLSQL/utPLSQL/pull/1295) + - Fix code causing the object duration Oracle exception on oracle 23.26 by @lwasylow in [#1310](https://github.com/utPLSQL/utPLSQL/pull/1310) + - Packages with annotation-like comments are not test suites by @jgebal in [#1313](https://github.com/utPLSQL/utPLSQL/pull/1313) + - Performance improvements to annotation parsing by @lwasylow in [#1312](https://github.com/utPLSQL/utPLSQL/pull/1319) + - Updated documentation and copyright banners across source files @jgebal in [#1319](https://github.com/utPLSQL/utPLSQL/pull/1319) + +---------------------------- +[Download utPLSQL release v3.2.01 here](https://github.com/utPLSQL/utPLSQL/releases/tag/v3.2.01) diff --git a/docs/announcements/posts/2026-05-24-version3.2.2-released.md b/docs/announcements/posts/2026-05-24-version3.2.2-released.md new file mode 100644 index 0000000..229226a --- /dev/null +++ b/docs/announcements/posts/2026-05-24-version3.2.2-released.md @@ -0,0 +1,22 @@ +--- +layout: post +title: "utPLSQL v3.2.2 released" +date: + created: 2026-05-24 +categories: + - "releases" + - "utplsql-core" + +--- + +## What's Changed +* Filtering by tags fixed for schemas containing suite-paths and contexts by @jgebal in [#1325](https://github.com/utPLSQL/utPLSQL/pull/1325) +* Fixed issue with reporter failing to initialize by @jgebal in [#1354](https://github.com/utPLSQL/utPLSQL/pull/1354) +* Fixed issue with duplicate sources from dba_source by @jgebal in [#1355](https://github.com/utPLSQL/utPLSQL/pull/1355) +* Allow HTML coverage on FIPS-enabled DB by @jgebal in [#1356](https://github.com/utPLSQL/utPLSQL/pull/1356) + + +**Full Changelog**: [v3.2.01...v3.2.2](https://github.com/utPLSQL/utPLSQL/compare/v3.2.01...v3.2.2) + +---------------------------- +[Download utPLSQL release v3.2.2 here](https://github.com/utPLSQL/utPLSQL/releases/tag/v3.2.2) diff --git a/docs/announcements/posts/2026-06-15-website-navigation-improvements.md b/docs/announcements/posts/2026-06-15-website-navigation-improvements.md new file mode 100644 index 0000000..eacedfa --- /dev/null +++ b/docs/announcements/posts/2026-06-15-website-navigation-improvements.md @@ -0,0 +1,35 @@ +--- +layout: post +title: "Website navigation improvements" +date: + created: 2026-06-15 +categories: + - "website" +--- + +We've been busy improving the utPLSQL website experience over the past couple of days. + + + +## Shared navigation bar + +The top navigation bar shared across all utPLSQL sites has been redesigned and refactored. +It is now more consistent and makes it easier to navigate utPLSQL project and organization's pages. + +## Light / Dark / Auto theme switching + +The theme toggle has been upgraded from a simple light/dark switch to a three-way control: + +- **Light** — always light +- **Dark** — always dark +- **Auto** — follows your system preference + +Your choice is remembered across visits. + +## Announcements reorganized + +The Announcements are now presented in a blog-like style with categories section expanded by default, making it easier to find relevant announcements at a glance. +The archive by year has been removed in favour of a cleaner post listing on the index page. + +We hope these improvements make the site more pleasant to use. +Feel free to share feedback in the [GitHub Discussions](https://github.com/org/discussions). diff --git a/docs/announcements/posts/2026-06-17-utPLSQL-for-SQL-Developer-2.0.1-released.md b/docs/announcements/posts/2026-06-17-utPLSQL-for-SQL-Developer-2.0.1-released.md new file mode 100644 index 0000000..caceb13 --- /dev/null +++ b/docs/announcements/posts/2026-06-17-utPLSQL-for-SQL-Developer-2.0.1-released.md @@ -0,0 +1,22 @@ +--- +layout: post +title: "utPLSQL for SQL Developer v2.0.0 and v2.0.1" +date: + created: 2026-06-17 +categories: + - "releases" + - "utplsql-sql-developer" + +--- + +This is a maintenance release all dependencies and changes by @PhilippSalvisberg + +## What's Changed +* Enforces SQL Developer version 24.3.1.347.1826 with JDK 17 +* Bumps all dependencies + + +**Full Changelog**: [v1.4.1...v2.0.1](https://github.com/utPLSQL/utPLSQL-SQLDeveloper/compare/v1.4.1...v2.0.1) + +---------------------------- +[Download utPLSQL for SQL Developer v2.0.1 here](https://github.com/utPLSQL/utPLSQL-SQLDeveloper/releases/tag/v2.0.1) diff --git a/docs/announcements/posts/2026-07-10-version3.2.3-released.md b/docs/announcements/posts/2026-07-10-version3.2.3-released.md new file mode 100644 index 0000000..f9e9956 --- /dev/null +++ b/docs/announcements/posts/2026-07-10-version3.2.3-released.md @@ -0,0 +1,24 @@ +--- +layout: post +title: "utPLSQL v3.2.3 released" +date: + created: 2026-07-10 +categories: + - "releases" + - "utplsql-core" +--- + +## What's Changed +* Fix issue with `UT_TAP_REPORTER` on Oracle 23.26 by @jgebal in [#1359](https://github.com/utPLSQL/utPLSQL/pull/1359) +* Fixed support for camelCase in context `--%name` annotation. by @jgebal in [#1361](https://github.com/utPLSQL/utPLSQL/pull/1361) +* utPLSQL can be installed in editioned schema. by @jgebal in [#1362](https://github.com/utPLSQL/utPLSQL/pull/1362) +* Removed coveralls reporter by @jgebal in [#1363](https://github.com/utPLSQL/utPLSQL/pull/1363) +* Clarify behavior of before/after procedures in suitepath by @jgebal in [#1364](https://github.com/utPLSQL/utPLSQL/pull/1364) +* `throws` can reference exception without schema or package name by @jgebal in [#1365](https://github.com/utPLSQL/utPLSQL/pull/1365) +* `throws` works with uninitialized exception variables by @jgebal in [#1366](https://github.com/utPLSQL/utPLSQL/pull/1366) + + +**Full Changelog**: [v3.2.2...v.3.2.3](https://github.com/utPLSQL/utPLSQL/compare/v3.2.2...v.3.2.3) + +---------------------------- +[Download utPLSQL release v3.2.3 here](https://github.com/utPLSQL/utPLSQL/releases/tag/v3.2.3) diff --git a/docs/announcements/posts/2026-08-14-next-chapter-for-utPLSQL.md b/docs/announcements/posts/2026-08-14-next-chapter-for-utPLSQL.md new file mode 100644 index 0000000..ac09dd1 --- /dev/null +++ b/docs/announcements/posts/2026-08-14-next-chapter-for-utPLSQL.md @@ -0,0 +1,82 @@ +--- +layout: post +title: "Next chapter for utPLSQL" +date: + created: 2026-08-12 +categories: + - "news" +--- + +## Looking back +utPLSQL v3 has come a long way since it was first released in 2017. +It has already been over 10 years since the first discussions about starting the project began. +However, development slowed after 2019, and by 2024 the project had become inactive. +Life took me in a different direction for a few years, and the after-hours project understandably took a back seat. + + +## The current state +In the last year, a few people reached out to me asking whether the project is still alive. +Regulated companies often can't use software that isn't under active maintenance, +and others simply treat it as a security risk. + +In recent months I have invested time in bringing the project back to life, +refreshing all libraries and dependencies, fixing build processes and pipelines, +and releasing new versions for the main project and tools. +The documentation was restructured and updated, and discussions were moved to [GitHub](https://github.com/orgs/utPLSQL/discussions). + +## The future roadmap + +I realized that **utPLSQL needs a clear vision for its future development**. Without one, +it risks becoming legacy and dying, like many other open-source projects have. + +The software world keeps moving forward. New versions of Oracle Database, programming languages, developer tools and libraries are released continuously. + +At the same time, there are many ideas and plans that were never implemented as part of the development of utPLSQL v3. Those are still very much valid and would be highly valuable additions to the framework. They would make PL/SQL development and testing even more modern and smoother. + +I have created a high-level roadmap that highlights the key points of the future development of utPLSQL core. + +### Phase 1 - Core + +- Security model rework: CBAC for framework internals +- Drop legacy version support (11g, 12c, 18c) +- Annotations, suite structure & module rework + +### Phase 2 - Modernization + +- Code coverage rework +- Reporter API & assertion output improvements +- Modern database capabilities (data types) + +### Phase 3 - Developer experience + +- Framework usage - telemetry +- Developer/tester productivity (data setup, mocking, scope narrowing) + +### Phase 4 - New capability + +- cucumber-utPLSQL: Gherkin BDD/ATDD test runner for PL/SQL + +The detailed roadmap is available in the [utPLSQL org GitHub Discussions](https://github.com/orgs/utPLSQL/discussions/15). + +## Sustainability + +The intention is to keep utPLSQL under active development and create possibilities for companies and individuals to get direct access to the development team, with options for knowledge sharing, consultations, and more. + +Working on the above requires significant investment of thought, time and effort. It is not sustainable to keep developing utPLSQL without support from those who use it and benefit from it daily. + +Over the last decade, this project has been a significant part of my life as an engineer and professional software developer. I would like to see it thrive rather than fade into deprecation and obscurity. + +## Sponsorship + +I am currently working on opening utPLSQL for sponsorship, and I'll share the tiers and details in a follow-up post once everything is in place. + +If you or your company would benefit from active development of utPLSQL and want to be notified when sponsorship opens then please: + +- comment on [this GitHub discussion](https://github.com/orgs/utPLSQL/discussions/22) +- or contact me directly on [LinkedIn](https://www.linkedin.com/in/jacek-gebal-6678301/) [X](https://x.com/GebalJacek), [BlueSky](https://bsky.app/profile/jacek-gebal.bsky.social) +- or contact utPLSQL.org on [LinkedIn](https://www.linkedin.com/company/utplsql/), [X](https://x.com/utPLSQL), [BlueSky](https://bsky.app/profile/utplsql.bsky.social) + +Your responses will help me gauge interest as I finalize the preparations. + +> Jacek Gebal
+> @utPLSQL \ No newline at end of file diff --git a/docs/assets/favicon.png b/docs/assets/favicon.png new file mode 100644 index 0000000..7c34109 Binary files /dev/null and b/docs/assets/favicon.png differ diff --git a/docs/assets/icon-transparent.png b/docs/assets/icon-transparent.png new file mode 100644 index 0000000..6e4534a Binary files /dev/null and b/docs/assets/icon-transparent.png differ diff --git a/docs/assets/sqlcl-utplsql.jpg b/docs/assets/sqlcl-utplsql.jpg new file mode 100644 index 0000000..c6e368f Binary files /dev/null and b/docs/assets/sqlcl-utplsql.jpg differ diff --git a/docs/assets/supported_by_redgate_100.png b/docs/assets/supported_by_redgate_100.png new file mode 100644 index 0000000..ea9f93a Binary files /dev/null and b/docs/assets/supported_by_redgate_100.png differ diff --git a/docs/assets/topbar.css b/docs/assets/topbar.css new file mode 100644 index 0000000..e9c431b --- /dev/null +++ b/docs/assets/topbar.css @@ -0,0 +1,200 @@ +#utplsql-topbar { + background: #1565c0; + padding: 0 1rem; + display: flex; + align-items: center; + height: 2rem; + font-size: 0.7rem; + font-family: var(--md-text-font, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif); + position: sticky; + top: 0; + z-index: 10; + box-shadow: 0 1px 3px rgba(0,0,0,0.25); + letter-spacing: 0.03em; +} + +#utplsql-topbar a { + color: rgba(255,255,255,0.72); + text-decoration: none; + padding: 0 0.5rem; + line-height: 2rem; + white-space: nowrap; + transition: color 0.15s; +} + +#utplsql-topbar a:hover, +#utplsql-topbar a.utplsql-active { + color: #fff; +} + +#utplsql-topbar .utplsql-brand { + font-weight: 700; + color: #fff; + padding-right: 0.75rem; + margin-right: 0.25rem; + border-right: 1px solid rgba(255,255,255,0.25); + display: flex; + align-items: center; + gap: 0.4rem; +} + +#utplsql-topbar .utplsql-brand-icon { + display: block; + width: 1.3rem; + height: 1.3rem; + flex-shrink: 0; + background-image: url('icon-transparent.png'); + background-repeat: no-repeat; + background-position: center; + background-size: contain; +} + +#utplsql-topbar .utplsql-controls { + margin-left: auto; + display: flex; + align-items: center; + gap: 0.1rem; +} + +#utplsql-topbar .utplsql-controls button { + background: none; + border: none; + cursor: pointer; + color: rgba(255,255,255,0.72); + padding: 0 0.4rem; + height: 2rem; + display: flex; + align-items: center; + transition: color 0.15s; + border-radius: 0.2rem; +} + +#utplsql-topbar .utplsql-controls button:hover { + color: #fff; +} + +#utplsql-topbar .utplsql-controls button svg { + width: 1rem; + height: 1rem; + fill: currentColor; + display: block; +} + +/* Material header sits below the topbar */ +.md-header, +.md-header--shadow { + top: 2rem !important; +} + +/* NOTE: .md-header__button and .md-header__option hiding is intentionally + NOT here — it is injected by topbar.js only after the topbar is built, + so that a JS failure leaves Material's original navigation intact. */ + +/* ── Org-site only ──────────────────────────────────────────────────────── + The org site sets data-utplsql-site="org" on in its template. + Sub-sites keep Material's title (version selector lives there) and tabs + (the only way to navigate between top-level sections like User Guide / + Reporting / About). + ─────────────────────────────────────────────────────────────────────── */ + +/* Hide Material's logo/title on the org site — brand lives in the topbar */ +[data-utplsql-site="org"] .md-header__title { + display: none !important; +} + +/* Hide tab bar on the org site — the shared topbar handles section nav */ +[data-utplsql-site="org"] .md-tabs { + display: none !important; +} + +/* Back-to-top button: push below topbar + header so it isn't hidden behind them */ +.md-top { + top: 4.4rem !important; +} + +/* Sidebar offset: org site has topbar + header (~2 + 2.4 = 4.4rem), no tabs. + Sub-sites have topbar + header + tabs (~2 + 2.4 + 2.4 = 6.8rem). */ +[data-utplsql-site="org"] .md-sidebar { + top: 4.4rem !important; +} + +.md-sidebar { + top: 6.8rem !important; +} + +/* Hamburger button — hidden by default, shown via media query on mobile */ +#utplsql-topbar .utplsql-hamburger { + display: none; + background: none; + border: none; + cursor: pointer; + color: rgba(255,255,255,0.72); + padding: 0 0.4rem; + height: 2rem; + align-items: center; + flex-shrink: 0; + transition: color 0.15s; +} + +#utplsql-topbar .utplsql-hamburger:hover { + color: #fff; +} + +#utplsql-topbar .utplsql-hamburger svg { + width: 1.2rem; + height: 1.2rem; + fill: currentColor; + display: block; +} + +/* Org site links injected into Material's sidebar drawer — desktop: hidden */ +#utplsql-drawer-nav { + display: none; +} + +@media screen and (max-width: 76.1875em) { + /* Hide nav links on mobile — sidebar drawer handles navigation */ + #utplsql-topbar a:not(.utplsql-brand) { + display: none; + } + + /* Show hamburger */ + #utplsql-topbar .utplsql-hamburger { + display: flex; + } + + /* Material's mobile search overlay is position:fixed from top:0. + Shift the whole search container (form + output together) below our topbar. */ + .md-search__inner { + padding-top: 2rem !important; + } + + /* Org site nav section at the top of the drawer */ + #utplsql-drawer-nav { + display: block; + padding: 0.6rem 0.8rem 0.4rem; + border-bottom: 1px solid var(--md-default-fg-color--lightest, rgba(0,0,0,.12)); + margin-bottom: 0.4rem; + } + + #utplsql-drawer-nav .utplsql-drawer-heading { + font-size: 0.65rem; + font-weight: 700; + letter-spacing: 0.08em; + text-transform: uppercase; + color: var(--md-default-fg-color--light); + padding-bottom: 0.3rem; + } + + #utplsql-drawer-nav a { + display: block; + padding: 0.25rem 0; + color: var(--md-typeset-a-color); + text-decoration: none; + font-size: 0.75rem; + } + + #utplsql-drawer-nav a:hover { + color: var(--md-accent-fg-color); + } +} diff --git a/docs/assets/topbar.js b/docs/assets/topbar.js new file mode 100644 index 0000000..382af71 --- /dev/null +++ b/docs/assets/topbar.js @@ -0,0 +1,325 @@ +/** + * utPLSQL shared top navigation bar. + * Published at https://utplsql.org/assets/topbar.js + * + * CSS lives in topbar.css (loaded via extra_css / template link) so it + * survives Material's instant-navigation head replacement. + * + * Sub-repositories load this script via their docs/overrides/main.html template. + * Update this file to change the shared nav across all sub-sites simultaneously. + */ +(function () { + 'use strict'; + + /* Base URL comes from the MkDocs site_url injected by the template. + Sub-sites that load this script from utplsql.org don't set the variable, + so they fall back to the hardcoded production URL. */ + var BASE = (window.utplsqlBaseUrl || 'https://www.utplsql.org/').replace(/\/+$/, ''); + + var NAV = [ + { label: 'Home', url: BASE + '/' }, + { label: 'Announcements', url: BASE + '/announcements/' }, + { label: 'Documentation', url: BASE + '/documentation.html' }, + { label: 'Downloads', url: BASE + '/downloads.html' }, + { label: 'Resources', url: BASE + '/resources.html' }, + { label: 'About', url: BASE + '/about.html' }, + { label: 'Contributing', url: BASE + '/contributing.html' }, + ]; + + var SVG_MENU = + '' + + '' + + ''; + + /* Icons from Material for MkDocs icon set, matching the org's mkdocs.yml palette config. + Cycle order: auto → light → dark → auto + auto → material/lightbulb-auto-outline (following OS preference) + light → material/lightbulb-outline (forced light, click for dark) + dark → material/lightbulb (forced dark, click for auto) */ + var SVG_AUTO = + '' + + '' + + ''; + + var SVG_LIGHT = + '' + + '' + + ''; + + var SVG_DARK = + '' + + '' + + ''; + + /* Module-level references so the built bar can be re-inserted on instant + navigation without recreating it (prevents the logo from reloading). */ + var themeBtn = null; + var savedBar = null; + + /* ── Theme state ───────────────────────────────────────────────────────── + 'utplsql-scheme' in localStorage holds one of three values: + 'auto' — follow the OS prefers-color-scheme (default when unset) + 'default' — forced light mode + 'slate' — forced dark mode + ─────────────────────────────────────────────────────────────────────── */ + + function getPreference() { + try { return localStorage.getItem('utplsql-scheme') || 'auto'; } catch (e) {} + return 'auto'; + } + + function osPrefersDark() { + return window.matchMedia('(prefers-color-scheme: dark)').matches; + } + + /* Returns the effective Material colour scheme for the current preference. */ + function effectiveScheme(pref) { + if (pref === 'slate' || pref === 'default') return pref; + return osPrefersDark() ? 'slate' : 'default'; /* auto */ + } + + function applyScheme(scheme) { + document.body.setAttribute('data-md-color-scheme', scheme); + /* Keep Material's own __palette in sync so its JS doesn't fight us. */ + try { + var stored = JSON.parse(localStorage.getItem('__palette') || 'null'); + if (stored && stored.color) { + stored.color.scheme = scheme; + stored.index = scheme === 'slate' ? 1 : 0; + } else { + stored = { index: scheme === 'slate' ? 1 : 0, color: { scheme: scheme } }; + } + localStorage.setItem('__palette', JSON.stringify(stored)); + } catch (e) {} + } + + function updateThemeIcon() { + if (!themeBtn) return; + var pref = getPreference(); + if (pref === 'auto') { + themeBtn.innerHTML = SVG_AUTO; + themeBtn.setAttribute('aria-label', 'Theme: auto (following OS) — click for light'); + } else if (pref === 'default') { + themeBtn.innerHTML = SVG_LIGHT; + themeBtn.setAttribute('aria-label', 'Theme: light — click for dark'); + } else { + themeBtn.innerHTML = SVG_DARK; + themeBtn.setAttribute('aria-label', 'Theme: dark — click for auto'); + } + } + + /* Re-applies our stored preference after Material's navigation re-init. */ + function applyStoredScheme() { + var pref = getPreference(); + applyScheme(effectiveScheme(pref)); + updateThemeIcon(); + } + + function injectDrawerNav() { + /* Only needed on mobile — desktop shows links in the topbar itself. */ + if (!window.matchMedia('(max-width: 76.1875em)').matches) return; + + /* Already injected and still in the DOM — nothing to do. */ + if (document.getElementById('utplsql-drawer-nav')) return; + + var inner = document.querySelector('.md-sidebar--primary .md-sidebar__inner'); + if (!inner) return; + + var section = document.createElement('nav'); + section.id = 'utplsql-drawer-nav'; + section.setAttribute('aria-label', 'utPLSQL.org site navigation'); + + var heading = document.createElement('div'); + heading.className = 'utplsql-drawer-heading'; + heading.textContent = 'utPLSQL.org'; + section.appendChild(heading); + + NAV.forEach(function (item) { + var a = document.createElement('a'); + a.href = item.url; + a.textContent = item.label; + section.appendChild(a); + }); + + inner.insertBefore(section, inner.firstChild); + } + + function updateActiveLink() { + var bar = document.getElementById('utplsql-topbar'); + if (!bar) return; + var current = window.location.href; + bar.querySelectorAll('a:not(.utplsql-brand)').forEach(function (a) { + var isActive = a.href !== BASE + '/' && current.indexOf(a.href) === 0; + a.classList.toggle('utplsql-active', isActive); + }); + } + + + function ensureStyle() { + /* Re-inject the hiding style if Material's instant navigation removed it. */ + if (!document.getElementById('utplsql-topbar-style')) { + var s = document.createElement('style'); + s.id = 'utplsql-topbar-style'; + s.textContent = + '.md-header__button:not([for="__search"]) { display: none !important; }' + + '.md-header__option { position: absolute !important; left: -9999px !important; }' + + '.md-top { top: 4.4rem !important; z-index: 11; }'; + document.head.appendChild(s); + } + } + + function inject() { + ensureStyle(); + + /* Topbar already in DOM — just sync state. */ + if (document.getElementById('utplsql-topbar')) { + updateActiveLink(); + applyStoredScheme(); + injectDrawerNav(); + return; + } + + /* Material's instant navigation removed the topbar — re-insert the same + DOM node so the CSS background-image icon doesn't flash. */ + if (savedBar) { + document.body.insertBefore(savedBar, document.body.firstChild); + updateActiveLink(); + applyStoredScheme(); + injectDrawerNav(); + return; + } + + /* ── First load: build the bar ── */ + var bar = document.createElement('nav'); + bar.id = 'utplsql-topbar'; + bar.setAttribute('aria-label', 'utPLSQL.org site navigation'); + + /* Hamburger — mobile only, triggers Material's sidebar drawer */ + var hamburger = document.createElement('button'); + hamburger.className = 'utplsql-hamburger'; + hamburger.setAttribute('aria-label', 'Open navigation'); + hamburger.innerHTML = SVG_MENU; + hamburger.addEventListener('click', function () { + var drawer = document.querySelector('label[for="__drawer"]'); + if (drawer) drawer.click(); + }); + bar.appendChild(hamburger); + + /* Brand */ + var brand = document.createElement('a'); + brand.className = 'utplsql-brand'; + brand.href = BASE + '/'; + + var icon = document.createElement('span'); + icon.className = 'utplsql-brand-icon'; + icon.setAttribute('aria-hidden', 'true'); + brand.appendChild(icon); + + var brandText = document.createElement('span'); + brandText.textContent = 'utPLSQL'; + brand.appendChild(brandText); + bar.appendChild(brand); + + /* Nav links */ + NAV.forEach(function (item) { + var a = document.createElement('a'); + a.href = item.url; + a.textContent = item.label; + bar.appendChild(a); + }); + + /* ── Right-aligned controls ── */ + var controls = document.createElement('div'); + controls.className = 'utplsql-controls'; + + /* Theme toggle — cycles: auto → light → dark → auto */ + themeBtn = document.createElement('button'); + themeBtn.addEventListener('click', function () { + var current = getPreference(); + var next = current === 'auto' ? 'default' : current === 'default' ? 'slate' : 'auto'; + try { localStorage.setItem('utplsql-scheme', next); } catch (e) {} + applyScheme(effectiveScheme(next)); + updateThemeIcon(); + }); + + updateThemeIcon(); + controls.appendChild(themeBtn); + bar.appendChild(controls); + + savedBar = bar; + document.body.insertBefore(bar, document.body.firstChild); + updateActiveLink(); + injectDrawerNav(); + + /* When auto mode is active, re-apply if the OS theme changes live. */ + window.matchMedia('(prefers-color-scheme: dark)').addEventListener('change', function () { + if (getPreference() === 'auto') { + applyScheme(effectiveScheme('auto')); + } + }); + } + + function rewriteFeedbackLink() { + var title = encodeURIComponent('Doc feedback: ' + document.title); + var body = encodeURIComponent('Page: ' + location.href + '\n\nWhat could be improved:\n'); + document.querySelectorAll('.md-feedback a[href*="discussions/new"]').forEach(function (a) { + a.href = 'https://github.com/utPLSQL/utPLSQL/discussions/new?category=documentation-feedback&title=' + title + '&body=' + body; + }); + } + + function initFeedbackForm() { + var feedback = document.forms.feedback; + if (typeof feedback === 'undefined') return; + + feedback.hidden = false; + feedback.addEventListener('submit', function (ev) { + ev.preventDefault(); + + var page = document.location.pathname; + var data = ev.submitter.getAttribute('data-md-value'); + + if (typeof gtag !== 'undefined') { + gtag('event', 'feedback', { page: page, data: data }); + } + + feedback.firstElementChild.disabled = true; + + var note = feedback.querySelector(".md-feedback__note [data-md-value='" + data + "']"); + if (note) note.hidden = false; + + rewriteFeedbackLink(); + }); + + rewriteFeedbackLink(); + } + + /* Hide Material's built-in header controls immediately to prevent a flash + where logo/palette appear before the topbar is painted. */ + ensureStyle(); + /* Fallback: if topbar not in DOM after 4 s, restore Material's navigation. */ + setTimeout(function () { + if (!document.getElementById('utplsql-topbar')) { + var s = document.getElementById('utplsql-topbar-style'); + if (s) s.parentNode.removeChild(s); + } + }, 4000); + + /* Apply initial scheme as early as possible to avoid flash. */ + applyScheme(effectiveScheme(getPreference())); + + if (document.readyState === 'loading') { + document.addEventListener('DOMContentLoaded', function () { inject(); initFeedbackForm(); }); + } else { + inject(); + initFeedbackForm(); + } + + /* Material instant navigation — fires after each page swap. */ + if (typeof document$ !== 'undefined') { + document$.subscribe(inject); + document$.subscribe(initFeedbackForm); + } + /* Fallback: browser history navigation */ + window.addEventListener('popstate', updateActiveLink); + +})(); diff --git a/docs/assets/utPLSQL-logo-transparent.png b/docs/assets/utPLSQL-logo-transparent.png new file mode 100644 index 0000000..e31eff2 Binary files /dev/null and b/docs/assets/utPLSQL-logo-transparent.png differ diff --git a/docs/assets/utPLSQL-testing-framework-transparent.png b/docs/assets/utPLSQL-testing-framework-transparent.png new file mode 100644 index 0000000..4bb19c6 Binary files /dev/null and b/docs/assets/utPLSQL-testing-framework-transparent.png differ diff --git a/docs/buildpack.html b/docs/buildpack.html deleted file mode 100644 index 210aa67..0000000 --- a/docs/buildpack.html +++ /dev/null @@ -1,66 +0,0 @@ - - - - - - - - - - - Build Test Packages - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Administrative Topics | Next Section: How to build a test package >

- - -

Build Test Packages

- -

- We learn best by following the examples of those who have gone before - us. So you will find in this document sample test packages and different - approaches to using utPLSQL to test your PL/SQL code like it has never - been tested before! -

-

- Spend some time in the general How to Build a Test - Package so that you are comfortable with the basic steps necessary - to integrate your test code into the utPLSQL framework. The Test Run section - offers a narrative presentation of building a test package; it makes a - nice follow-up to the How To section if you still feel any uncertainty. - Then you will be more than ready to explore the Examples. -

- -

How to Build a Test Package

- -

A "Test Run" with utPLSQL

- - -

< Previous Section: Administrative Topics | Next Section: How to build a test package >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/contributing.md b/docs/contributing.md new file mode 100644 index 0000000..2c3813c --- /dev/null +++ b/docs/contributing.md @@ -0,0 +1,9 @@ +# Contributing + +The utPLSQL project team welcomes contributions from the community. + +- **Contribute code** — please read the [contributing guide](https://github.com/utPLSQL/utPLSQL/blob/master/CONTRIBUTING.md) before submitting a pull request. +- **Ask questions and share ideas** — use [GitHub Discussions](https://github.com/orgs/utPLSQL/discussions) for support, questions, and feature proposals. +- **Report bugs and issues** — open an issue in the relevant [GitHub repository](index.md#core-projects). + +The source code for all utPLSQL projects is hosted on the [utPLSQL GitHub organisation](https://github.com/utPLSQL). diff --git a/docs/defsuite.html b/docs/defsuite.html deleted file mode 100644 index fb3cb98..0000000 --- a/docs/defsuite.html +++ /dev/null @@ -1,138 +0,0 @@ - - - - - - - - - - - Defining Test Suites - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: utRecEq Package | Next Section: Custom Reporter Packages >

- - -

Defining Test Suites

- -

- If you define test suites and register packages - within those suites, then utPLSQL will run an unlimited number of - tests with a single command. -

- -

Note

- - - -

utSuite - Define Test Suites

- -

To create and remove test suites, call these programs:

- -
-PROCEDURE utSuite.add (
-   name_in          IN VARCHAR2,
-   desc_in          IN VARCHAR2 := NULL,
-   rem_if_exists_in IN BOOLEAN  := TRUE
-);
-
-PROCEDURE utSuite.rem (name_in IN VARCHAR2);
-
- -

- These programs manipulate the contents of the ut_suite - table. See the tables.sql file for the DDL creating this table. -

- -

utPackage - Define Test Packages for a Suite

- -

To register a package in a suite, call the following:

- -
-PROCEDURE utPackage.add (
-   suite_in          IN VARCHAR2,
-   package_in        IN VARCHAR2,
-   samepackage_in    IN BOOLEAN := FALSE,
-   prefix_in         IN VARCHAR2 := NULL,
-   dir_in            IN VARCHAR2 := NULL,
-   seq_in            IN PLS_INTEGER := NULL,
-   owner_in          IN VARCHAR2 := NULL,
-   add_tests_in      IN BOOLEAN := FALSE,
-   test_overloads_in IN BOOLEAN := FALSE
-);
-
- -

- This manipulates the contents of the ut_package - table. See the tables.sql file for the DDL creating this table. -

- -

- Here is a sample script that defines a very small - portion of the PL/Vision test suite: -

- -
-BEGIN
-   utSuite.add ('PLVision');
-
-   utPackage.add('PLVision', 'PLVstr', dir_in => 'e:\utplsql\test');
-
-   utPackage.add ('PLVision', 'PLVdate', dir_in => 'e:\utplsql\test'');
-
-   utPLSQL.testsuite ('PLVision', recompile_in => TRUE);
-
-END;
-/
-
- - -

< Previous Section: utRecEq Package | Next Section: Custom Reporter Packages >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/documentation.md b/docs/documentation.md new file mode 100644 index 0000000..bbce1cb --- /dev/null +++ b/docs/documentation.md @@ -0,0 +1,13 @@ +--- +layout: page +title: Documentation +permalink: /documentation/ +menuInclude: true +--- + +* [utPLSQL framework](/utPLSQL/latest) +* [utPLSQL-cli](utPLSQL-cli.md) +* [utPLSQL-maven plugin](utPLSQL-maven-plugin.md) +* [SQLDeveloper extension](utPLSQL-SQLDeveloper.md) +* [PL/SQL Developer plugin](utPLSQL-PLSQL-Developer.md) + diff --git a/docs/downloads.md b/docs/downloads.md new file mode 100644 index 0000000..b927d38 --- /dev/null +++ b/docs/downloads.md @@ -0,0 +1,18 @@ +--- +layout: page +title: Downloads +permalink: /downloads/ +menuInclude: true +--- + + +- [utPLSQL framework](https://github.com/utPLSQL/utPLSQL/releases) - the testing framework + +- [utPLSQL-cli](https://github.com/utPLSQL/utPLSQL-cli/releases) - command line utility to run utPLSQL tests from any command line (Win/Linux/Mac) + +- [utPLSQL Maven plugin](https://github.com/utPLSQL/utPLSQL-maven-plugin/releases) to run utPLSQL tests as part of Java Maven project build + +- [utPSLQL - SQLDeveloper extension](https://github.com/utPLSQL/utPLSQL-SQLDeveloper/releases) to create and run utPLSQL tests from [SQLDeveloper](https://www.oracle.com/database/technologies/appdev/sql-developer.html) + +- [utPSLQL - PL/SQL Developer extension](https://github.com/utPLSQL/utPLSQL-PLSQL-Developer/releases) to create and run utPLSQL tests from [PLSQL Developer](https://www.allroundautomations.com/products/pl-sql-developer/) + diff --git a/docs/examples.html b/docs/examples.html deleted file mode 100644 index d4e2236..0000000 --- a/docs/examples.html +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - - - - - - Examples - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: A 'Test Run' with utPLSQL | Next Section: Test a Procedure >

- - -

Examples

- -

- We learn best by following the examples of those who have gone before - us. So you will find in this document sample test packages and different - approaches to using utPLSQL to test your PL/SQL code like it has never - been tested before! -

- -

Test a Procedure

- -

Test a Function

- -

Test an Entire Package API

- -

Put Test Code in Same Package

- -

Use Non-Default Prefix

- -

Create and Run a Test Suite

- -

< Previous Section: A 'Test Run' with utPLSQL | Next Section: Test a Procedure >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/fileout.html b/docs/fileout.html deleted file mode 100644 index 368f47d..0000000 --- a/docs/fileout.html +++ /dev/null @@ -1,204 +0,0 @@ - - - - - - - - - - - Configuring the File Reporter - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Custom Reporter Packages | Next Section: Release Notes >

- - -

Configuring the File Reporter

- -

Outline

- -

- By default, the results of a test run are written to the screen - (via the default Output Reporter). The subprograms described in this - section were created by Rainer Medert to allow these results to be written - to file instead. They form part of the utConfig package. Don't forget that - you will first need to enable file output from the database via the - UTL_FILE_DIR parameter in order to do this. -

- -

Turning file output on

- -

- To turn on file output, you will need to switch to using the File - Reporter, or a custom reporter that uses it. See the page on Custom Reporter Packages for details. -

- -

Setting the directory to be used

- -

- Once file output has been turned on, you can specify which directory the - files will be written to using the following procedure: -

- -
-PROCEDURE setfiledir (
-   dir_in      IN VARCHAR2 := NULL, 
-   username_in IN VARCHAR2 := NULL
-);
-
- -

- the directory given will have to have been specified for output in a - UTL_FILE_DIR database parameter, as mentioned above. -

- -

To see which directory is being used for output, use the following:

- -
-FUNCTION filedir (username_in IN VARCHAR2 := NULL) RETURN VARCHAR2;
-
- -

Formatting the output filenames

- -

The structure of the filenames used for output is as follows:

- -
-<user-prefix>_[program-name_]<date><extension>
-
- -

Each of these elements can be configured using the following procedures.

- -

- The user-prefix is an arbitrary string. It defaults to the username of - the currently connected user, but can be set (and returned) using the - following: -

- -
--- Set the file prefix for a user
-PROCEDURE setuserprefix (
-   userprefix_in IN VARCHAR2 := NULL, 
-   username_in   IN VARCHAR2 := NULL
-);
-
--- Get the file prefix for a user
-FUNCTION userprefix (username_in IN VARCHAR2 := NULL) RETURN VARCHAR2;
-
- -

- The program-name is the name of the tested program, or the test suite - being run. By default, this is element is not used in the generated filename. - To turn this on or off (and to determine the current setting), use the - following: -

- -
--- Set the include program name flag for a user
-PROCEDURE setincludeprogname (
-   incname_in  IN BOOLEAN := FALSE, 
-   username_in IN VARCHAR2 := NULL
-);
-
--- Get the include program name flag for a user
-FUNCTION includeprogname (username_in IN VARCHAR2 := NULL) RETURN BOOLEAN;
-
- -

- The date element of the filename is simply SYSDATE converted to a string. - The default format is 'YYYYDDMMHH24MISS', but this can be set (and - returned) using the following: -

- -
--- Set the date format for a user
-PROCEDURE setdateformat (
-   dateformat_in IN VARCHAR2 := 'yyyyddmmhh24miss', 
-   username_in   IN VARCHAR2 := NULL
-);
-          
--- Get the date format for a user
-FUNCTION dateformat (username_in IN VARCHAR2 := NULL) RETURN VARCHAR2;
-
- -

- The final element of the filename that can be configured is the extension. - This defaults to ".UTF" but can be set (and returned) using the following: -

- -
--- Set the file extension for a user
-PROCEDURE setfileextension (
-   fileextension_in IN VARCHAR2 := '.UTF', 
-   username_in IN VARCHAR2 := NULL
-);
-
--- Get the file extension for a user
-FUNCTION fileextension (username_in IN VARCHAR2 := NULL) RETURN VARCHAR2;
-
- -

- Note The initial dot must be included, otherwise there will be none - in the resulting filename! -

- -

Setting all the parameters at once

- -

- It is possible to set all the file output parameters at once using the - following procedure: -

- -
-PROCEDURE setfileinfo ( 
-   dir_in           IN VARCHAR2 := NULL,
-   userprefix_in    IN VARCHAR2 := NULL, 
-   incname_in       IN BOOLEAN  := FALSE,     
-   dateformat_in    IN VARCHAR2 := 'yyyyddmmhh24miss', 
-   fileextension_in IN VARCHAR2 := '.UTF',
-   username_in      IN VARCHAR2 := NULL
-);
-
- -

- To get back all of the file output parameters simultaneously, use the - following function: -

- -
-FUNCTION fileinfo (username_in IN VARCHAR2 := NULL) RETURN rec_fileinfo;
-
- -

- The record type rec_fileinfo is defined in the utConfig - package and has one field for each of the parameters. -

- -

< Previous Section: Custom Reporter Packages | Next Section: Release Notes >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/fourstep.html b/docs/fourstep.html deleted file mode 100644 index 26f4ac8..0000000 --- a/docs/fourstep.html +++ /dev/null @@ -1,660 +0,0 @@ - - - - - - - - - - - The Four Step Program to using utPLSQL - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Glossary and Requirements | Next Section: Administrative Topics >

- - -

The Four Step Program to Using utPLSQL

- -

Step 1. Install utPLSQL.

- -

Step 2. Choose a program to test and identify the test cases.

- -

Step 3. Build a test package.

- -

Step 4. Run your test.

- -

A note on which schemas to use

- -

- - - - Where to go from here -

- -

Step 1. Install (and Upgrade) utPLSQL.

- -

- Note: if you have already installed a previous version of - utPLSQL, you will use these same steps to perform your install. The - installation procedure does not remove any objects, such as tables, - prior to installation. If you wish to install a fresh copy of utPLSQL, and not upgrade - over the existing installation, please follow the steps below for removing - utPLSQL. -

- -

- Connect via SQL*Plus to the session that will own the - utPLSQL components. If you do not already have a schema defined, then you must - create it. The utPLSQL schema must have the authority to: -

- - - -

- If you like, you can install utPLSQL into the SYSTEM schema, which will avoid the need to create - a new user. However, you may prefer to keep everything in a separate place. - The following is an example script submitted by Bill Pribyl, which creates a user "UTP" with sufficient privileges - to install utPLSQL. Obviously it is only an example and will need to be changed for your environment: -

- -
-connect system/manager
-create user utp identified by utp default tablespace
-  users temporary tablespace temp;
-
-grant create session, create table, create procedure,
-  create sequence, create view, create public synonym,
-  drop public synonym to utp;
-
-alter user utp quota unlimited on users;
-
- -

- Note If the schema in question does not have the ability to create - and drop public synonyms or execute privilege on DBMS_PIPE, you may get - error messages when installing. However, utPLSQL will still function - correctly. -

- -

- Once you have connected to the schema, run the ut_i_do.sql - file with the parameter "install" to install all utPLSQL objects. You should ensure that - the working directory of your SQL*Plus - session is the directory holding the utPLSQL files, then issue this as follows: -

- -
-SQL> @ut_i_do install
-
- -

- This file will create all tables, packages and other objects needed. - Note that the installation script - creates some files dynamically using the SPOOL command. For this reason, it is - necessary that you have write permission in the directory. -

- -

To check the installation of utPLSQL, examine the ut_i_install.log file.

- -

Removing utPLSQL

- -

- To de-install the product, run the ut_i_do.sql - script again, but with the parameter "uninstall", as in: -

- -
-SQL> @ut_i_do uninstall
-
- -

Step 2. Choose a program to test and identify the test cases.

- -

- You may want to test a single stand-alone procedure or - function, or a set of programs in a package. Pick the program and then come up - with the set of different cases you want to test. This data will determine what - kind of and how many tests you run for your program. -

- -

- Suppose, for example, that I have created a stand alone function called - betwnStr (a variation on SUBSTR that returns a sub-string based on a starting - and ending location) that is stored in betwnstr.sf (1): -

- -
-CREATE OR REPLACE FUNCTION betwnStr (
-   string_in IN VARCHAR2,
-   start_in  IN INTEGER,
-   end_in    IN INTEGER
-)
-RETURN VARCHAR2
-IS
-BEGIN
-   RETURN (
-      SUBSTR (
-         string_in,
-         start_in,
-         end_in - start_in + 1
-      )
-   );
-END;
-
- -

- To test this function, I will want to pass in a variety of - inputs, as shown in this table: -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

Start

-
-

End

-
-

Result

-
-

NULL

-
-

NOT NULL

-
-

NULL

-
-

NOT NULL

-
-

NULL

-
-

NULL

-
-

NULL

-
-

NULL

-
-

NULL

-
-

3 (positive number)

-
-

1 (smaller positive number)

-
-

NULL

-
-

3 (positive number)

-
-

100 (larger than length of string)

-
-

Remainder of string from 3

-
- -

So now I know what I want to test and how I want to test it.

- -

Step 3. Build a test package.

- -

- utPLSQL offers an easy, automated way to run your tests. To - work automatically, though, you have to follow some rules so that utPLSQL can - find and execute your test code. Here are the rules: -

- -

The test code must be placed inside a test package.

- -

- The test package specification should - be stored in a file named ut_<program>.pks and the body must be stored in - a file named ut_<program>.pkb (by following this naming convention, - utPLSQL can be set to automatically recompile your test package before each - test). -

- -

- The test package must contain a setup procedure called ut_setup and a teardown procedure called ut_teardown, neither of - which take any arguments. -

- -

- The test package should have a separate procedure for each program to be - tested in this package. -

- -

- Now, you should know that there are a number of bells and - whistles in utPLSQL that allow you to change many default values (such as the - prefixes used for the setup, teardown and test procedures) and behavior of the - utPLSQL packages. While you are "Getting Started", however, we will - rely completely on the defaults and get you up and testing ASAP. -

- -

- So if I am going to test the stand-alone procedure, betwnstr, my test - package specification, saved in ut_betwnstr.pks(1), - will look like this: -

- -
-CREATE OR REPLACE PACKAGE ut_betwnstr
-IS
-   PROCEDURE ut_setup;
-   PROCEDURE ut_teardown;
-   
-   PROCEDURE ut_betwnstr;
-END ut_betwnstr;
-/
-
- -

- Now let's build the package body, saved in ut_betwnstr.pkb(1). In this very simple - case, I don't have to set up any data structures and I do not, therefore, have - to tear anything down. My teardown procedure can be empty (but it must - be present). So I have: -

- -
-CREATE OR REPLACE PACKAGE BODY ut_betwnstr
-IS
-   PROCEDURE ut_setup IS
-   BEGIN
-      NULL;
-   END;
-   
-   PROCEDURE ut_teardown
-   IS
-   BEGIN
-      NULL;
-   END;
-
- -

- Time to build the unit test procedure. To do this, I need to - go back to my grid of test cases and translate those sets of data inputs and - results into calls to programs in the utAssert - package. -

- -

- utAssert offers a number of "assertion routines" that test the - values or expression you pass to them and then record the results in utPLSQL. - You can, with utAssert, test for equality between two strings or files or - tables or collections. You can test to see if an expression evaluates to NULL. - I can use both of these types of assertions (equality and IS NULL) for my test - cases, which I repeat below: -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

Start

-
-

End

-
-

Result

-
-

NULL

-
-

NOT NULL

-
-

NULL

-
-

NOT NULL

-
-

NULL

-
-

NULL

-
-

NULL

-
-

NULL

-
-

NULL

-
-

3 (positive number)

-
-

1 (smaller positive number)

-
-

NULL

-
-

3 (positive number)

-
-

100 (larger than length of string)

-
-

Remainder of string

-
- -

- Here's how it works: for each test case, I provide a string description of - the case, then the expression I want to evaluate. Let's start with - "typical valid usage". I pass a string "abcdefg", a start - location of 3 and end location of 5, and betwnstr should return - "cde". I express that in my unit test procedure as follows: -

- -
-PROCEDURE ut_betwnstr IS
-BEGIN
-   utAssert.eq (
-      'Typical valid usage',
-      BETWNSTR(
-         STRING_IN => 'abcdefg',
-         START_IN => 3,
-         END_IN => 5
-      ),
-      'cde'
-   );
-
- -

- Notice that I call utAssert.eq because I want to compare the - value returned by betwnstr with the string "cde". They should - be equal. -

- -

- I can now write another call to a utAssert program for each of my cases. In - this very next example, I call utAssert.isnull, because I am expecting betwnstr - to return a NULL value. -

- -
-      utAssert.isnull (
-         'NULL start',
-         BETWNSTR(
-            STRING_IN => 'abcdefg',
-            START_IN => NULL,
-            END_IN => 5
-         )
-      );
-      
-      utAssert.isnull (
-         'NULL end',
-         BETWNSTR(
-            STRING_IN => 'abcdefg',
-            START_IN => 2,
-            END_IN => NULL
-         )
-      );
-      
-      utAssert.isnull (
-         'End smaller than start',
-         BETWNSTR(
-            STRING_IN => 'abcdefg',
-            START_IN => 5,
-            END_IN => 2
-         )
-      );
-      
-      utAssert.eq (
-         'End larger than string length',
-         BETWNSTR(
-            STRING_IN => 'abcdefg',
-            START_IN => 3,
-            END_IN => 200
-         ),
-         'cdefg'
-      );
-
-   END ut_BETWNSTR;
-   
-END ut_betwnstr;
-/
-
- -

- I have now created my unit test program for the betwnstr - function. I will compile both these files to make sure there are no compile - errors: -

- -
-SQL> @ut_betwnstr.pks
-
-Package created.
-
-SQL> @ut_betwnstr.pkb
-
-Package body created.
-
- -

- Note: when you run your test, utPLSQL will by default - attempt to recompile your test package to ensure that the latest changes are - incorporated into the test. It is still worth doing an initial compile to make - sure you built your test properly. You will also need to make sure that UTL_FILE is installed and configured so that your - test package files can be read and compiled by utPLSQL. -

- -

- So with the test package in place and compiling, now let's - see how we go about running the test. -

- -

Step 4. Run your test.

- -

- You've built your code, you've built your test package, - you've compiled that test package. Now it's time to run the test. Start up - SQL*Plus and connect to the schema owning the code you want to test. -

- -

- Then run your test package within the utPLSQL testing framework by calling utPLSQL.test: -

- -
-SQL> exec utplsql.test ('betwnstr', recompile_in => FALSE)
-
- -

- That second parameter in the call to utplsql.test, - "recompile_in => FALSE", tells utPLSQL that you have already - compiled your test package. You can also have utPLSQL automatically recompile your test package - each time you run a test. -

- -

- If the test does not find any errors (which means that the assertion - programs did not detect any conflicts), you will see this output: -

- -
-SQL> exec utplsql.test ('betwnstr', recompile_in => FALSE)
-SUCCESS: "betwnstr"
-
- -

If the test detected a failure, you will see output along these lines:

- -
-SQL> exec utplsql.test ('betwnstr', recompile_in => FALSE)
-FAILURE: "betwnstr"
-BETWNSTR: IS NULL: NULL start
-BETWNSTR: End larger than string length; expected "cdeg", got "cdefg"
-
- -

- As you can see, utPLSQL tells you the description of the - test case that failed, and also shows you as much as it can about what caused - the failure. -

- -

- You have now successfully installed utPLSQL, written a test package and run - your test! -

- -

Automatic Recompilation of Test Package

- -

- utPLSQL will, by default, attempt to recompile your test package code - (which must be put in two files <name>.pks for the package specification - and <name>.pkb for the package body). This of course assumes that the files - are situated on the same machine as your database. If this is not the case, you can - turn off this functionality by calling utConfig.autocompile - as follows: -

- -
-utConfig.autocompile(false);
-
- -

- If you do wish to use this functionality, utPLSQL needs - the UTL_FILE package provided by Oracle to read the source code files and then - compile the code found in those files. Before using UTL_FILE you must configure it for use from within PL/SQL. - Once you have confirmed that UTL_FILE works in your database instance, you - must tell utPLSQL where the test package is located by calling utPLSQL.setdir. - If you do not do this, then utPLSQL will not be able to recompile your test - package before each run, and instead will display an error message. -

- -

- Call the utConfig.setdir program to tell - utPLSQL the location of your source code. Suppose that I stored all my code in e:\utplsql\testall. Then I would make this - call in SQL*Plus: -

- -
-SQL> exec utplsql.setdir ('e:\utplsql\testall')
-
- -

A note on which schemas to use

- -

- In step 1, above, we described which user should own the objects which make up the utPLSQL framework. - However, there has often been confusion about which schema should contain the test packages and which schema to connect as - when running the tests. There are many ways to do it, but the simplest is as follows: -

- - -

Where to go from here

- -

- If you proceeded through all four steps, you should now have - used utPLSQL successfully to test a very simple function (betwnstr) or your own - functionality. This will undoubtedly leave you very excited about using utPLSQL - to handle much more complex code and elaborate testing requirements. -

- -

- To find out more about the different features and - functionality available in utPLSQL, visit the User - Guide. -

- -

- To read through a more thorough presentation of how to build - test packages in utPLSQL, visit How to - Build Test Packages. -

- -

- To see a wide array of examples of building test cases and - different kinds of test packages, visit the Examples - document. -

- -
- -

Footnotes

- -

1. This file is to be found in the Examples directory of the utPLSQL distribution.

- - -

< Previous Section: Glossary and Requirements | Next Section: Administrative Topics >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/glossreq.html b/docs/glossreq.html deleted file mode 100644 index 8fea7d7..0000000 --- a/docs/glossreq.html +++ /dev/null @@ -1,162 +0,0 @@ - - - - - - - - - - - Glossary and Requirements - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Getting Started | Next Section: The Four Step Program to using utPLSQL >

- - -

Glossary and Requirements

- -

Glossary

- -

- Before diving into the details, let's make sure - we have a common vocabulary. -

- -

Unit Test

- -

- A test of a single unit or program. Suppose you - have built product.total_sales, a function to calculate and return total - sales of the specified product for a given date period. You will then build - a single procedure to perform the test for that function. -

- -

Test Case

- -

- Individual cases or test scenarios for a unit test. - You will want to try out different scenarios (valid and invalid product - Ids, various date ranges, etc.). Each different combination of inputs (parameter - values) is a different test case. These are bundled up and executed within - the single unit test procedure. -

- -

Package Test

- -

- A set of unit tests which test the functionality - of all programs in a single PL/SQL package (or a single stand-alone program - unit - procedure or function). -

- -

- The way utPLSQL works today, you must define - your various tests cases and unit tests within a test package (though it - could be the same package containing the functionality). -

- -

Test Suite

- -

- A series of package tests. Obviously, any application - of non-trivial complexity will consist of multiple packages, each covering - their own area of functionality. A test suite contains a series of packages - that can then be tested in sequence by executing the test suite as a whole. -

- -

Requirements

- -

- If you are using Oracle8i or above, utPLSQL takes advantage - of a number of Oracle8i features, including autonomous transactions, invoker - rights and native dynamic SQL. utPLSQL will however still run on Oracle7 - (7.3.4 and above) and Oracle8. -

- -

Requirements for using utPLSQL include:

- - - -

Requirements for Executing Test Code

- -

- If you install and use utPLSQL from within a single schema (ie, the same schema that owns utPLSQL code and tables owns the code - you want to test, as well as the test packages), then no additional privileges are needed. -

-

- If, however, you install utPLSQL in a shared schema and then access it from other schemas, you may need to grant additional - privileges to the utPLSQL schema. utPLSQL uses dynamic PL/SQL to run the test code. It therefore requires directly granted - EXECUTE privileges on those code elements (both the code to be tested and the test packages) -- or the AUTHID CURRENT_USER - capability of Oracle8i and above. -

- -

For Oracle8i and above

-

- You do not need to grant any additional privileges, unless you want to test code owned by one schema from another schema. - In that case, you will need to grant EXECUTE to the schema from which you run your tests on both the code to be tested and the test package. -

- -

For Oracle7 and Oracle8

-

- You must grant EXECUTE to the utPLSQL schema on both the code to be tested and the test package. - These grants must be made directly and not through roles. -

- - -

< Previous Section: Getting Started | Next Section: The Four Step Program to using utPLSQL >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/howto.html b/docs/howto.html deleted file mode 100644 index 0b18602..0000000 --- a/docs/howto.html +++ /dev/null @@ -1,641 +0,0 @@ - - - - - - - - - - - How to build a test package - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Build Test Packages | Next Section: A 'Test Run' with utPLSQL >

- - -

How to build a test package

- -

Instructions

-

- To use utPLSQL, you will build a test package containing your unit tests. - This test package must conform to the API (application programmatic interface) - rules of utPLSQL, so that utPLSQL can run your tests automatically. -

- -

Every test package must have:

- -
-

- A setup procedure - register your unit test and set - up any data structures needed for testing. -

- -

- A teardown procedure - remove any data structures - created for testing. -

- -

- One or more unit test procedures - perform the - unit tests. -

-
- -

- The names you give to your test package, setup, teardown and unit test - proceedures must also follow the utPLSQL Naming Conventions. -

- -

Setup Procedure

- -

- The utPLSQL.test and utPLSQL.testsuite programs - will call the setup procedure of your test package before it runs any unit - tests. Use this procedure to define your unit tests and also initialize - any data structures needed for your units. The package specification header - for this procedure must be of this form: -

- -
-CREATE OR REPLACE PACKAGE <prefix><package>
-IS
-   PROCEDURE <prefix>setup;
-
- -

- where <prefix> is the unit test prefix and <package> - is the name of the package (or stand alone program) to be tested. The default - naming convention is that your test package and all utPLSQL programs, including - the setup procedure, have a prefix of "ut_", as in: -

- -
-CREATE OR REPLACE PACKAGE ut_<program>
-IS
-   PROCEDURE ut_setup;
-
- -

- Note: if you are using manual - registration of unit tests (which is not the default setting - and is not recommeded), see Naming Conventions - for details on when and how to apply prefixes to your package and procedure - names. -

- -

- Now let's take a look at the body/implementation - of the setup procedure and how you can use it to define test data structures - and, optionally, register unit tests. -

- -

Define test data structures

- -

- You should use the setup procedure to define data structures you - need in one or more of your tests. You might, for example, want to create - a temporary table to hold information for comparison. You might populate - a collection or a record a scalar global variable. -

- -

- Here is an example of such a procedure (see the file ut_te_employee.pkb - in the Examples directory of the utPLSQL distribution for the full implementation): -

- -
-PROCEDURE ut_setup
-IS
-BEGIN
-   ut_teardown;
-
-   EXECUTE IMMEDIATE 'CREATE TABLE ut_employee AS
-         SELECT * FROM employee';
-
-   EXECUTE IMMEDIATE 'CREATE TABLE ut_DEL1 AS
-         SELECT * FROM employee';
-
-   EXECUTE IMMEDIATE 'CREATE TABLE ut_DELBY_EMP_DEPT_LOOKUP AS
-         SELECT * FROM employee';
-END;
-
- -

- For each of my tests, I create a separate table to modify and then use - in my utAssert comparison. -

- -

- You could place these statements in each of the individual unit test - procedures. The advantage of storing them all in the single setup procedure - is that they are easier to manage -- and also easier to tear down or destroy - when you are done. -

- -

Manual registration of unit tests

- -

- If you have decided to choose manual - registration of your unit test procedures, then you will need to register - each procedure with a call to utPLSQL.registertest - in the setup procedure. This is not recommended. But if you insist... -

- -

- Here is an example of a setup procedure for the - PLVdate package: -

- -
-CREATE OR REPLACE PACKAGE BODY ut_plvdate
-IS
-   PROCEDURE ut_setup
-   IS
-   BEGIN
-      utplsql.addtest ('ut_to_date');
-      utplsql.addtest ('ut_to_char');
-   END;
-
- -

- The names passed to the utPLSQL.addtest procedure - must match the interface of the defined unit test procedures - with the following interface. So the above two calls to addtest tell utPLSQL - to look for two unit test procedures named ut_to_date and ut_to_char. -

- -

Teardown Procedure

- -

- The utPLSQL.test and utPLSQL.testsuite programs - will call the teardown procedure of your test package after it runs all - unit tests. Use this procedure to destroy or remove any data structures - that were needed for your units. The contents of this procedure should, - in general, be the logical reverse of the contents of the setup - procedure. The package specification header for this procedure must - be of this form: -

- -
-CREATE OR REPLACE PACKAGE <prefix><package>
-IS
-   PROCEDURE <prefix>teardown;
-
- -

- where <prefix> is the unit test prefix and <package> - is the name of the package (or stand alone program) to be tested. -

- -

- The default naming convention is that your test - package and all utPLSQL programs, including the teardown procedure, have - a prefix of "ut_", as in: -

- -
-CREATE OR REPLACE PACKAGE ut_<program>
-IS
-   PROCEDURE ut_teardown;
-
- -

- Note: if you are using manual - registration of unit tests (which is not the default setting - and is not recommeded), see Naming Conventions - for details on when and how to apply prefixes to your package and procedure - names. -

- -

- Now let's take a look at the body/implementation - of the teardown procedure and how you can use it to remove test data structures. -

- -

- Here is an example of the most common type of teardown - procedure -- it does nothing: -

- -
-CREATE OR REPLACE PACKAGE ut_sales_pkg
-IS
-   PROCEDURE teardown
-   IS
-   BEGIN
-      NULL;
-   END;
-
- -

- This is what your teardown procedure will look like - when you do not need to create any special data structures for your tests. - If I were testing a simple string utility, for example, I do not need a - database table or collection to run my tests. Note that even if your teardown - procedure does nothing, it still must be present in the package specification - and body. utPLSQL will look for and try to execute the procedure as - part of its S.O.P. (standard operating procedure). -

- -

- Now, if your setup procedure creates something, - you should probably destroy it in teardown. You might drop or truncate - tables, do a ROLLBACK or simply make sure files and cursors are closed. - Here is an example of such a procedure: -

- -
-PROCEDURE teardown
-IS
-BEGIN
-   mycollection.DELETE;
-   EXECUTE IMMEDIATE 'TRUNCATE TABLE ' || workspace_tab;
-   DBMS_SESSION.FREE_UNUSED_USER_MEMORY;
-END;
-
- -

The Unit Test Procedure

- -

- The unit test procedure is, of course, where it - gets really interesting and very application specific. -

- -

The general format for a test procedure is as follows:

- -
-CREATE OR REPLACE PACKAGE <prefix><package>
-IS
-   PROCEDURE <prefix><program>;
-
- -

- where <prefix> is the unit test prefix and <package> - is the name of the package (or stand alone program) to be tested. The default - naming convention is that your test package and the unit test procedure - each have a prefix of "ut_". You can override that prefix with another - of your own choosing in your call to utPLSQL.test - or utPLSQL.testsuite. Under some circumstances, you can drop - the prefix on the unit test procedure, but this is not recommended. see - Naming Conventions. for details. -

- -

- Here is a very generic version of a unit test package - specification and a single unit test procedure: -

- -
--- Test package for stand alone program
-CREATE OR REPLACE PACKAGE ut_<package>
-IS
-   PROCEDURE ut_setup;
-   PROCEDURE ut_teardown;
-   PROCEDURE ut_<program>;
-END;
-
- -

- The body of your unit test procedure is, well, mostly - yours to figure out, since we don't know what you are testing and how you - need to test it. The basic format of this test procedure, however, should - be: -

- -
-PROCEDURE <myprogram>
-IS
-BEGIN
-   <run package.myprogram or set up for test>
-
-   -- call a utAssert assertion to check results:
-   utAssert.<assertion> (...);
-
-   <repeat of the above for different test cases>
-EXCEPTION
-   WHEN OTHERS
-   THEN
-      utAssert.this (
-         'Unknown failure of <package.myprogram>: ' || SQLERRM,
-         FALSE);
-END;
-
- -

- You should include a call to a utAssert assertion program in the exception - section to trap unexpected errors and register a test failure (I pass FALSE - for the second argument, which guarantees a failure!). You might, of course, - have other handlers to trap specific exceptions like NO_DATA_FOUND and - either register a failure or ignore the exception, since it might not be - an actual test failure. -

- -

- Here is an example of a unit test procedure that contains multiple calls - to assertion programs for different test cases. -

- -
-PROCEDURE ut_BETWNSTR IS
-BEGIN
-   utAssert.eq (
-      'Typical valid usage',
-      BETWNSTR(
-         STRING_IN => 'abcdefg',
-         START_IN => 3,
-         END_IN => 5
-      ),
-      'cde'
-   );
-      
-   utAssert.isnull (
-      'NULL start',
-      BETWNSTR(
-         STRING_IN => 'abcdefg',
-         START_IN => NULL,
-         END_IN => 5
-      )
-   );
-
-   utAssert.isnull (
-      'NULL end',
-      BETWNSTR(
-         STRING_IN => 'abcdefg',
-         START_IN => 2,
-         END_IN => NULL
-      )
-   );
-      
-   utAssert.isnull (
-      'End smaller than start',
-      BETWNSTR(
-         STRING_IN => 'abcdefg',
-         START_IN => 5,
-         END_IN => 2
-      )
-   );
-      
-   utAssert.eq (
-      'End larger than string length',
-      BETWNSTR(
-         STRING_IN => 'abcdefg',
-         START_IN => 3,
-         END_IN => 200
-      ),
-      'cdefg'
-   );
-      
-END ut_BETWNSTR;
-
- -

- In the above case, I am testing a function, so I call the function "in - line" with the assertion program. When testing a procedure, you will call - the procedure first and then call the appropriate assertion program to - test the outcome. -

- -

- Explore the Examples to learn about different - ways to write unit test procedures. -

- -

Naming Conventions

- -

- When you execute a test or test suite, utPLSQL looks for a test package, - based on the name of the program you are testing. It then attempts to execute - specific programs within that package. utPLSQL allows you to test stand-alone - programs (procedure or function) or package-based programs. When testing - the contents of a package, you can place your unit test procedures in the - same - package or a separate test package. That's a lot of flexibility, and - flexibility generally leads to confusion. -

- -

- To make things as simple as possible, the default mode of utPLSQL follows - this simple rule: -

- -

- Your unit test package and each utPLSQL-related program in that package - (setup, teardown and unit tests) must all use the same prefix. -

- -

- The default prefix is "ut_", but you can override that with your own. - If you follow this rule (and you can follow it very easily by using the - utGen - package to generate a starting point for your test packages), utPLSQL -

- -

- If you are following the utPLSQL defaults and letting the utility automatically - detect and execute unit tests, do not read any further! -

- -

- If you choose to perform manual - registration of your unit tests, then read the following sections carefully, - as there is a scenario in which you should not apply the utPLSQL - prefix to your unit test procedures. -

- -

- This section describes the conventions or rules that utPLSQL follows - to locate and execute your unit tests. There are three different "scenarios" - to consider: -

- -

Separate test package to test package-based programs

- -

Separate test package to test a stand-alone program

- -

Single package containing both source to be tested and unit test programs

- -

- While these rules might seem confusing at first glance, you will find - over time that they are designed to make the issue of what things are named - as transparent as possible when you run your tests. In other words, you - simply ask to test "mypackage"; you don't have to run some oddly-named - program with a prefix in front of it. -

- -

- In addition, you can use the utGen package to - generate a starting point for your test packages. utGen will automatically - follow the rules; you only need to "fill in the blanks" of your unit test - procedures within the established headers. -

- -

Separate test package to test package-based programs

- -

- If you are placing your unit test code in a package separate from your - source code (the default setting), then the name of that test package must - be of the form: -

- -
-<prefix><package>
-
- -

- where <prefix> is the utPLSQL prefix and <package> is the name of - the package containing the programs to be tested. -

- -

You specify the prefix in one of the following ways:

- - - -

- The names of the test package programs, on the other hand, should not - have a prefix before them. These prefixes are not necessary to distinguish - the test procedure with the program being tested, since they are defined - in different packages. -

- -

Separate test package to test a stand-alone program

- -

- If you are placing your unit test code in a package separate from your - source code (the default setting), then the name of that test package must - be of the form: -

- -
-<prefix><program>
-
- -

- where <prefix> is the utPLSQL prefix and <program> is the name of - the stand-alone program you plan to test. -

-

- You specify the prefix in one of the following ways: -

- - - -

- The names of the test package programs, on the other hand, also must have - the same prefix. This is necessary to avoid confusing naming conflicts - between the program you are testing and the name of the unit test procedure - for that program, as in the following package that tests the betwnstr function: -

- -
-CREATE OR REPLACE PACKAGE ut_betwnstr
-IS
-   PROCEDURE ut_setup;
-   PROCEDURE ut_teardown;
-   PROCEDURE ut_betwnstr;
-END ut_betwnstr;
-/
-
- -

- I suppose that looks odd; I have created a function named ut_betwnstr.ut_betwnstr - and it would be very strange to write code like that. But that is the whole - point of utPLSQL: I don't have to write code like that. I just run - my test with nothing more than this: -

- -
-SQL> exec utPLSQL.test ('betwnstr')
-
- -

Single package containing both source to be tested and unit test programs

- -

- Finally, there is the scenario in which a developer places all of her test - programs (setup, teardown and unit tests) in the same package as the code - to be tested. In this case, there is no separate test package, so all of - the test programs must use the utPLSQL prefix, as in: -

- -
-CREATE OR REPLACE PACKAGE str
-IS
-   FUNCTION betwn (
-      string_in IN VARCHAR2,
-      start_in IN PLS_INTEGER,
-      end_in IN PLS_INTEGER
-   )
-      RETURN VARCHAR2;
-      
-   PROCEDURE ut_setup;
-   PROCEDURE ut_teardown;
-   PROCEDURE ut_betwn;
-      
-END str;
-/
-
- -

You specify the prefix in one of the following ways:

- -
- -
- - -

< Previous Section: Build Test Packages | Next Section: A 'Test Run' with utPLSQL >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/index.html b/docs/index.html deleted file mode 100644 index 47e8e69..0000000 --- a/docs/index.html +++ /dev/null @@ -1,114 +0,0 @@ - - - - - - - - - - - Home - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

Next Section: Getting Started >

- - -

Table of Contents

- -

Welcome to utPLSQL - a unit testing framework for the Oracle PL/SQL Language

- -

Getting Started

- -
-

- This document tells you the minimum you need - to know in order to get started with utPLSQL: how to install the software, - build simple test packages, and run your tests. -

-
- -

Build Test Packages

- -
-

- utPLSQL provides with you a framework in which - to run your tests. You still have to write your test code, and that code - must follow some rules if utPLSQL is going to know how to run those tests. -

-
- -

Examples

- -
-

- There is no better way to learn how to build - and run utPLSQL test packages than to work from the many examples found - here. -

-
- -

User Guide

- -
-

- Once you are familiar with utPLSQL basics, have - run some tests, and are ready to learn and use more of the many utPLSQL - features, the User Guide will tell you all you need to know about the different - features and programs of utPLSQL. -

-
- -

Release Notes

- -
-

- Well, you know what these are: a description - of fixes and enhancements in the latest release! -

-
- -

Document Map

- -
-

The full list of the pages in the documentation

-
-

Web Site

-

- https://utplsql.github.io/ Contains links to various resources such as: -

-

- - -

Next Section: Getting Started >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 0000000..eb9dedc --- /dev/null +++ b/docs/index.md @@ -0,0 +1,36 @@ +

utPLSQL - Testing Framework for PL/SQL

+ +

utPLSQL - Testing Framework for PL/SQL

+ +The ultimate unit testing framework for Oracle PL/SQL. + +Free, open-source, and inspired by the xUnit family (JUnit, NUnit, etc.). + +Write and run tests directly in PL/SQL, integrate with your CI/CD pipeline, and verify your code stability with every build. + +!!! tip "Latest News" + Stay up to date with releases and project updates on the [Announcements](announcements/index.md) page. + +--- + +## Get Started + +- [Documentation](documentation.md) — installation, configuration, writing tests +- [Downloads](downloads.md) — latest releases and changelogs + +--- + +## Frameworks and tools + +{% + include-markdown "https://raw.githubusercontent.com/utPLSQL/.github/main/profile/README.md" + rewrite-relative-urls=false + start="" + end="" +%} + +--- + +## Community + +Have a question or idea? Start a [discussion on GitHub](https://github.com/orgs/utPLSQL/discussions) — it's the best place to ask for help, share feedback, or propose new features. diff --git a/docs/map.html b/docs/map.html deleted file mode 100644 index 519f611..0000000 --- a/docs/map.html +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - - - - - - Document Map - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Release Notes

-

Document Map

-

Home

Getting Started

  Glossary and Requirements

  The Four Step Program to using utPLSQL

  Administrative Topics

Build Test Packages

  How to build a test package

  A 'Test Run' with utPLSQL

Examples

  Test a Procedure

  Test a Function

  Test an Entire Package API

  Put Test Code in Same Package

  Use Non-Default Prefix

  Create and Run a Test Suite

User Guide

  utPLSQL Package

  utConfig Package

  utResult Package

  utAssert Package

  utGen Package

  utOutput Package

  utRecEq Package

  Defining Test Suites

  Custom Reporter Packages

  Configuring the File Reporter

Release Notes

Document Map

< Previous Section: Release Notes

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/overrides/main.html b/docs/overrides/main.html new file mode 100644 index 0000000..58b36cc --- /dev/null +++ b/docs/overrides/main.html @@ -0,0 +1,27 @@ +{% extends "base.html" %} +{# + Org-site template override (utPLSQL.github.io). + Loads the same shared topbar as all sub-sites — single source of truth in topbar.js. +#} + +{% block extrahead %} + {{ super() }} + + +{% endblock %} diff --git a/docs/prefix.html b/docs/prefix.html deleted file mode 100644 index 8b3fac1..0000000 --- a/docs/prefix.html +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - - - - - Use Non-Default Prefix - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Put Test Code in Same Package | Next Section: Create and Run a Test Suite >

- - -

Use Non-Default Prefix

- -

- The default prefix for utPLSQL is "ut_", but you don't have to use that - prefix. There are some situations where you absolutely will not want to - use the default prefix. Suppose, for example, that you have written a package - with ten procedures, each of which already have "ut_" as a prefix - (it might stand for "Unified Technologies" or "Underside Treatment: or...well, - you get the picture). -

- -

- Since this prefix is not hard-coded into utPLSQL, you can very easily - specify your own prefix. You can do this when you run a test, as in: -

- -
-SQL> utPLSQL.test ('te_employee', prefix_in => 'test_');
-
- -

You can also specify a prefix when you add a package to a test suite, as in:

- -
-SQL> utPackage.add ('mysuite', 'mypackage' prefix_in => 'test_');
-
- -

- Of course, when you specify a non-default prefix, you must also build your - test package using that prefix. If you plan to generate a starting point - for your package with utGen, be sure to specify your prefix at that point, - as in: -

- -
-SQL> utGen.testpkg('mypackage' prefix_in => 'test_');
-
- -

- For an example of a package with a non-default prefix, check out test_te_employee.pks - and test_te_employee.pkb (Both to be found in the Examples directory of the utPLSQL distribution). -

- - -

< Previous Section: Put Test Code in Same Package | Next Section: Create and Run a Test Suite >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/release.html b/docs/release.html deleted file mode 100644 index 1e41373..0000000 --- a/docs/release.html +++ /dev/null @@ -1,725 +0,0 @@ - - - - - - - - - - - Release Notes - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Configuring the File Reporter | Next Section: Document Map >

- - -

Release Notes

- -

Known Issues

-

utPLSQL version 2.x

- - -

Change History

- -

utPLSQL version 2.3.1 (7th July 2016)

- - - - -

utPLSQL version 2.3.0 (8th February 2015)

- - - -

utPLSQL version 2.2.3 (30th August 2014)

- - - -

utPLSQL version 2.2.2 (4th May 2014)

- - - -

utPLSQL version 2.2.1 (6th April 2014)

- - - -

utPLSQL version 2.2

- - - -

utPLSQL version 2.1.1

- - - -

utPLSQL version 2.0.10.1

- - - -

utPLSQL version 2.0.9.2

- - - -

utPLSQL version 2.0.9.1

- - - -

utPLSQL version 2.0.8.2

- - - -

utPLSQL version 2.0.8.1

- - - -
-SQL> exec utplsql.test ('str', per_method_setup_in => true)
-
- -

utPLSQL version 2.0.7

- - - -

utPLSQL version 2.0.6

- - - -

utPLSQL version 2.0.5

- - - -

utPLSQL version 2.0.4

- - - -

utPLSQL version 2.0.3

- - - -

utPLSQL version 2.0.2

- - - -

utPLSQL version 2.0.1

- - - -

utPLSQL version 1.5.6

- - - -

utPLSQL version 1.5.5

- -

Bug Fixes

- - - -

Enhancements

- - - -

utPLSQL version 1.5.4

- -

Bug Fixes

- - - -

utPLSQL version 1.5.3

- -

Documentation and Usage Changes

- - - -

Bug Fixes

- - - -

Enhancements

- - - -

utPLSQL version 1.5.2

- -

Bug Fixes

- - - -

Known Problems

- - - -

Enhancements

- - - -

utPLSQL version 1.5.1

- -

Support for Oracle7.3, Oracle8 and Oracle8i

- -

- utPLSQL can now be used on any version of Oracle from 7.3.4 and above! The - installation script automatically detects your Oracle RDBMS version and adjusts - the code accordingly (Using a great SQL*Plus trick, courtesy of Vladimir - Trusevich; check out the references to &start81 and &start73 in the - source code, as well as the queries in code.sql, to get a sense of how we - can maintain a single base of code for all these versions!). -

- -

There are some differences in how the code works:

- - - -

- In Oracle8i, the Invoker Rights model is used to allow all of utPLSQL code - to run under the authority of the invoker, not the owner/definer. In earlier - versions, the Definer Rights model is followed. So if you define utPLSQL - in a central schema and then share it with others via GRANTs and synonyms, - you may need to grant additional authority to the utPLSQL schema. -

- - -

Stores Additional Configuration Information

- -

- When you set the directory for your test code (through a call to - utPLSQL.setdir - , utPLSQL.test or utPLSQL.testsuite), that value is stored in the uPLSQL - configuration table (ut_config). It will be used for current and future sessions - as the default, until you change it. -

- -

- The prefix you specify in calls to utPLSQL.setprefix - , utPLSQL.test or utPLSQL.testsuite will also be saved in the uPLSQL configuration - table. It will be used for current and future sessions as the default, until - you change it. -

- -

Shows All Configuration Information

- -

- Call the utPLSQL.showconfig - procedure to display all of the stored configuration values for the specified - schema. -

- -

utPLSQL version 1.4.1

- -

Automatic Test Registration

- -

- You no longer have to manually register - your unit test procedures - in the setup procedure. Instead, utPLSQL will (in default mode) read and - execute the list of public procedures and functions from the ALL_ARGUMENTS - data dictionary view that conform to utPLSQL naming conventions. This enhancement - makes utPLSQL much easier and simpler to use than before. Simply use the - designated prefix (default being "ut_") on your program names, and they will - be executed. -

- -

Improved error handling and reporting

- -

Rather than display a small, easily missed test result, as in :

- -
-SUCCESS: PLVstr
-
- -

- utPLSQL now displays a much more noticeable (though still lacking in - colors, as in red for failure and green for success) display of the "big - picture", as in: -

- -
-SQL> exec utplsql.test ('str', dir_in=>'e:\openoracle\utplsql\utinstall\examples')
-.
->    SSSS   U     U   CCC     CCC   EEEEEEE   SSSS     SSSS
->   S    S  U     U  C   C   C   C  E        S    S   S    S
->  S        U     U C     C C     C E       S        S
->   S       U     U C       C       E        S        S
->    SSSS   U     U C       C       EEEE      SSSS     SSSS
->        S  U     U C       C       E             S        S
->         S U     U C     C C     C E              S        S
->   S    S   U   U   C   C   C   C  E        S    S   S    S
->    SSSS     UUU     CCC     CCC   EEEEEEE   SSSS     SSSS
-.
- SUCCESS: "str"
-
- -

utPLSQL version 1.3.2

- -

Improved Statistics Recording

- -

- utPLSQL will now record the status of the last test run in the ut_package - and ut_suite tables. It also correctly updates those tables with a count - of executions and failures. Finally, it is no longer necessary to define - your package in and run it from a test suite for results to be recorded. -

- -

New Assertions and Assertion Features

- -

- utAssert now offers assertion routines that allow you to easily validate - the contents of PL/SQL collections (index-by tables, nested tables and varying - arrays) by running either the utassert.eqcoll - or utassert.ecollAPI - assertions. -

- -

- You can also now request that utAssert show the - results of a test immediately - after execution. This allows you to build small test scripts without have - to create a test package and run it through the utPLSQL test engine. -

- -

Bug Fixes

- -

- Generally, error handling is now improved, particularly for compile errors - on test packages and modifications to underlying tables, such as ut_package. -

- -

- When a test has been completed, utPLSQL clears out the results information. -

- - -

< Previous Section: Configuring the File Reporter | Next Section: Document Map >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/reporter.html b/docs/reporter.html deleted file mode 100644 index c5b9bba..0000000 --- a/docs/reporter.html +++ /dev/null @@ -1,274 +0,0 @@ - - - - - - - - - - - Custom Reporter Packages - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Defining Test Suites | Next Section: Configuring the File Reporter >

- - -

Custom Reporter Packages

-

- Generally, the default output provided by utPLSQL is sufficient. This - just writes to the screen using DBMS_OUTPUT. If you are running it - interactively while doing some development, you just need to know if the - tests are passing and details of the failing tests. However, there are - cases where you'd like the results to be reported in a different format, - especially when the tests are being run in batch mode. To support this, - utPLSQL has the concept of Reporter Packages. utPLSQL is distributed with - the following reporter packages as standard: -

- - - -

- The naming convention is that reporter packages are called - UT<NAME>REPORTER. To set which reporter is used, you will - need to call utConfig.Setreporter, passing the name of the reporter. - To use the HTML reporter for example, you should issue the following command: -

- -
-BEGIN
-   utConfig.setreporter('HTML');
-END; 
-
- -

- For more details of how to develop your own custom - reporter package, see below. -

- -

Output Reporter

- -

- Contained in the UTOUTPUTREPORTER package, this simply encapsulates the - standard behaviour, whereby the output is written out to DBMS_OUTPUT. When a - problem occurs with another reporter, utPLSQL will automatically fall back on - this mechanism to report problems. This means it is wise to have DBMS_OUTPUT - enabled even if you are using another output method. -

- -

File Reporter

- -

- This reporter, contained in the UTFILEREPORTER package, writes test results - out to a file. For details on how to configure this process, see the details - which can be found here. This functionality was - available before version 2.2 of utPLSQL, but has now been moved into its own - package. -

- -

HTML Reporter

- -

- The package UTHTMLREPORTER is really just an example package to be used as - a basis for your own custom reporters. It builds on the filereporter described above to - send results to a file. The difference is that the results are presented in a (rather crude) - HTML table. -

- -

Writing your own Reporter

- -

- To define your own reporter package you need it conform to a particular API. The various - procedures are then registered as 'callbacks' for utPLSQL to use. - An example package spec is given below. -

- -
-CREATE OR REPLACE PACKAGE utMyRssReporter
-IS
-
-   PROCEDURE open;
-   PROCEDURE pl (str IN VARCHAR2);
-   
-   PROCEDURE before_results(run_id IN utr_outcome.run_id%TYPE);
-   PROCEDURE show_failure;
-   PROCEDURE show_result;
-   PROCEDURE after_results(run_id IN utr_outcome.run_id%TYPE);
-   
-   PROCEDURE before_errors(run_id IN utr_error.run_id%TYPE);
-   PROCEDURE show_error;
-   PROCEDURE after_errors(run_id IN utr_error.run_id%TYPE);   
-   
-   PROCEDURE close;
-   
-   PROCEDURE before_suite_results(suite_id IN ut_suite.id%TYPE);
-
-END utMyRssReporter;
-/
-
- -

- Your reporter package can define other functions and procedures, for - example to allow configuration, but all the procedures shown above should - be defined. The usage of these procedures follows. Note If you - want to keep the format of the output the same as for the Output Reporter, - but wish to send it elsewhere, you can define open, close and pl, but - simply call the equivalent procedure in utOutputReporter for the others. - For an example of this, see the File Reporter. -

- -

open

- -

- This is called at the very start of the process and is the ideal place to - do initialization, such as opening any files that you will be writing to. -

- -

pl

-

- This is a general routine to simply write out the given string for purposes of logging etc. - If you don't want this to show up in your output, you can simply call utoutputreporter.pl to send this to DBMS_OUTPUT instead. -

- -

before_results

- -

- As the name suggests, this is called before the results are output. Note that the tests have already completed at this point, - so it is possible to call utresult.success (run_id) to determine if the run was a success or not and display a large banner. -

- -

show_failure

- -

- This is called when a failure is reported and we are only showing failures (i.e. utconfig.showfailuresonly has been set). - To get details of the failure, you will need to examine the package level record utreport.outcome. -

- -

show_result

- -

- This is called whenever a result is reported and we are showing all - results. To get details, you will need to examine - utreport.outcome. See below for details. -

- -

after_results

-

This is called after all the results have been sent for output.

- -

before_errors

-

This is called before any errors are sent for output.

- -

show_error

-

- This is called for each error to output. To get details, you will need - to examine the package level record utreport.error. - See below for details. -

- -

after_errors

-

This is called after any errors have been sent for output.

- -

before_suite_results

-

- This is called only when a suite is executed. It displays the overall - banner and suite execution statistics. -

- -

Outcome and Error records

-

- In order to keep the API as simple as possible, many of the procedures defined above take no parameters. In particular, details of the outcome or error which - triggered the callback are not passed through to your procedure. These are stored as package level records in the utReport package as shown below. -

- -
-outcome utr_outcome%ROWTYPE;
-error utr_error%ROWTYPE;
-
- -

The important fields in the outcome record are:

- - - -

The important fields in the error record are:

- - - -

Using Your Custom Reporter

-

- To use your custom reporter, you simply call utConfig.Setreporter with the name of your reporter. So if - you have defined your reporter in the utMyRssReporter package, you need to call: -

- -
-BEGIN
-   utConfig.setreporter('MyRss');
-END; 
-
- -

- Then you just run your tests as usual and hopefully your reporter will - format the results as you expect. -

- -

Sending output to the current reporter

-

- If you wish to send output to the current reporter, for example, for logging purposes, you should call utReport.pl. - This is part of the utReport package, which acts as a facade and passes any calls through to the current reporter package. - So if you have set up a custom reporter package 'utMyRssReporter' as shown above and called utConfig.setreporter('MyRss'), - any calls such as the following: -

- -
-BEGIN
-  utReport.pl('Logging Message');
-END;
-
- -

will be equivalent to

- -
-BEGIN
-  utMyRssReporter.pl('Logging Message');
-END;
-
- - -

< Previous Section: Defining Test Suites | Next Section: Configuring the File Reporter >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/resources.md b/docs/resources.md new file mode 100644 index 0000000..f30f9a3 --- /dev/null +++ b/docs/resources.md @@ -0,0 +1,90 @@ +--- +layout: page +title: Resources +permalink: /resources/ +menuInclude: true +--- + +Do you know about videos, articles, blogs or code examples that are missing here? Please let us know! + +## Framework + +- [Latest documentation](/utPLSQL/latest/) + +#### Overview + +- [UKOUG Testing PLSQL APIs with utPLSQL v3 Webinar](https://www.youtube.com/watch?v=3IQXWdKkBP4) (by Jacek Gebal) + Comprehensive webinar about utPLSQL by Jacek Gebal. The definitive guide to why and how to test PL/SQL with utPLSQL +- [utPLSQL 3.0 - How to have your cake and eat it](https://mikesmithers.wordpress.com/2018/04/25/utplsql-3-0-how-to-have-your-cake-and-eat-it/) (by Mike Smithers) + Complete introduction to utPLSQL 3.0, covering installation, comprehensive example application, transaction challenges and even code coverage +- [Strongholds of Confidence: Self-Testing your Database](https://cleandatabase.wordpress.com/2017/10/26/strongholds-of-confidence-self-testing-your-database/) (by Samuel Nitsche) + Plea to start creating meaningful, automated self-tests and why. Finishes with a concrete utPLSQL example +- [Test Driven Development in PLSQL with utPLSQL v3 – intro](http://www.oraclethoughts.com/uncategorized/test-driven-development-in-oracle-database-with-utplsql-v3-intro/) (by Jacek Gebal) + Addresses some major struggles of developers who start with unit-testing and also gives a brief intro into Test-Driven-Development +- [Testing PL/SQL in your Ci/Cd pipeline with utPLSQL](https://www.youtube.com/watch?v=rgbAG8RgR9U) (by Blaine Carter) + Blaine demonstrates running utPLSQL unit tests in Oracle Developer Cloud and publishing test results. +- [Extending Oracle Database DevOps with Automated PL/SQL Unit Testing](https://www.youtube.com/watch?v=zFtUmAe61mg) (by Shay Shmeltzer) + Overview of running utPLSQL unit tests within Oracle Developer Cloud +- [DevOps Around Autonomous Data Warehouse](https://www.youtube.com/watch?v=AcWaYWAgOeQ) (Oracle) + A short overview of an architecture proposed for Database Software Delivery LifeCycle with automated testing and static code analysis +- [Oracle Developers Office Hours - Real World Testing of PL/SQL Code](https://www.youtube.com/watch?v=-GkzMV5lUaQ) (hosted by Steven Feuerstein) + Panel webinar with: Jasmin Fluri, Deepthi Bandari, Swathi Ambati & Maik Becker, Patrick Barel & Samuel Nitsche +- [Oracle Groundbreakers - Testing with utPLSQL](https://www.youtube.com/watch?v=OxHMaOiPitI) (by Philipp Salvisberg) + Presentation on 28th October 2020 at Oracle Groundbreakers APAC Virtual Tour +- [Oracle Developers Office Hours - Testing with utPLSQL](https://www.youtube.com/watch?v=5WGHplRgXzQ) (hosted by Connor McDonald) + Live coding and testing session with Samuel Nitsche and Jacek Gebal +- [Testing in the Imperial Database](https://www.youtube.com/watch?v=sDI8FwKzdok) (by Samuel Nitsche) + Talk from SAST Q4 Digital Testing conference +- [Testing With utPLSQL – Made Easy With SQL Developer](https://www.salvis.com/blog/2022/07/31/testing-with-utplsql-made-easy-with-sql-developer/) (by Philipp Salvisberg) +- [Database Development Champions - Programming With utPLSQL – This Is the Way](https://www.youtube.com/watch?v=LtypQEr4-5A) (by Philipp Salvisberg) + +#### Structuring Tests + +- [utPLSQL’s Suite Hierarchy in action](https://cleandatabase.wordpress.com/2018/12/16/100codeexamples-utplsqls-suite-hierarchy-in-action/) (by Samuel Nitsche) + Example of the `%suitepath` annotation and utPLSQL hierarchies +- [Narrate Star Wars Movies with utPLSQL annotations](https://cleandatabase.wordpress.com/2019/06/25/narrate-star-wars-movies-with-utplsql-annotations/) (by Samuel Nitsche) + Example how to use the different annotations that allow to structure tests (`%before`, `%after`, `%context`) +- [Testing the Deathstar security with utPLSQL contexts](https://cleandatabase.wordpress.com/2019/06/06/testing-the-deathstar-security-with-utplsql-contexts/) (by Samuel Nitsche) + Example how to use the `%context` annotation + +#### Cursor Comparison + +- [What is the equivalent of utassert eqtable / eqquery in utPLSQL v3](http://www.oraclethoughts.com/utplsql/what-is-the-equivalent-of-utassert-eqtable-utplsql-v2-v3/) (by Jacek Gebal) + Comparison between utPLSQL v2's `utassert.eqtable` and v3's `ut.expect(sys_refcursor).to_equal(sys_refcursor)` approach. +- [Unit-Tests for Primary/Secondary Lookup with Cursor Comparison](https://cleandatabase.wordpress.com/2018/12/06/100codeexamples-unit-tests-for-primary-secondary-lookup-with-cursor-comparison/) (by Samuel Nitsche) + Example how to use cursor comparison with `select from dual` expectations +- [utPLSQL Cursor Comparison with user-defined Types](https://cleandatabase.wordpress.com/2019/02/03/100codeexamples-utplsql-cursor-comparison-with-user-defined-types/) (by Samuel Nitsche) + Example how to use cursor comparison with expectations created via user-defined types +- [Test updatable views with utPLSQL Cursors](https://cleandatabase.wordpress.com/2019/03/15/100codeexamples-test-updatable-views-with-utplsql-cursors/) (by Samuel Nitsche) + Example how to easily test the updatability of a view with cursor comparison + +#### Code Talks + +- [2017 CodeTalk Series: Unit Testing PL SQL Code in the Real World](https://www.youtube.com/watch?v=1qAZvS5rvyY) +- [2018 CodeTalk Series: Practical Advice for Taking Your PL SQL Testing to the Next Level](https://www.youtube.com/watch?v=CvZOwp9pn4o) + + +## Tools + +#### utPLSQL - SQLDeveloper extension + +- [Running utPLSQL Tests in SQL Developer](https://www.salvis.com/blog/2019/07/06/running-utplsql-tests-in-sql-developer/) (by Philipp Salvisberg) + Detailed explanation how to install and use the utPLSQL-Plugin for SQLDeveloper +- [utPLSQL for SQL Developer 1.2 – What’s New?](https://www.salvis.com/blog/2020/06/07/utplsql-for-sql-developer-1-2-whats-new/) (by Philipp Salvisberg) +- [Documentation](https://github.com/utPLSQL/utPLSQL-SQLDeveloper) +- [Downloads](https://github.com/utPLSQL/utPLSQL-SQLDeveloper/releases) + +#### utPLSQL Command-line interface + +- [Documentation](https://github.com/utPLSQL/utPLSQL-cli) +- [Downloads](https://github.com/utPLSQL/utPLSQL-cli/releases) + +#### utPLSQL PLSQL-Developer plugin + +- [Documentation](https://github.com/utPLSQL/utPLSQL-PLSQL-Developer) +- [Download](https://github.com/utPLSQL/utPLSQL-PLSQL-Developer/releases) + +#### Maven-Plugin + +- [Documentation](https://github.com/utPLSQL/utPLSQL-maven-plugin) + diff --git a/docs/samepack.html b/docs/samepack.html deleted file mode 100644 index 04dfd67..0000000 --- a/docs/samepack.html +++ /dev/null @@ -1,235 +0,0 @@ - - - - - - - - - - - Put Test Code in Same Package - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Test an Entire Package API | Next Section: Use Non-Default Prefix >

- - -

Put Test Code in Same Package

- -

- In some cases (usually when your packages are small and the code you - need to write to construct your tests is also constrained), you will not - want to bother with creating a separate package to test your code. To do - this, you will put the setup, teardown and unit test procedures inside - the package specification and body. We look at two examples: -

- - - -

Testing a simple string function

-

- Suppose I have my basic sting package, containing (for now at least) just - a single function: -

- -
-/*file str.pks */
-CREATE OR REPLACE PACKAGE str
-IS
-   FUNCTION betwn (
-      string_in IN VARCHAR2,
-      start_in IN PLS_INTEGER,
-      end_in IN PLS_INTEGER
-   )
-      RETURN VARCHAR2;
-END str;
-/
-
- -

- Now it is time to test the function. I really don't want to bother with - a separate package; let's keep it together. To do this, I change the specification - to: -

- -
-CREATE OR REPLACE PACKAGE str
-IS
-   FUNCTION betwn (
-      string_in IN VARCHAR2,
-      start_in IN PLS_INTEGER,
-      end_in IN PLS_INTEGER
-   )
-      RETURN VARCHAR2;
-      
-   PROCEDURE ut_setup;
-   PROCEDURE ut_teardown;
- 
-   -- For each program to test...
-   PROCEDURE ut_betwn;
-      
-END str;
-/
-
- -

- The package body contains nothing unusual; it is the same test for str.betwn - that you can find in the Testing - a Scalar Function example. But when I execute my test, I need to tell - utPLSQL that my test code is located in the same package: -

- -
-SQL> exec utconfig.showconfig
-=============================================================
-utPLSQL Configuration for SCOTT
-   Directory: e:\openoracle\utplsql\utinstall\examples
-   Autcompile? Y
-   Manual test registration? N
-   Prefix = ut_
-=============================================================
-
-PL/SQL procedure successfully completed.
-
-SQL> exec utPLSQL.test ('str', samepackage_in => TRUE)
-.
->    SSSS   U     U   CCC     CCC   EEEEEEE   SSSS     SSSS
->   S    S  U     U  C   C   C   C  E        S    S   S    S
->  S        U     U C     C C     C E       S        S
->   S       U     U C       C       E        S        S
->    SSSS   U     U C       C       EEEE      SSSS     SSSS
->        S  U     U C       C       E             S        S
->         S U     U C     C C     C E              S        S
->   S    S   U   U   C   C   C   C  E        S    S   S    S
->    SSSS     UUU     CCC     CCC   EEEEEEE   SSSS     SSSS
-.
- SUCCESS: "str"
- 
- -

Testing the population of a collection

-

- Collections are very useful structures, but they can be difficult to analyze - and compare. utPLSQL provides the utAssert.eqColl and utAssert.eqCollAPI - programs to help you do this. -

-

- For this example, consider the fileIO package: it implements a path - feature for the UTL_FILE package. In other words, you request to open a - file and your file-opening program will search through each of the directories - in the path in sequence until it finds the file or exhausts the list. Here - is the specification of this package: -

-
-/*file filepath1.pkg */
-CREATE OR REPLACE PACKAGE fileIO
-IS
-   c_delim CHAR(1) := ';';
-   
-   dirs dirs_tabtype := dirs_tabtype ();
-   
-   -- Unit test list
-   ut_dirs dirs_tabtype := dirs_tabtype ();
-   
-   PROCEDURE setpath (str IN VARCHAR2, delim IN VARCHAR2 := c_delim);
-   FUNCTION path RETURN VARCHAR2;
-   FUNCTION pathlist RETURN dirs_tabtype;
-
-   FUNCTION open (file IN VARCHAR2, loc IN VARCHAR2 := NULL) RETURN UTL_FILE.FILE_TYPE;
-   
-   -- Unit test code in same package
-   PROCEDURE ut_setup;
-   PROCEDURE ut_teardown;
-   PROCEDURE ut_setpath;
-END;
-/
-
- -

A few things to notice about this package:

- - -

Given that, let's take a look at the implementation of the test program:

- -
-PROCEDURE ut_setpath
-IS
-BEGIN
-   /* Populate base collection */
-   ut_dirs.DELETE;
-   
-   ut_dirs.EXTEND(2);
-   ut_dirs(1) := 'c:\temp';
-   ut_dirs(2) := 'e:\demo';
-   
-   /* Call setpath to do the work */
-   setpath ('c:\temp;e:\demo');
-   
-   utAssert.eqColl (
-      'Valid double entry',
-      'fileio.dirs',
-      'fileio.ut_dirs'
-      );
-END;
-
- -

This program consists of three steps:

- -
- -
- - -

< Previous Section: Test an Entire Package API | Next Section: Use Non-Default Prefix >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/started.html b/docs/started.html deleted file mode 100644 index f768c02..0000000 --- a/docs/started.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - - - - - - Getting Started - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Home | Next Section: Glossary and Requirements >

- - -

Getting Started

- -

- This document gives you all the information you need to get started - with utPLSQL: how to install the product, build a test package and run - your test. If you are new to unit testing, you should take a few moments - to review the Glossary to familiarize yourself with the terminology. -

- -

- And it is always worthwhile reviewing requirements before installing - the software! -

- -

What is utPLSQL and what do I need?

- -
-

Glossary

- -

Requirements

-
- -

The Four Step Program to Using utPLSQL

- -
-

Step 1. Install utPLSQL.

- -

Step 2. Choose a program to test and identify the test cases.

- -

Step 3. Build a test package.

- -

Step 4. Run your test.

- -

- - Where To Go From Here -

-
- -

Administrative Topics

- -
-

Configuring UTL_FILE

- -

Join the Project Team

- -

Reporting Bugs and Enhancement Requests

- -
- -

< Previous Section: Home | Next Section: Glossary and Requirements >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/stylesheets/extra.css b/docs/stylesheets/extra.css new file mode 100644 index 0000000..7f05ab8 --- /dev/null +++ b/docs/stylesheets/extra.css @@ -0,0 +1,12 @@ +[data-md-color-scheme="default"] { + --md-primary-fg-color: #2f8bff; + --md-accent-fg-color: #1f5db0; + --md-accent-fg-color--transparent: #1f5db0; +} + +[data-md-color-scheme="slate"] { + --md-hue: 200; + --md-primary-fg-color: #2f8bff; + --md-accent-fg-color: #1f5db0; + --md-accent-fg-color--transparent: #1f5db0; +} diff --git a/docs/suite.html b/docs/suite.html deleted file mode 100644 index 7157c10..0000000 --- a/docs/suite.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - - - - - - Create and Run a Test Suite - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Use Non-Default Prefix | Next Section: User Guide >

- - -

Create and Run a Test Suite

- -

- Usually our applications are composed of multiple packages. To test - our application, we must test all of the packages. utPLSQL makes it easier - for you to do that by offering test suites. -

-

- Here is an example of a script that defines a (partial) test suite for - PL/Vision, a code library available from RevealNet - as part of its Active PL/SQL Knowledge Base: -

- -
-/*file plvision.tst */
-BEGIN
-   -- Define a test suite for PL/Vision
-   utsuite.add ('PLVision');
-   
-   -- Add packages for testing
-   utpackage.add (
-      'PLVision', 'PLVstr', dir_in => 'e:\openoracle\utplsql\examples');
-   utpackage.add (
-      'PLVision', 'PLVdate', dir_in => 'e:\openoracle\utplsql\examples');
-END;   
-/
-
- -

- This is a very simple test suite definition. I rely on all defaults, but - I specify a location for my test package code. By doing this, utPLSQL will - be able to find my test packages even if the default/current utPLSQL directory - is set to another location. -

-

- If I want to, I can also specify the order in which packages are tested - by passing a value for the seq_in argument. I can request that the test - code be looked for in the same package as the source code, and so on. Here - is a rewriting of the above sutie creation script that demonstrates these - options: -

- -
-BEGIN
-   utsuite.add ('PLVision');
-
-   utpackage.add ('PLVision',
-      'PLVstr',
-      dir_in => 'e:\openoracle\utplsql\examples',
-      seq_in => 1,
-      samepackage_in => TRUE
-   );
-
-   utpackage.add ('PLVision',
-      'PLVdate',
-      dir_in => 'e:\openoracle\utplsql\examples',
-      seq_in => 2,
-      samepackage_in => TRUE
-   );
-END;
-/
- - -

< Previous Section: Use Non-Default Prefix | Next Section: User Guide >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/testapi.html b/docs/testapi.html deleted file mode 100644 index de3bc7d..0000000 --- a/docs/testapi.html +++ /dev/null @@ -1,361 +0,0 @@ - - - - - - - - - - - Test an Entire Package API - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Test a Function | Next Section: Put Test Code in Same Package >

- - -

Test an Entire Package API

- -

- Most packages consist of lots more than a single program, and you will - generally want to test each and every of the programs listed in the package - specification. When you generate a test package with utGen, - it will produce a template unit test procedure for each program in the - package specification. You will then need to modify each of these programs. -

-

- One example of this more complex package structure is the table encapsulation - package. This kind of package establishes a layer of code and therefore - control between application requirements and underlying data structures. - While the building of such a layer is uncommon in the world of PL/SQL developers, - it is strongly recommended practice. A variety of tools, in fact, offer - automated table encapsulation package generation, including Oracle - Designer, RevealNet's PL/Generator - and a variety of IDE (integrated development environment) tools. -

-

- Suppose, then, that I used PL/Generator to generate a table encapsulation - package for the employee table. It would look like the code found in te_employee.pks - and te_employee.pkb(1) (being rather - lengthy, we will not reproduce it in the documentation. If you take a look, - you will see that their are dozens of programs in the API, which means - that you would have lots of work to do in building your unit test cases. - In addition, many of the programs will be performing DML operations (updating, - deleting, inserting). How you can easily and dependably test those programs? -

-

- When you are dealing with lots of programs that have a uniform structure - and behavior (which should be the case if you are building table - API packages), then you should look for ways to generate, rather - than write manually, your test package. utGen cannot do this generation - work for you, since the logic in your encapsulation package is specific - to your environment. -

-

- You can, instead, build your own custom generator or use an existing - generator that is sufficiently flexible to meet your needs. The original - creator of utPLSQL, Steven Feuerstein, - has also been working on generator utilities for a number of years. One - of these utilities, currently "code named" GenX, came in very handy for - creating a test package for his PL/Generator-generated encapsulation packages. -

-

- Using CGML (Code Generation Markup Language), Steven created a template - (See te_utpkg.gdr in the Examples directory of the utPLSQL distribution) - that reads information from the data dictionary and defines the setup, - teardown and at least a good starting point for the unit test procedures. - Here is the template logic for the setup procedure: -

-
-   PROCEDURE {utprefix}setup
-   IS
-   BEGIN
-      -- Clean start
-      {utprefix}teardown;
-[ASIS]   
-      -- Generic copy of base table for testing 
-      EXECUTE IMMEDIATE 
-         'CREATE TABLE {tabprefix}[objname] AS
-            SELECT * FROM [objname]';
-            
-[ENDASIS]   
-   [FOREACH]prog
-   [IF]{allprogs}[EQ]Y[OR][progname][LIKE]UPD%[OR][progname][LIKE]INS%[OR][progname][LIKE]DEL%
-      -- Create copy of base table for this unit test.
-      EXECUTE IMMEDIATE 
-         'CREATE TABLE ^{progtab}^ AS
-[ASIS]   
-            SELECT * FROM [objname]';
-[ENDASIS]   
-            
-   [ENDIF]
-   [ENDFOREACH]
-   END;
-
- -

- You are not, of course, expected to understand all the logic and syntax - in this fragment. If you are interested in pursuing these sorts of genreation - opportunities and would like to check out GenX, drop a note to Steven - Feuerstein. -

-

- Here is a portion of the generated logic (found in ut_te_employee.pks - and ut_te_employee.pkb"(1)), the - program that tests the delete operation in the encapsulation package: -

- -
-   PROCEDURE ut_del1
-   IS
-      fdbk PLS_INTEGER;
-   BEGIN
-      /* Delete that finds now rows. */
-
-      EXECUTE IMMEDIATE '
-      DELETE FROM ut_DEL1
-       WHERE employee_id = -1
-      ';
-      te_employee.del (-1, rowcount_out => fdbk);
-      -- Test results
-      utassert.eqtable ('Delete rows', 'EMPLOYEE', 'ut_DEL1');
-      /* Successful delete */
-
-      EXECUTE IMMEDIATE '
-      DELETE FROM ut_DEL1
-       WHERE employee_id between 7800 and 7899
-      ';
-
-      FOR rec IN (SELECT *
-                    FROM employee
-                   WHERE employee_id BETWEEN 7800 AND 7899)
-      LOOP
-         te_employee.del (
-            rec.employee_id,
-            rowcount_out => fdbk
-         );
-      END LOOP;
-
-      -- Test results
-      utassert.eqtable ('Delete rows', 'EMPLOYEE', 'ut_DEL1');
-      ROLLBACK;
-   EXCEPTION
-      WHEN OTHERS
-      THEN
-         utassert.this (
-            'DEL1 exception ' || SQLERRM,
-            SQLCODE = 0
-         );
-   END;
-
- -

- In this procedure, I test for two scenarios: a delete that removes zero - rows and a delete that removes a specific set of rows. In both cases, I - perform the explicit (non-encapsulated) DML logic against a copy - of the actual table (this copy is created in the setup - procedure; that is the reason I use dynamic SQL to refer to this table - -- it doesn't exist when the package is compiled!). Then I do the (hopefully) - same operation by using the API program. Finally, I call the appropriate - utAssert assertion program to compare the results -- and at the end of - the procedure issue a ROLLBACK so that my "source" table (employee, in - this case), i set back to the original data state. Notice that I also put - an assertion program in the exception section to trap any errors and flag - it as a failed test. -

-

- That should give you a good feel for the kind of code you might write - to test a table encapsulation package. The next two sections show you how - I used the setup and teardown procedures to manage the data structures - I use in my tests. -

- -

Set Up Data Structures

- -

- As I contemplated how best to test these large packages, I revisited some - of my testing principles and found one to be of particular importance: -

- -

Build isolated tests.

- -

- This principle is important because it allows you to run one, all or - a subset of your tests without having to worry about the impact or dependencies - on the other tests. And test isolation is particularly important - when testing DML operations. The way to validate a successful DML operation - is by analyzing the contents of the "source" table against a "test" table. - If all the tests modify the same test table, ti will be very difficult - if not impossible to verify success or notice failure. -

-

- So I decided that the best way to run my unit tests for DML operations - was to create a separate test table for each unit test. As a consequence, - my setup procedure for the te_employee package looks like this: - (See ut_te_employee.pkb in the Examples directory of the utPLSQL distribution) -

- -
-   PROCEDURE ut_setup
-   IS
-   BEGIN
-      ut_teardown;
-      EXECUTE IMMEDIATE 'CREATE TABLE ut_employee AS
-            SELECT * FROM employee';
-      EXECUTE IMMEDIATE 'CREATE TABLE ut_DEL1 AS
-            SELECT * FROM employee';
-      EXECUTE IMMEDIATE 'CREATE TABLE ut_DELBY_EMP_DEPT_LOOKUP AS
-            SELECT * FROM employee';
-      EXECUTE IMMEDIATE 'CREATE TABLE ut_DELBY_EMP_JOB_LOOKUP AS
-            SELECT * FROM employee';
-      EXECUTE IMMEDIATE 'CREATE TABLE ut_DELBY_EMP_MGR_LOOKUP AS
-            SELECT * FROM employee';
-      EXECUTE IMMEDIATE 'CREATE TABLE ut_INS1 AS
-            SELECT * FROM employee';
-      EXECUTE IMMEDIATE 'CREATE TABLE ut_UPD1 AS
-            SELECT * FROM employee';
-      EXECUTE IMMEDIATE 'CREATE TABLE ut_UPD$HIRE_DATE1 AS   
-            SELECT * FROM employee';
-      EXECUTE IMMEDIATE 'CREATE TABLE ut_UPD$SALARY1 AS
-            SELECT * FROM employee';
-   END;
-
- -

- I first remove all my data structures using the teardown procedure to make - sure I have a clean start. Then I use dynamic SQL (the Oracle8i version) - to create all my tables. I must rely on dynamic SQL because PL/SQL does - not yet support native DDL statements, such as CREATE TABLE. -

-

- Then I am set to test. -

- -

Tear Down Data Structures

- -

- Well, if I am going to create a whole bunch of data structures to run my - tests, I had better get rid of those structures when I am done. Here is - the teardown program I generated for the te_employee package: -

- -
-   PROCEDURE ut_teardown
-   IS
-   BEGIN
-      BEGIN
-         EXECUTE IMMEDIATE 'DROP TABLE ut_employee';
-      EXCEPTION
-         WHEN OTHERS
-         THEN
-            NULL;
-      END;
-
-      BEGIN
-         EXECUTE IMMEDIATE 'DROP TABLE ut_DEL1';
-      EXCEPTION
-         WHEN OTHERS
-         THEN
-            NULL;
-      END;
-
-      BEGIN
-         EXECUTE IMMEDIATE 'DROP TABLE ut_DELBY_EMP_DEPT_LOOKUP';
-      EXCEPTION
-         WHEN OTHERS
-         THEN
-            NULL;
-      END;
-
-      BEGIN
-         EXECUTE IMMEDIATE 'DROP TABLE ut_DELBY_EMP_JOB_LOOKUP';
-      EXCEPTION
-         WHEN OTHERS
-         THEN
-            NULL;
-      END;
-
-      BEGIN
-         EXECUTE IMMEDIATE 'DROP TABLE ut_DELBY_EMP_MGR_LOOKUP';
-      EXCEPTION
-         WHEN OTHERS
-         THEN
-            NULL;
-      END;
-
-      BEGIN
-         EXECUTE IMMEDIATE 'DROP TABLE ut_INS1';
-      EXCEPTION
-         WHEN OTHERS
-         THEN
-            NULL;
-      END;
-
-      BEGIN
-         EXECUTE IMMEDIATE 'DROP TABLE ut_UPD1';
-      EXCEPTION
-         WHEN OTHERS
-         THEN
-            NULL;
-      END;
-
-      BEGIN
-         EXECUTE IMMEDIATE 'DROP TABLE ut_UPD$HIRE_DATE1';
-      EXCEPTION
-         WHEN OTHERS
-         THEN
-            NULL;
-      END;
-
-      BEGIN
-         EXECUTE IMMEDIATE 'DROP TABLE ut_UPD$SALARY1';
-      EXCEPTION
-         WHEN OTHERS
-         THEN
-            NULL;
-      END;
-
-   END;
-
- -

- Again, I use dynamic SQL, but enclose each DROP TABLE statement inside - its own exception section so that if for any reason the DROP fails, I continue - on in an attempt to get as much done as possible. -

- -
- -

Footnotes

-

- 1. These files are in the Examples directory of the utPLSQL distribution. -

- -

< Previous Section: Test a Function | Next Section: Put Test Code in Same Package >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/testfunc.html b/docs/testfunc.html deleted file mode 100644 index 2d5549f..0000000 --- a/docs/testfunc.html +++ /dev/null @@ -1,148 +0,0 @@ - - - - - - - - - - - Test a Function - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Test a Procedure | Next Section: Test an Entire Package API >

- - -

Test a Function

- -

- As with the procedure, there are a couple of scenarios to consider: -

- - - -

Testing a Scalar Function

- -

- First, a test of a function returning a scalar value. Consider the following - packaged function: -

- -
-/*file str.pks and str.pkb */
-CREATE OR REPLACE PACKAGE str
-IS
-   FUNCTION betwn (
-      string_in IN VARCHAR2,
-      start_in IN PLS_INTEGER,
-      end_in IN PLS_INTEGER
-   )
-      RETURN VARCHAR2;
-END str;
-/
-
- -

- The str.betwn function returns the sub-string of a string_in that is found - between the start and end locations specified by start_in and end_in. -

- -

- So...time to test! I generate a test package - and then modify the unit test procedure to check for various conditions: -

- -
-/*file ut_str.pkb */
-CREATE OR REPLACE PACKAGE BODY ut_str
-IS
-   PROCEDURE ut_setup
-   IS
-   BEGIN
-      NULL;
-   END;
-   
-   PROCEDURE ut_teardown
-   IS
-   BEGIN
-      NULL;
-   END;
-
-   -- For each program to test...
-   PROCEDURE ut_betwn IS
-   BEGIN
-      utAssert.eq (
-         'Typical Valid Usage',
-         str.betwn ('this is a string', 3, 7),
-         'is is' 
-         );
-         
-      utAssert.eq (
-         'Test Negative Start',
-         str.betwn ('this is a string', -3, 7),
-         'ing'
-         );
-         
-      utAssert.isNULL (
-         'Start bigger than end',
-         str.betwn ('this is a string', 3, 1)
-         );
-   END ut_betwn;
-
-END ut_str;
-/
-
- -

- As you can see, my calls to str.betwn are embedded right within calls to - utAssert.eq and utAssert.isNULL, making my test code compact. -

- - -

< Previous Section: Test a Procedure | Next Section: Test an Entire Package API >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/testproc.html b/docs/testproc.html deleted file mode 100644 index e70c616..0000000 --- a/docs/testproc.html +++ /dev/null @@ -1,331 +0,0 @@ - - - - - - - - - - - Test a Procedure - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Examples | Next Section: Test a Function >

- - -

Test a Procedure

- -

There are a couple of scenarios to consider:

- - - -

Test Success Through Parameters

- -

- We'll start with a really simple example. I - have built a procedure that accepts two dates and returns the number of - seconds between them. Here it is: -

- -
-/*file calc_secs_between.sp */
-CREATE OR REPLACE PROCEDURE calc_secs_between (
-   date1 IN DATE,
-   date2 IN DATE,
-   secs OUT NUMBER)
-IS
-BEGIN
-   -- 24 hours in a day, 
-   -- 60 minutes in an hour,
-   -- 60 seconds in a minute...
-   secs := (date2 - date1) * 24 * 60 * 60;
-END;
-/
-
- -

- After compiling my code cleanly, I generate - my test package: -

- -
-SQL> SET SERVEROUTPUT ON FORMAT WRAPPED
-SQL> exec utGen.testpkg ('calc_secs_between ')
-CREATE OR REPLACE PACKAGE ut_calc_secs_between
-IS
-   PROCEDURE ut_setup;
-   PROCEDURE ut_teardown;
-
-   -- For each program to test...
-   PROCEDURE ut_CALC_SECS_BETWEEN;
-END ut_calc_secs_between;
-/
-CREATE OR REPLACE PACKAGE BODY ut_calc_secs_between
-IS
-   PROCEDURE ut_setup
-   IS
-   BEGIN
-      NULL;
-   END;
-
-   PROCEDURE ut_teardown
-   IS
-   BEGIN
-      NULL;
-   END;
-
-   -- For each program to test...
-   PROCEDURE ut_CALC_SECS_BETWEEN IS
-   BEGIN
-      CALC_SECS_BETWEEN (
-            DATE1 => ''
-            ,
-            DATE2 => ''
-            ,
-            SECS => ''
-       );
-
-      utAssert.this (
-         'Test of CALC_SECS_BETWEEN',
-         '<boolean expression>'
-         );
-   END ut_CALC_SECS_BETWEEN;
-
-END ut_calc_secs_between;
-/
-
- -

- I generated the output to the screen, but it - is actually easier to deposit the code directly into two separate files - for package spec and body, ut_calc_secs_between.pks and ut_calc_secs_between.pkb, - which I do as follows: -

- -
-SQL> exec utGen.testpkg ('calc_secs_between ', output_type_in => utGen.c_file)
-
- -

- By conforming to this standard, utPLSQL can - automatically compile this code before each test. I now edit the ut_calc_secs_between - procedure to test for various cases: -

- -
-PROCEDURE ut_CALC_SECS_BETWEEN 
-IS
-   secs PLS_INTEGER;
-BEGIN
-   CALC_SECS_BETWEEN (
-         DATE1 => SYSDATE
-         ,
-         DATE2 => SYSDATE
-         ,
-         SECS => secs
-    );
-
-   utAssert.eq (
-      'Same dates',
-      secs, 
-      0
-      );
-      
-   CALC_SECS_BETWEEN (
-         DATE1 => SYSDATE
-         ,
-         DATE2 => SYSDATE+1
-         ,
-         SECS => secs
-    );
-
-   utAssert.eq (
-      'Exactly one day',
-      secs, 
-      24 * 60 * 60
-      );
-      
-END ut_CALC_SECS_BETWEEN;
-
- -

and now I can run my test:

- -
-SQL> exec utplsql.test ('calc_secs_between')
-.
->    SSSS   U     U   CCC     CCC   EEEEEEE   SSSS     SSSS
->   S    S  U     U  C   C   C   C  E        S    S   S    S
->  S        U     U C     C C     C E       S        S
->   S       U     U C       C       E        S        S
->    SSSS   U     U C       C       EEEE      SSSS     SSSS
->        S  U     U C       C       E             S        S
->         S U     U C     C C     C E              S        S
->   S    S   U   U   C   C   C   C  E        S    S   S    S
->    SSSS     UUU     CCC     CCC   EEEEEEE   SSSS     SSSS
-.
- SUCCESS: "calc_secs_between"
- 
- -

- Certainly, there are a variety of other conditions - to test, but this should give you a good idea of how to go about it! -

- -

Test Success by Analyzing Impact

- -

- Now let's consider a more complicated situation. - I have a procedure that truncates all the rows in the specified table. - To do this I just use dynamic SQL, as you can see in: -

- -
-/*file truncit.sp */
-CREATE OR REPLACE PROCEDURE truncit (
-   tab IN VARCHAR2,
-   sch IN VARCHAR2 := NULL
-)
-IS
-BEGIN
-   EXECUTE IMMEDIATE 'truncate table ' || NVL (sch, USER) || '.' || tab;
-END;
-/
-
- -

- After I run this test, I cannot simply check - the value returned by the procedure. Instead, I must check to see how many - rows are left in the table. Fortunately, I have another dynamic SQL utility - to help me out here, one that returns the count of rows in any table: - (Note that you could also use utAssert.eqqueryvalue here.) -

- -
-/*file tabcount.sf */
-CREATE OR REPLACE FUNCTION tabcount (
-   sch IN VARCHAR2,
-   tab IN VARCHAR2)
-   RETURN INTEGER
-IS
-   retval  INTEGER;
-BEGIN
-   EXECUTE IMMEDIATE 
-      'SELECT COUNT(*) FROM ' || sch || '.' || tab
-      INTO retval; 
-   RETURN retval;
-EXCEPTION
-    WHEN OTHERS 
-    THEN
-       RETURN NULL; 
-END;
-/
-
- -

- So I will generate a package - to test truncit and then modify the package body: -

- -
-SQL> SET SERVEROUTPUT ON FORMAT WRAPPED
-SQL> exec utGen.testpkg ('truncit', output_type_in => utGen.c_file)
-
- -

- To run my test, I need to truncate a table. - That is an irreversible action, so I will create a "temporary" table in - the setup procedure and drop it in the teardown procedure. Then I will - run my code and use tabCount to validate the results: -

- -
-/*file ut_truncit.pkb */
-CREATE OR REPLACE PACKAGE BODY ut_truncit
-IS
-   PROCEDURE ut_setup
-   IS
-   BEGIN
-      EXECUTE IMMEDIATE 
-         'CREATE TABLE temp_emp AS SELECT * FROM employee';
-   END;
-   
-   PROCEDURE ut_teardown
-   IS
-   BEGIN
-      EXECUTE IMMEDIATE 
-         'DROP TABLE temp_emp';
-   END;
-
-   -- For each program to test...
-   PROCEDURE ut_TRUNCIT IS
-   BEGIN
-      TRUNCIT (
-            TAB => 'temp_emp'
-            ,
-            SCH => USER
-       );
-
-      utAssert.eq (
-         'Test of TRUNCIT',
-         tabcount (USER, 'temp_emp'),
-         0
-         );
-   END ut_TRUNCIT;
-
-END ut_truncit;
-/
-
- -

- Not quite as straightforward as checking values - returned in OUT or IN OUT arguments, but not too awful, right? Of course, - things can get considerably more complicated as your code (and the results - you must test for) grows more complex. Regardless, you will find it easier - to build and run your tests through utPLSQL than through more ad hoc and - considerably less organized approaches. -

- - - -

< Previous Section: Examples | Next Section: Test a Function >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/testrun.html b/docs/testrun.html deleted file mode 100644 index f5aabdf..0000000 --- a/docs/testrun.html +++ /dev/null @@ -1,361 +0,0 @@ - - - - - - - - - - - A 'Test Run' with utPLSQL - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: How to build a test package | Next Section: Examples >

- - -

A "Test Run" with utPLSQL

- -

- I will put utPLSQL to work in a small-scale development - effort, to show you how it all hangs together. I've got a "hangnail" in - my PL/SQL development work, called SUBSTR. This function bothers me and - I want to take care of it. What's the problem? SUBSTR is great when you - know the starting location of a string and number of characters you want. In - many situations, though, I have the start and end locations and I need - to figure out the number of characters I then want. Is it: -

- -
-mystring := SUBSTR (full_string, 5, 17); -- start and end? Nah...
-
-mystring := SUBSTR (full_string, 5, 12); -- end - start?
-
-mystring := SUBSTR (full_string, 5, 13); -- end - start + 1?
-
-mystring := SUBSTR (full_string, 5, 11); -- end - start 1 1?
-
- -

- Why should I have to remember stuff like this? I - never do, and so I take out a scrap of paper, write down 'abcdefgh', put - a mark over the "c" and another over the "g", count on my fingers and then - remember that of course the formula is "end - start + 1". -

- -

- All right, so I did that a dozen times, I am sick - of it and determined to stop wasting my time in the future. I will write - a function called "str.betwn" (the betwn function defined in the str package) - that does the work and the remembering for me. -

- -

- Instead of immediately coding the function, however, - I will first write my unit tests with utPLSQL! Since my source package - is named "str", I will create a test package named "ut_str". I am a lazy - fellow, so I will take the lazy way out and generate the starting point - for my package: -

- -
-SQL> exec utgen.testpkg ('str', output_type_in => utplsql.c_file)
-
- -

- Note: for the above call to work, I must have already - set my default directory for utPLSQL, which I do via a SQL*Plus login script - that looks like this: -

- -
-exec utplsql.setdir ('e:\utplsql\test')
-
-SET SERVEROUTPUT ON SIZE 1000000 FORMAT WRAPPED
-
- -

- Otherwise, I would need to specify the directory - in my call to genpkg, as in: -

- -
-SQL> exec utgen.testpkg ('str', output_type_in => utplsql.c_file, dir_in => 'e:\utplsql\test')
-
- -

I then will find this package spec in the ut_str.pks file:

- -
-CREATE OR REPLACE PACKAGE ut_str
-IS
-   PROCEDURE ut_setup;
-   PROCEDURE ut_teardown;
-   
-   -- For each program to test...
-   PROCEDURE ut_betwn;
-END ut_str;
-/
-
- -

- And I don't really have to modify the specification - at all. The body will, on the other hand, require some work, since I haven't - yet figured out a way to automatically generate the test code itself. Here - is the purely generated test package body found - in the ut_str.pkb file: -

- -
-CREATE OR REPLACE PACKAGE BODY ut_str
-IS
-   PROCEDURE ut_setup
-   IS
-   BEGIN
-      NULL;
-   END;
-   
-   PROCEDURE ut_teardown
-   IS
-   BEGIN
-      NULL;
-   END;
-   
-   -- For each program to test...
-   PROCEDURE ut_betwn
-   IS
-   BEGIN
-      utAssert.this (
-         'Test of betwn',
-         <boolean expression>,
-      );
-   END;
-   
-END ut_str;
-/
-
- -

- The setup and teardown procedures are fine (I don't - have any special setup and therefore teardown requirements), but the ut_betwn - needs lots of work. It doesn't really test anything yet. -

- -

- Before I start writing my test code, however, I - will just sit back and think about what I want to test. Here are some inputs - that I can think of: -

- - - - - - - - - - - - - - - - - - - - - - - - - - -
StringStartEndExpected Result
"this is a string"3 (positive number)7 (bigger positive number)"is is"
"this is a string"-3 (invalid negative number)7 (bigger positive number)"ing" (consistent with SUBSTR behavior)
"this is a string"3 (positive number)1 (smaller positive number)NULL
- - -

- We could easily come up with a whole lot more test - cases - and if this was real life and not product documentation, I would - not move forward until I had identified all interesting tests. So let's - suppose I have done that and now I am ready to do some coding. Since I - am testing a function, I will want to compare the result of the function - call to my expected results. I will therefore change my assertion from - the generic "assert this" procedure to the utAssert.eq program, and put - the call to the function right into the assertion routine. Here, then, - is my first crack at transforming my ut_betwn procedure: -

- -
-PROCEDURE ut_betwn IS
-BEGIN
-   utAssert.eq (
-      'Test of betwn',
-      str.betwn ('this is a string', 3, 7),
-      'is is'
-   );
-END;
-
- -

- Following the Extreme Programming philosophy ("code - a little, test a lot"), I will test this test case before I add all the - other test cases. I do this with a very simple call: -

- -
-SQL> exec utplsql.test ('str')
-
->    SSSS   U     U   CCC     CCC   EEEEEEE   SSSS     SSSS
->   S    S  U     U  C   C   C   C  E        S    S   S    S
->  S        U     U C     C C     C E       S        S
->   S       U     U C       C       E        S        S
->    SSSS   U     U C       C       EEEE      SSSS     SSSS
->        S  U     U C       C       E             S        S
->         S U     U C     C C     C E              S        S
->   S    S   U   U   C   C   C   C  E        S    S   S    S
->    SSSS     UUU     CCC     CCC   EEEEEEE   SSSS     SSSS
-
->SUCCESS: "str"
-
- -

- Now, you could say: "Great it worked!" Or you could - say: "I have no idea if it worked. Maybe it always says success." - I go for the latter, so let's deliberately cause a failure: -

- -
-PROCEDURE ut_betwn IS
-BEGIN
-   utAssert.eq (
-      'Test of betwn',
-      str.betwn ('this is a string', 3, 7),
-      'this is a pipe'
-   );
-END;
-
- -

- Saving the file (but not bothering to recompile, - since utPLSQL will do it for me automagically), - I then run my test again: -

- -
-SQL> exec utplsql.test ('str', recompile_in=>false)
-
->  FFFFFFF   AA     III  L      U     U RRRRR   EEEEEEE
->  F        A  A     I   L      U     U R    R  E
->  F       A    A    I   L      U     U R     R E
->  F      A      A   I   L      U     U R     R E
->  FFFF   A      A   I   L      U     U RRRRRR  EEEE
->  F      AAAAAAAA   I   L      U     U R   R   E
->  F      A      A   I   L      U     U R    R  E
->  F      A      A   I   L       U   U  R     R E
->  F      A      A  III  LLLLLLL  UUU   R     R EEEEEEE
-
-FAILURE: "str"
-
-BETWN: Typical Valid Usage; expected "is is", got "this is a pipe"
-
- -

- Now I have a higher degree of confidence that I - am getting this right. Excellent! Now I will add the other test cases: -

- -
-PROCEDURE ut_betwn IS
-BEGIN
-   utAssert.eq (
-      'Typical Valid Usage',
-      str.betwn ('this is a string', 3, 7),
-      'is is'
-   );
-   
-   utAssert.eq (
-      'Test Negative Start',
-      str.betwn ('this is a string', -3, 7),
-      'ing'
-   );
-   
-   utAssert.isNULL (
-      'Start bigger than end',
-      str.betwn ('this is a string', 3, 1)
-   );
-END;
-
- -

- I will deliberately cause each of these tests to - fail, to give you a sense of the quality of feedback: -

- -
->  FFFFFFF   AA     III  L      U     U RRRRR   EEEEEEE
->  F        A  A     I   L      U     U R    R  E
->  F       A    A    I   L      U     U R     R E
->  F      A      A   I   L      U     U R     R E
->  FFFF   A      A   I   L      U     U RRRRRR  EEEE
->  F      AAAAAAAA   I   L      U     U R   R   E
->  F      A      A   I   L      U     U R    R  E
->  F      A      A   I   L       U   U  R     R E
->  F      A      A  III  LLLLLLL  UUU   R     R EEEEEEE
-
-FAILURE: "str"
-betwn: Typical Valid Usage; expected "is is", got "this is a pipe"
-betwn: Test Negative Start; expected "ing", got "BRRRING"
-betwn: IS NOT NULL: Start bigger than end
-
- -

- Faced with these results, I can zoom in on the code - within str.betwn that is causing these incorrect results. I resist the - temptation to fix the code for all my tests all at once. Instead, I make - one change at a time, then run my test again. I do that over and over again - until the failure for the single test case goes away. Then I move to the - next one. Eventually, I get a green light and am highly confident of my - program - if, of course, I really did come up with an exhaustive list of - tests. -

- -

- As I think of another test case, I add a call to - utAssert to run that test. -

- -

- As a bug is reported to me, I add a call to utAssert - to reproduce that bug. Then I repair my code. -

- - -

< Previous Section: How to build a test package | Next Section: Examples >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/userguide.html b/docs/userguide.html deleted file mode 100644 index 4731784..0000000 --- a/docs/userguide.html +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - - - - - User Guide - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: Create and Run a Test Suite | Next Section: utPLSQL Package >

- - -

User Guide

- -

- The utPLSQL unit testing framework consists of several different elements: -

- - -

This document tells you how to use those utPLSQL packages:

- -

utPLSQL - Register and run test packages

- -

utConfig - Set how tests are run

- -

- utResult - Analyze and display results - of unit tests -

- -

utAssert - Assert that code works properly

- -

utGen - Generate test packages

- -

utOutput - Handling DBMS_OUTPUT for testing

- -

utRecEq - Generate functions to compare record types

- -

Define Test Suites

- -

Using and defining Custom Reporter Packages

- -

Configuring the File Reporter

- - -

< Previous Section: Create and Run a Test Suite | Next Section: utPLSQL Package >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/utPLSQL-PLSQL-Developer.md b/docs/utPLSQL-PLSQL-Developer.md new file mode 100644 index 0000000..54a59e1 --- /dev/null +++ b/docs/utPLSQL-PLSQL-Developer.md @@ -0,0 +1,8 @@ +--- +title: utPLSQL-PLSQL-Developer plugin +--- + +{% + include-markdown "https://raw.githubusercontent.com/utPLSQL/utPLSQL-PLSQL-Developer/develop/README.md" + rewrite-relative-urls=false +%} diff --git a/docs/utPLSQL-SQLDeveloper.md b/docs/utPLSQL-SQLDeveloper.md new file mode 100644 index 0000000..c26663c --- /dev/null +++ b/docs/utPLSQL-SQLDeveloper.md @@ -0,0 +1,8 @@ +--- +title: utPLSQL-SQLDeveloper extension +--- + +{% + include-markdown "https://raw.githubusercontent.com/utPLSQL/utPLSQL-SQLDeveloper/main/README.md" + rewrite-relative-urls=false +%} diff --git a/docs/utPLSQL-cli.md b/docs/utPLSQL-cli.md new file mode 100644 index 0000000..22f95c4 --- /dev/null +++ b/docs/utPLSQL-cli.md @@ -0,0 +1,9 @@ +--- +title: utPLSQL-cli +--- + +{% + include-markdown "https://raw.githubusercontent.com/utPLSQL/utPLSQL-cli/develop/README.md" + rewrite-relative-urls=true + start="# utPLSQL-cli" +%} diff --git a/docs/utPLSQL-maven-plugin.md b/docs/utPLSQL-maven-plugin.md new file mode 100644 index 0000000..378285e --- /dev/null +++ b/docs/utPLSQL-maven-plugin.md @@ -0,0 +1,9 @@ +--- +title: utPLSQL-maven plugin +--- + +{% + include-markdown "https://raw.githubusercontent.com/utPLSQL/utPLSQL-maven-plugin/develop/README.md" + rewrite-relative-urls=true + start="# utPLSQL-maven-plugin" +%} diff --git a/docs/utassert.html b/docs/utassert.html deleted file mode 100644 index c3ee793..0000000 --- a/docs/utassert.html +++ /dev/null @@ -1,1430 +0,0 @@ - - - - - - - - - - - utAssert Package - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: utResult Package | Next Section: utGen Package >

- - -

utAssert Package

- -

This package contains the following procedures and functions:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
utAssert.thisGeneric "Assert This" Procedure
- utAssert.isnull - utAssert.isnotnull - Check for NULL and NOT NULL values
utAssert.eqCheck Equality of Scalar Values
utAssert.eqtableCheck Equality of Database Tables
utAssert.eqtabcountCheck Equality of Table Counts
utAssert.eqqueryCheck Equality of Queries
utAssert.eqqueryvalueCheck Equality of Query against single value
utAssert.eqfileCheck Equality of Files
utAssert.eqpipeCheck Equality of Database Pipes
- utAssert.eqcoll - utAssert.eqcollapi - Check Equality of Collections
utAssert.throwsCheck a procedure or function throws an exception
- utAssert.previous_passed - utAssert.previous_failed - - Check if the previous assertion - passed or failed -
utAssert.eqoutputCheck Equality of DBMS_OUTPUT Collections
- utAssert.objexists - utAssert.objnotexists - Check for existence of database objects
utAssert.eq_refc_queryCheck Equality of RefCursor and Query
utAssert.eq_refc_tableCheck Equality of RefCursor and Database Table
-

- The utAssert package provides a set of assertion routines ("assert that - the following condition is true") that you will use to register the outcome - of a test case. You must call a utAssert assertion program after (or containing) - a test case so that the results of that test can be recorded and then reported. - See Build Test Packages for many examples and - more details on this process. Here is a very simple example, though, to give - you an idea of the code you would write: -

- -
-PROCEDURE ut_BETWNSTR IS
-BEGIN
-   utAssert.eq (
-      'Typical valid usage',
-      BETWNSTR(
-         STRING_IN => 'abcdefg',
-         START_IN => 3,
-         END_IN => 5
-      ),
-      'cde'
-   );
-END;
-
-

- utAssert offers a wide (and ever expanding) set of assertion programs that - allow you to efficiently (a) test the outcome of your unit test and (b) report - the results of that test to utPLSQL. You should review - Common Assertion Parameters and Behavior before using any specific assertion - program. It is also possible to build your own assertion - routine. Note: all utAssert assertions are defined in the ut_assertion - table, as well as actually coded in the utAssert package. -

- -

Common Assertion Parameters and Behavior

- -

- Each type of assertion routine accepts different kinds of data, but there - are lots of similarities between the assertions, as well. Here is an explanation - of the common assertion parameters: -

- - - - - - - - - - - - - - - - - - - - - - -
msg_in - A message to be displayed if the assertion - fails. This is the first argument and is mandatory, because the tests need - to be self documenting. -
check_this_in - The value to be checked.. If a Boolean expression, - this will usually include the invocation of the method being tested, resulting - in a single line of code for the entire test case. -
against_this_in - For assert_eq, the assertion routine will - check the check_this_in value against the against_this_in value. This parameter - should be the certifiably correct value. -
null_ok_in - TRUE if a NULL value should be interpreted - as a successful test, FALSE if NULL indicates failure. -
raise_exc_in - TRUE if it is OK for the assertion routine - to allow an exception to be propagated out unhandled. -
- -

Generic "Assert This" Assertion Procedure

- -

- This most generic assertion program simply says "assert this" and passes - a Boolean expression. It is used by all the other assertion routines, which - construct a Boolean expression from their specific values and logic. -

- -
-   PROCEDURE utAssert.this (
-      msg_in        IN VARCHAR2,
-      check_this_in IN BOOLEAN,
-      null_ok_in    IN BOOLEAN := FALSE,
-      raise_exc_in  IN BOOLEAN := FALSE
-   );
-
- -

- Use utAssert.this when you have a Boolean expression that you want to check, - as in: -

- -
-BEGIN
-   ...
-   utAssert.this (
-      'Boolean function result',
-      is_valid_account (my_account)
-   );
-
- -

- You can also use this assertion to register a failure, most usually in - an exception section, as in: -

- -
-EXCEPTION
-   WHEN OTHERS
-   THEN
-      utAssert.this (
-         SQLERRM,
-         FALSE
-      );
-
- -

- Generally, you should avoid utAssert.this and instead use a specialized - assertion routine, documented below. Most of the assertions give you the - ability check for equality (of scalars, such as strings, or more complex - data structures like tables, pipes and files): does the data generated by - my code match the expected value(s)? -

- -

Check for NULL and NOT NULL Values

- -

- You can check to see if a value is NULL or is NOT NULL with the following - assertions: -

- -
-PROCEDURE utAssert.isnotnull (
-   msg_in        IN VARCHAR2,
-   check_this_in IN VARCHAR2,
-   null_ok_in    IN BOOLEAN := FALSE,
-   raise_exc_in  IN BOOLEAN := FALSE
-);
-
-PROCEDURE utAssert.isnull (
-   msg_in        IN VARCHAR2,
-   check_this_in IN VARCHAR2,
-   null_ok_in    IN BOOLEAN := FALSE,
-   raise_exc_in  IN BOOLEAN := FALSE
-);
-
-PROCEDURE utAssert.isnotnull (
-   msg_in        IN VARCHAR2,
-   check_this_in IN BOOLEAN,
-   null_ok_in    IN BOOLEAN := FALSE,
-   raise_exc_in  IN BOOLEAN := FALSE
-);
-
-PROCEDURE utAssert.isnull (
-   msg_in        IN VARCHAR2,
-   check_this_in IN BOOLEAN,
-   null_ok_in    IN BOOLEAN := FALSE,
-   raise_exc_in  IN BOOLEAN := FALSE
-);
-
- -

- Use these assertions when you simply want to check if a scalar expression - (string, date, number and Boolean are supported) is NULL or NOT NULL, as - in: -

- -
-BEGIN
-   ...
-   utAssert.isNULL (
-      'Should be nothing left',
-      TRANSLATE (digits_in_string, 'A1234567890', 'A')
-   );
-
- -

Check Equality of Scalar Values

-

- If you need to compare two dates or two strings or two numbers or two Booleans, - use the utAssert.eq assertion program. -

- -

Here is the header for the scalar equality check assertion:

- -
-PROCEDURE utAssert.eq (
-   msg_in          IN VARCHAR2,
-   check_this_in   IN VARCHAR2|BOOLEAN|DATE|NUMBER,
-   against_this_in IN VARCHAR2|BOOLEAN|DATE|NUMBER,
-   null_ok_in      IN BOOLEAN := FALSE,
-   raise_exc_in    IN BOOLEAN := FALSE
-);
-
- -

- If the two values are equal, your code gets a green light. Otherwise, utAssert - writes the test results to the utResult package, resulting in a red light - for the test. If NULL values are considered value for this test, pass TRUE - for null_ok_in. If you want the assertion to raise an exception on failure - and stop the test from proceeding, pass TRUE for raise_exc_in. Here is an - example of using the utAssert.eq program: -

- -
   
-   PROCEDURE ut_emp_dept_lookuprowcount
-   IS
-      l_rowcount1 PLS_INTEGER;
-      l_rowcount2 PLS_INTEGER;
-      BEGIN
-         -- Run baseline code.
-         SELECT COUNT (*)
-         INTO l_rowcount1
-         FROM employee
-         WHERE department_id = 30;
-         
-         -- Compare to program call:
-         l_rowcount2 := te_employee.emp_dept_lookuprowcount (30);
-         
-         -- Test results
-         utassert.eq (
-            'Successful EMP_DEPT_LOOKUPROWCOUNT',
-            l_rowcount2,
-            l_rowcount1
-         );
-      END;
-
- -

Check Equality of DatabaseTables

- -

- If your test performs DML operations (update, insert or delete), you will - need to check your results in a database table. You could do this by querying - the results into local variables and then calling utAssert.eq to check those - values against your expected data. That can be a very laborious process, - so utAssert offers the eqtable and equerry assertion routines to streamline - the process. Both these procedures use the MINUS SQL operator to essentially - "subtract" the contents of one table (query) from the other. If anything - is left, then the two tables (queries) are not the same and the test is given - a red light. As you can probably see, the structure of the two tables (queries) - must be identical for this assertion to work properly. The utAssert.eqtable - allows you to compare the contents of your data table (changed by your code) - against another table, which you can preset with the data you expect to see - after the test. Here is the header for eqtable: -

- -
-PROCEDURE utAssert.eqtable (
-   msg_in           IN VARCHAR2,
-   check_this_in    IN VARCHAR2,
-   against_this_in  IN VARCHAR2,
-   check_where_in   IN VARCHAR2 := NULL,
-   against_where_in IN VARCHAR2 := NULL,
-   raise_exc_in     IN BOOLEAN := FALSE
-);
-
- -

- where check_this_in and against_this_in are the names of tables or views. - You can supply an optional WHERE clause to restrict the rows you wish to - compare. Here is an example that calls eqTable twice, to test two different - conditions. -

- -
-PROCEDURE ut_del1
-IS
-   fdbk PLS_INTEGER;
-BEGIN
-   /* Delete that finds now rows. */
-
-   EXECUTE IMMEDIATE '
-   DELETE FROM ut_DEL1
-   WHERE employee_id = -1
-   ';
-   te_employee.del (-1, rowcount_out => fdbk);
-
-   -- Test results
-   utassert.eqtable ('Delete rows', 'EMPLOYEE', 'ut_DEL1');
-
-   /* Successful delete */
-
-   EXECUTE IMMEDIATE '
-   DELETE FROM ut_DEL1
-   WHERE employee_id between 7800 and 7899
-   ';
-      
-   FOR rec IN (SELECT *
-                 FROM employee
-                WHERE employee_id BETWEEN 7800 AND 7899)
-   LOOP
-      te_employee.del (
-         rec.employee_id,
-         rowcount_out => fdbk
-      );
-   END LOOP;
-   
-   -- Test results
-   utassert.eqtable ('Delete rows', 'EMPLOYEE', 'ut_DEL1');
-   ROLLBACK;
-EXCEPTION
-   WHEN OTHERS
-   THEN
-      utassert.this (
-         'DEL1 exception ' || SQLERRM,
-         SQLCODE = 0
-      );
-END;
-
- -

Check Equality of Table Counts

- -

- If your tests simply produce the right number of rows in a table but not - a fixed set of values, you will not be able to use - utAssert.eqtable above. However, utAssert.eqtabcount allows you to simply - test that the numbers of rows are equal. The declaration of the procedure - is as follows: -

- -
-PROCEDURE utAssert.eqtabcount (
-   msg_in           IN VARCHAR2,
-   check_this_in    IN VARCHAR2,
-   against_this_in  IN VARCHAR2,
-   check_where_in   IN VARCHAR2 := NULL,
-   against_where_in IN VARCHAR2 := NULL,
-   raise_exc_in     IN BOOLEAN := FALSE
-);
-
- -

- where check_this_in and against_this_in are the names of tables or views. - As in utAssert.eqtable, you can supply an optional WHERE clause to restrict - the rows you wish to compare. The following test will compare the number - of rows in the CD_COLLECTION and UT_TEST_5_1 tables where the given condition - holds: -

- -
-utassert.eqtabcount('Test 5.1: Insert new rows',
-                    'CD_COLLECTION',
-                    'UT_TEST_5_1',
-                    'ARTIST = ''The Fall''',
-                    'ARTIST = ''The Fall''');
-
- -

Asserting Query Equality

- -

- The utAssert.eqquery allows you to compare the data returned by two queries - (strings that are contained in the check_this_in and against_this_in parameters). - In this case, you specify the full SELECT statements for each query as the - parameters. By using equery, you may be able to avoid constructing a separate - table with preset data. -

- -
-PROCEDURE utAssert.eqquery (
-   msg_in          IN VARCHAR2,
-   check_this_in   IN VARCHAR2,
-   against_this_in IN VARCHAR2,
-   raise_exc_in    IN BOOLEAN := FALSE
-);
-
- -

- If you want the assertion to raise an exception on failure and stop the - test from proceeding, pass TRUE for raise_exc_in. Here is an example of - using eqQuery: -

- -
-PROCEDURE ut_upd1
-IS
-BEGIN
-   /* Update 3 columns by ID */
-   EXECUTE IMMEDIATE '
-   UPDATE ut_UPD1 SET
-      FIRST_NAME = ''SILLY'',
-      HIRE_DATE = trunc (SYSDATE+100),
-      COMMISSION = 5000
-    WHERE
-       EMPLOYEE_ID = 7600
-   ';
-   te_employee.upd (
-      7600,
-      first_name_in => 'SILLY',
-      commission_in => 5000,
-      hire_date_in => TRUNC (SYSDATE + 100),
-      rowcount_out => fdbk
-   );
-   -- Test results (audit fields are different so do a query)
-   utassert.eqquery (
-      'Update three columns',
-      'select first_name, commission, hire_date from EMPLOYEE',
-      'select first_name, commission, hire_date from ut_upd1'
-   );
-   ROLLBACK;
-END;
-
- -

Check Query Equality against a Single Value

-

- Often we will wish to test the result of a query against a single value rather - than another query as in utAssert.eqquery above. - It is possible to get around this problem by using a trivial query of the - form: -

- -
-SELECT fixed_value
-FROM DUAL;
-
- -

- Unfortunately, if the query returns multiple values or the wrong value we - will only be told that the test has failed with no details. This is where - utAssert.eqqueryvalue comes to the rescue. The procedure is declared as - follows: -

- -
-PROCEDURE utAssert.eqqueryvalue (
-   msg_in           IN VARCHAR2,
-   check_query_in   IN VARCHAR2,
-   against_value_in IN VARCHAR2|NUMBER|DATE,
-   raise_exc_in     IN BOOLEAN := FALSE
-);
-
- -

- Where check_query_in is the query in question and against_value_in is the - value to check it against. If the query returns more than one value, the - resulting error message will tell you this. Similarly, if the query returns - the wrong value, the message will state the expected and obtained values. - The following call compares the maximum value found in a table against a - given number value: -

- -
-utAssert.eqqueryvalue('Maximum value test',
-                      'SELECT MAX(MEMORY)
-                       FROM COMPUTERS
-                       WHERE OS IN (''Linux'', ''Unix'')',
-                       256);
-
- -

- Obviously this should only return a single value, but if it returns something - other than 256, we'll know about it. -

- -

Check Equality of Files

- -

- Many programs generate output to operating system files; alternatively, - you might write data to a file simply to test results. Use the eqfile assertion - for either of these scenarios. This procedure uses PL/SQL's UTL_FILE package - to compare the contents of two different files. Note: If you have not used - UTL_FILE in the past, you must configure - it before it can be used -- by utPLSQL or by your own code. UTL_FILE must - be allowed accss to either or both of the directories you specify (this involves - setting the utl_file_dir database parameter). -

- -
-PROCEDURE utAssert.eqfile (
-   msg_in IN VARCHAR2,
-   check_this_in IN VARCHAR2,
-   check_this_dir_in IN VARCHAR2,
-   against_this_in IN VARCHAR2,
-   against_this_dir_in IN VARCHAR2 := NULL,
-   raise_exc_in IN BOOLEAN := FALSE
-);
-
- -

- If you want the assertion to raise an exception on failure and stop the - test from proceeding, pass TRUE for raise_exc_in. You must specify the directory - containing the "check this" file; if you do not specify a directory for the - "against this" file, the "check this" directory will be used. Here is an - example of using eqFile (see ut_DEPARTMENT2file.pkg in the Examples directory - for the full implementation): -

- -
-PROCEDURE ut_DEPARTMENT2FILE IS
-BEGIN
-   DEPARTMENT2FILE (
-      LOC => 'c:\temp',
-      FILE => 'department.dat',
-      DELIM => '***'
-    );
-
-   utAssert.eqfile (
-      'Test of DEPARTMENT2FILE',
-      'department.dat',
-      'c:\temp',
-      'department.tst',
-      'c:\temp'
-      );      
-END ut_DEPARTMENT2FILE;
-
- -

Check Equality of Database Pipes

-

- Database pipes offer a handy mechanism for passing data between different - sessions connected to the RDBMS. It is important to know that pipes are being - filled properly; use the eqpipe to check this condition. With the eqpipe - procedure, you compare the contents of two different pipes. -

- -
-PROCEDURE utAssert.eqpipe (
-   msg_in          IN VARCHAR2,
-   check_this_in   IN VARCHAR2,
-   against_this_in IN VARCHAR2,
-   raise_exc_in    IN BOOLEAN := FALSE
-);
-
- -

- If you want the assertion to raise an exception on failure and stop the - test from proceeding, pass TRUE for raise_exc_in. To check the contents - of a pipe based on the execution of code, you will need to populate a pipe - against which to test equality. The employee_pipe.pkg file in the Examples - directory contains a demonstration of the kind of code you might write to - do this. This package contains all of the unit test code within the same - package. Here is my unit test program, which relies on the utAssert.eqpipe - program: -

- -
-PROCEDURE ut_fillpipe IS
-   stat PLS_INTEGER;
-BEGIN
-   emptypipe ('emps');
-   emptypipe ('emps2');
-   
-   fillpipe ('emps');
-   
-   /* Direct filling of pipe. */
-   
-   FOR rec IN (SELECT *
-                 FROM employee)
-   LOOP
-      DBMS_PIPE.RESET_BUFFER;
-      DBMS_PIPE.PACK_MESSAGE (rec.EMPLOYEE_ID);
-      DBMS_PIPE.PACK_MESSAGE (rec.LAST_NAME);
-      DBMS_PIPE.PACK_MESSAGE (rec.FIRST_NAME);
-      DBMS_PIPE.PACK_MESSAGE (rec.MIDDLE_INITIAL);
-      DBMS_PIPE.PACK_MESSAGE (rec.JOB_ID);
-      DBMS_PIPE.PACK_MESSAGE (rec.MANAGER_ID);
-      DBMS_PIPE.PACK_MESSAGE (rec.HIRE_DATE);
-      DBMS_PIPE.PACK_MESSAGE (rec.SALARY);
-      DBMS_PIPE.PACK_MESSAGE (rec.COMMISSION);
-      DBMS_PIPE.PACK_MESSAGE (rec.DEPARTMENT_ID);
-      DBMS_PIPE.PACK_MESSAGE (rec.CHANGED_BY);
-      DBMS_PIPE.PACK_MESSAGE (rec.CHANGED_ON);
-
-      stat := DBMS_PIPE.SEND_MESSAGE ('emps2', 0);
-   END LOOP;
-   
-   /* Compare the two */
-   utassert.eqpipe (
-      'Two employee pipes', 'emps', 'emps2');
-      
-END ut_fillpipe;
-
- -

- Since I have stored my unit test logic with my source code package, I would - run my test as follows: -

- -
-SQL> exec utplsql.test ('employee_pipe', samepackage_in=>TRUE)
-FAILURE: "employee_pipe"
-fillpipe: Pipes equal? Compared "emps" against "emps2"
-
- -

Check Equality of Collections

- -

- Collections are as close as you come to arrays in PL/SQL. They are very - useful for managing lists of information, but can be difficult to debug and - maintain. With the eqcoll and eqcollAPI procedures, you can compare the - contents of two different arrays. Use the eqColl procedure when you want - to compare two collections that are defined in the specification of a package. - Use the eqCollAPI procedure when you want to compare two collections that - are defined in the body of a package, with programs defined in the specification - (an API) to access and manipulate the collections. The collection equality - check headers are: -

- -
-   /* Direct access to collections */
-   PROCEDURE utAssert.eqcoll (
-      msg_in IN VARCHAR2,
-      check_this_in IN VARCHAR2, /* pkg1.coll */
-      against_this_in IN VARCHAR2, /* pkg2.coll */
-      eqfunc_in IN VARCHAR2 := NULL,
-      check_startrow_in IN PLS_INTEGER := NULL,
-      check_endrow_in IN PLS_INTEGER := NULL,
-      against_startrow_in IN PLS_INTEGER := NULL,
-      against_endrow_in IN PLS_INTEGER := NULL,
-      match_rownum_in IN BOOLEAN := FALSE,
-      null_ok_in IN BOOLEAN := TRUE,
-      raise_exc_in IN BOOLEAN := FALSE
-   );
-  
-   /* API based access to collections */
-   PROCEDURE utAssert.eqcollapi (
-      msg_in IN VARCHAR2,
-      check_this_pkg_in IN VARCHAR2,
-      against_this_pkg_in IN VARCHAR2,
-      eqfunc_in IN VARCHAR2 := NULL,
-      countfunc_in IN VARCHAR2 := 'COUNT',
-      firstrowfunc_in IN VARCHAR2 := 'FIRST',
-      lastrowfunc_in IN VARCHAR2 := 'LAST',
-      nextrowfunc_in IN VARCHAR2 := 'NEXT',
-      getvalfunc_in IN VARCHAR2 := 'NTHVAL',
-      check_startrow_in IN PLS_INTEGER := NULL,
-      check_endrow_in IN PLS_INTEGER := NULL,
-      against_startrow_in IN PLS_INTEGER := NULL,
-      against_endrow_in IN PLS_INTEGER := NULL,
-      match_rownum_in IN BOOLEAN := FALSE,
-      null_ok_in IN BOOLEAN := TRUE,
-      raise_exc_in IN BOOLEAN := FALSE
-   );
-
- -

where the eqcoll-specific parameters are as follows:

- - - - - - - - - - - - - - - - - - -
ParameterDescription
msg_in The message to be displayed if the test failes
check_this_in - The name of the collection to be checked. - Format: package.collection. In other words, the collection must be defined - in a package specification. Use eqCollAPI (and check_this_pkg_in) if you - want to hide the declaration of your collection in your package body (recommended). -
against_this_in - The name of the collection to be checked - against. Format: package.collection. In other words, the collection must - be defined in a package specification. Use eqCollAPI (and check_this_pkg_in) - if you want to hide the declaration of your collection in your package body - (recommended). -
- -

and the eqcollAPI-specific parameters are as follows:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ParameterDescription
msg_in The message to be displayed if the test failes
check_this_pkg_in - The name of the package that contains the - collection to be checked. -
against_this_pkg_in - The name of the package that contains the - collection to be checked against. -
countfunc_in - The name of the function in the package that - returns the number of rows defined in the collection. -
firstrowfunc_in - The name of the function in the package that - returns the first defined row in the collection. -
lastrowfunc_in - The name of the function in the package that - returns the last defined row in the collection. -
nextrowfunc_in - The name of the function in the package that - returns the next defined row in the collection from the specified row. -
getvalfunc_in - The name of the function in the package that - returns the contents of the specified row. -
- -

The parameters common to both eqColl and eqCollAPI are as follows

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ParameterDescription
eqfunc_in - The function used to determine if the contents - of each row of the two collections are the same. If you pass NULL for this - argument, then a standard equality check will be used. This is fine for scalar - values, but will not work, for example, with tables of records. -
check_startrow_in - The starting row in the check collection - for comparison. If NULL, then first row is used. -
check_endrow_in - The ending row in the check collection for - comparison. If NULL, then last row is used. -
against_startrow_in - The starting row in the against collection - for comparison. If NULL, then first row is used. -
against_endrow_in - The ending row in the against collection - for comparison. If NULL, then last row is used. -
match_rownum_in - Pass TRUE if you want to make sure that the - same row numbers are used in each collection. If FALSE, then the row numbers - can be different, but the contents of each corresponding row must be the same. -
null_ok_in - Pass TRUE if the assertion routine should - consider two NULL collections to be equal. -
raise_exc_in - If you want the assertion to raise an exception - on failure and stop the test from proceeding, pass TRUE for raise_exc_in. -
- -

- Here is an example of a script that uses utAssert.eqColl (taken from filepath1.pkg - in the Examples directory): -

- -
-PROCEDURE ut_setpath
-IS
-BEGIN
-   /* Populate base collection */
-   ut_dirs.DELETE;
-   ut_dirs.EXTEND(2);
-   ut_dirs(1) := 'c:\temp';
-   ut_dirs(2) := 'e:\demo';
-   
-   /* Call setpath to do the work */
-   setpath ('c:\temp;e:\demo');
-   
-   utAssert.eqColl (
-      'Valid double entry',
-      'fileio.dirs',
-      'fileio.ut_dirs'
-      );
-END;
-
- -

Checking a Procedure or Function throws an exception

- -

- Sometimes we design a procedure or function to throw an exception under certain - circumstances. This is something we'd like to be able to test for. Obviously - this is not particularly easy due to the way exceptions propagate through - the call stack. If we simply call the procedure in our test code, the exception - will have no chance of being caught within the utAssert package! Therefore, - we need to pass the tested call in to the package as a string. The procedure - utAssert.throws allows us to do this: -

- -
-PROCEDURE throws (
-      msg_in VARCHAR2,
-      check_call_in IN VARCHAR2,
-      against_exc_in IN VARCHAR2|NUMBER
-   );
-
-

- Where check_call_in is the call to be made, complete with parameters and - terminating semicolon. The argument against_exc_in is the exception we expect - to be thrown. This can be specified either as a named exception, or a SQLCODE - value. -

-

The following example shows both usages:

- -
-/* Test the Except Function */
-PROCEDURE ut_except
-IS
-BEGIN
-
-   /* Call the procedure with a negative number */
-   /* We expect a NO_DATA_FOUND exception       */
-   utAssert.throws('Negative Number',
-      'Except(-1);',
-      'NO_DATA_FOUND'
-   );
-   
-   /* Call the procedure with zero and a string    */
-   /* over 2 in length - We expect a SQLCODE of -1 */  
-   utAssert.throws('Zero and String',
-      'Except(0, ''Hello'');',
-      -1
-     );
-END;
-
- -

- Note how we have to quote the string parameters to the call and terminate - the string with a semicolon. -

- -

Check if the Previous Assertion Passed or Failed

- -

- Sometimes, a procedure may have a large number of effects that need to be - tested. For example, it might insert and update data in a series of - tables. To test all of these changes, it will be necessary to make - a series of calls to utAssert. This can have the effect that if the - procedure is not behaving as expected, then the user is presented with a - screenful of errors. To avoid this and just present them with a single - error, the functions previous_passed and previous_failed can be used. - These return a BOOLEAN argument giving the success or failure of the previously - called assertion. -

- -

The following example gives a demonstration:

- -
-/* Test the BookTrips Procedure */
-PROCEDURE ut_bookTrips
-IS 
-BEGIN
-
-  /* Call the procedure */
-  Vacation.bookTrips(5, 'Rio de Janeiro');
-  
-  /* Did it insert 5 rows into TRIPS table */
-  utAssert.eqqueryvalue('Insert 5 rows',
-    'SELECT COUNT(*)
-    FROM TRIPS
-    WHERE CITY = ''Rio de Janeiro''',
-    5);
-    
-  /* If that worked, look in more detail */
-  IF utAssert.previous_passed THEN
-    
-    /* Do they all have today's date? */
-    utAssert.eqqueryvalue('All with todays date',
-      'SELECT COUNT(*)
-       FROM TRIPS
-       WHERE CITY = ''Rio de Janeiro'''
-       AND TRUNC(CREATED) = TRUNC(SYSDATE)',
-       5);
-     
-    /* Do they all have a hotel specified? */
-    utAssert.eqqueryvalue('Hotel Specfied',
-      'SELECT COUNT(*)
-       FROM TRIPS T, HOTELS H
-       WHERE T.CITY = ''Rio de Janeiro'''
-       AND T.HOTEL = H.ID',
-       5);
-     
- END IF;
-   
-END;
-
- -

Comparing output from DBMS_OUTPUT

- -

- To complement the utOutput package, these - assertions allow you to easily compare collections of the type - DBMS_OUTPUT.CHARARR. Unlike the eqcoll and - eqcollapi assertions, this allows the comparison of locally defined - collections. The procedures are declared as follows: -

- -
-PROCEDURE eqoutput (
-   msg_in                IN   VARCHAR2,
-   check_this_in         IN   DBMS_OUTPUT.CHARARR,
-   against_this_in       IN   DBMS_OUTPUT.CHARARR,
-   ignore_case_in        IN   BOOLEAN := FALSE,
-   ignore_whitespace_in  IN   BOOLEAN := FALSE,
-   null_ok_in            IN   BOOLEAN := TRUE,
-   raise_exc_in          IN   BOOLEAN := FALSE
-);
-
-PROCEDURE eqoutput (
-   msg_in                IN   VARCHAR2,
-   check_this_in         IN   DBMS_OUTPUT.CHARARR,
-   against_this_in       IN   VARCHAR2,
-   line_delimiter_in     IN   CHAR := NULL,
-   ignore_case_in        IN   BOOLEAN := FALSE,
-   ignore_whitespace_in  IN   BOOLEAN := FALSE,
-   null_ok_in            IN   BOOLEAN := TRUE,
-   raise_exc_in          IN   BOOLEAN := FALSE
-);
-
- -

- The first version simply compares two collections, whereas the second compares a collection against a delimited string. The delimiter - can be specified by the line_delimiter_in parameter. If NULL is passed in (which is the default) then the lines are delimited by carriage returns. - Thus to test a collection mybuff which should look like: -

- -
-   mybuff(0) := 'Zidane';
-   mybuff(1) := 'Ronaldo';
-   mybuff(2) := 'Kahn';
-
- -

we could pass in parameters:

- -
-   check_this_in => 'Zidane|Ronaldo|Kahn';
-   line_delimiter_in => '|';
-
- -

or:

- -
-   check_this_in => 
-'Zidane
-Ronaldo
-Kahn';
-   line_delimiter_in => NULL;
-
- -

There are also the following flags to modify the way that the line-by-line comparisons are carried out:

- - - -

- Finally, note that only the text itself is compared. These assertions do - not care about how the records within the collections are numbered. -

- -

Check for Existence of Database Objects

- -

- The following assertions (created by Raji) check that a named database - object exists or does not exist: -

- -
-PROCEDURE objExists (
-   msg_in            IN   VARCHAR2,
-   check_this_in     IN   VARCHAR2,
-   null_ok_in        IN   BOOLEAN := FALSE,
-   raise_exc_in      IN   BOOLEAN := FALSE
-);
-
-PROCEDURE objnotExists (
-   msg_in            IN   VARCHAR2,
-   check_this_in     IN   VARCHAR2,
-   null_ok_in        IN   BOOLEAN := FALSE,
-   raise_exc_in      IN   BOOLEAN := FALSE
-);
-
- -

- In both cases, the check_this_in parameter gives the name of the object to - check for. So passing 'MYTHING' will check if the MYTHING object exists. This - is assumed to be in the current schema. To check for objects in a schema other - than the current one, simply add the name of the schema, separated by a dot. - So passing 'ANOTHER.THATTHING' will check for the existence of the THATTHING - object in the ANOTHER schema. -

- -

Check Equality of RefCursor and Query

- -

- If you have a procedure or function that returns a REF CURSOR type you - often would like to compare the data of the REF CURSOR against a query (if - your REF CURSOR returns a complete table you can use - utAssert.eq_refc_table below). In this case, - you specify the REF CURSOR of the procedure or function and the full - SELECT statement as parameters. By using eq_refc_query, you may be able to - avoid the huge workload of constructing separate tables with preset data. -

- -

- Before calling the comparison you have to specifiy the parameters of the procedure or function you are going to use. - This is done with the procedures utPLSQL_Util.reg_In_Param, utPLSQL_Util.reg_InOut_Param or utPLSQL_Util.reg_Out_Param. - The details of the parameters are built up in a variable of type utplsql_util.utplsql_params, which is then passed into eq_refc_query. -

- -
-PROCEDURE utPLSQL_Util.reg_In_Param (
-   par_pos            PLS_INTEGER,
-   par_val            VARCHAR2 | NUMBER | DATE,
-   params    IN OUT   utplsql_util.utplsql_params );
-
-PROCEDURE utPLSQL_Util.reg_InOut_Param (
-   par_pos            PLS_INTEGER,
-   par_val            VARCHAR2 | NUMBER | DATE,
-   params    IN OUT   utplsql_util.utplsql_params );
-
-PROCEDURE utPLSQL_Util.reg_Out_Param (
-   par_pos            PLS_INTEGER,
-   par_type           VARCHAR2,
-   params    IN OUT   utplsql_util.utplsql_params );
-
- -

- Having specified all the parameters for the procedure or function - returning the REF CURSOR, the comparison can be started. -

- -
-PROCEDURE utAssert.eq_refc_query (
-   p_msg_nm          IN   VARCHAR2,
-   proc_name         IN   VARCHAR2,
-   params            IN   utplsql_util.utplsql_params,
-   cursor_position   IN   PLS_INTEGER,
-   qry               IN   VARCHAR2 );
-
- -

where the reg_In_Param, reg_InOut_Param and reg_Out_Param-specific parameters are as follows:

- - - - - - - - - - - - - - - - - - -
ParameterDescription
par_pos Defines the parameter position beginning with 1, or 0 specifying the return value
par_type Specifies the data type of the return value and must be one out of 'NUMBER', 'VARCHAR', 'CHAR' or 'REFCURSOR'
params The local variable to keep the values that is used as a parameter for eq_refc_query
- -

and the eq_refc_query-specific parameters are as follows:

- - - - - - - - - - - - - - - - - - - - - - - - - - -
ParameterDescription
p_msg_nm The message to be displayed if the test fails
proc_name Specifies the procedure or function that delivers the REF CURSOR
params The parameter setting for the procedure or function
cursor_position Position of the REF CURSOR parameter to be checked, beginning with 1, or 0 to specify the return value of a function
qry The SELECT statement to be checked against
- -

Finally, note that only the record itself is compared. These assertions do not care about how the records within the cursor are numbered.

- - -

Check Equality of RefCursor and Database Table

- -

- If you have a procedure or function that returns a REF CURSOR type that represents a complete table or view you - often would like to compare the data of this REF CURSOR against the table or view - (if your REF CURSOR doesn't return a complete table or view you can use utAssert.eq_refc_query above). - In this case, you specify the REF CURSOR of the procedure or function and the table or view name as parameters. - By using eq_refc_table, you may be able to avoid the huge workload of constructing separate tables with preset data. -

- -

- Before calling the comparison you have to specifiy the parameters of the procedure or function you are going to use. - This is done with the procedures utPLSQL_Util.reg_In_Param, utPLSQL_Util.reg_InOut_Param or utPLSQL_Util.reg_Out_Param. - The details of the parameters are built up in a variable of type utplsql_util.utplsql_params, which is then passed into eq_refc_query. -

- -
-PROCEDURE utPLSQL_Util.reg_In_Param (
-   par_pos            PLS_INTEGER,
-   par_val            VARCHAR2 | NUMBER | DATE,
-   params    IN OUT   utplsql_util.utplsql_params );
-
-PROCEDURE utPLSQL_Util.reg_InOut_Param (
-   par_pos            PLS_INTEGER,
-   par_val            VARCHAR2 | NUMBER | DATE,
-   params    IN OUT   utplsql_util.utplsql_params );
-
-PROCEDURE utPLSQL_Util.reg_Out_Param (
-   par_pos            PLS_INTEGER,
-   par_type           VARCHAR2,
-   params    IN OUT   utplsql_util.utplsql_params );
-
- -

Having specified all the parameters for the procedure or function returning the REF CURSOR, the comparison can be started.

- -
-PROCEDURE utAssert.eq_refc_table (
-   p_msg_nm          IN   VARCHAR2,
-   proc_name         IN   VARCHAR2,
-   params            IN   utplsql_util.utplsql_params,
-   cursor_position   IN   PLS_INTEGER,
-   table_name        IN   VARCHAR2 );
-
- -

where the reg_In_Param, reg_InOut_Param and reg_Out_Param-specific parameters are as follows:

- - - - - - - - - - - - - - - - - - -
ParameterDescription
par_pos Defines the parameter position beginning with 1, or 0 specifying the return value
par_type Specifies the data type of the return value and must be one out of 'NUMBER', 'VARCHAR', 'CHAR' or 'REFCURSOR'
params The local variable to keep the values that is used as a parameter for eq_refc_query
- -

and the eq_refc_query-specific parameters are as follows:

- - - - - - - - - - - - - - - - - - - - - - - - - - -
ParameterDescription
p_msg_nm The message to be displayed if the test fails
proc_name Specifies the procedure or function that delivers the REF CURSOR
params The parameter setting for the procedure or function
cursor_position Position of the REF CURSOR parameter to be checked, beginning with 1, or 0 to specify the return value of a function
table_name The name of the table name or view to be checked against
- -

Finally, note that only the record itself is compared. These assertions do not care about how the records within the cursor are numbered.

- -

Building Your Own Assertion

- -

- You may want to build assertion routines that fit your specific needs. - If PL/SQL supported inheritance, you could extend the utAssert assertion - routines and then customize them through polymorphism. Lacking this feature, - however, you will write your own procedures that follow the same steps as - the pre-build assertions. In order to integrate the results of your assertion - test into the utResult package, you will want to mimic the utAssert.this procedure. - Here is its current implementation (Release 1.3.2); check the body of the - utAssert package for any changes. -

- -
-PROCEDURE this (
-   msg_in        IN VARCHAR2,
-   check_this_in IN BOOLEAN,
-   null_ok_in    IN BOOLEAN := FALSE,
-   raise_exc_in  IN BOOLEAN := FALSE,
-   register_in   IN BOOLEAN := TRUE
-   )
-IS
-BEGIN
-   IF    NOT check_this_in
-      OR (    check_this_in IS NULL
-          AND NOT null_ok_in)
-   THEN
-      IF register_in
-      THEN
-         -- Registers the results in the utResult databank.
-         utresult.report (msg_in);
-      ELSE
-         utreport.pl (msg_in); -- used to be utplsql.pl (msg_in) (PBA 20050621)
-      END IF;
-      
-      IF showing_results AND register_in
-      THEN
-         -- Show the results of the test more recently run.
-         utresult.showlast;
-      END IF;
-
-      IF raise_exc_in
-      THEN
-         RAISE test_failure;
-      END IF;
-   END IF;
-END;
-
- -

- The most important statement to include in your assertion routine is the - call to utResult.report, which will log the results of the test. -

- -

< Previous Section: utResult Package | Next Section: utGen Package >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/utconfig.html b/docs/utconfig.html deleted file mode 100644 index eaebcf9..0000000 --- a/docs/utconfig.html +++ /dev/null @@ -1,636 +0,0 @@ - - - - - - - - - - - utConfig Package - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: utPLSQL Package | Next Section: utResult Package >

- - -

utConfig Package

- -

This package contains the following functions and procedures:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
utConfig.testerReturn whose configuration is used
utConfig.settesterSet whose configuration is used
utConfig.showconfigView a schema's configuration
utConfig.setdirSet the directory containing the test package code
utConfig.dirReturn the directory containing the test package code
utConfig.setprefixSet the default unit test prefix for your code
utConfig.prefixReturn the default unit test prefix for your code
utConfig.registertestSet the registration mode (manual or automatic)
utConfig.registeringReturn the registration mode
utConfig.autocompileSet autocompile feature
utConfig.autocompilingReturn the autocompile flag
utConfig.setdelimiterSet the V2 delimiter
utConfig.delimiterReturn the V2 delimiter
utConfig.showfailuresonlyTurn off the display of successful tests
utConfig.showingfailuresonlyReturn whether successful test results are shown or not
utConfig.setreporterSets the default Output Reporter to use
utConfig.getreporterGets the name of the default Output Reporter to use
utConfig.setfiledirSet the directory for file output
utConfig.filedirReturn which directory is used for file output
utConfig.setuserprefixSet the user prefix for output file names
utConfig.userprefixReturn the user prefix for output file names
utConfig.setincludeprognameSet whether to include the name of the program being tested in output file names
utConfig.includeprognameReturn whether to include the name of the program being tested in output file names
utConfig.setdateformatSet the date format for the date portion of output file names
utConfig.dateformatReturn the date format used to construct output file names
utConfig.setfileextensionSet the file extension for output file names
utConfig.fileextensionReturn the file extension used for output file names
utConfig.setfileinfoSet all of the above file output related items
utConfig.fileinfoReturn all of the above file output related items
- -

- To make it as easy as possible for you to run your tests, utPLSQL stores - various pieces of configuration data in the ut_config table. This data - is stored by schema name and is automatically loaded into utPLSQL the first - time you use this utility in your session. This configuration information - is also automatically updated whenever you call utPLSQL.test -- or any - of the utPLSQL programs specifically designed to change the configuration - settings. -

- -

- You can at any time view the utPLSQL configuration for the currently-connected - schema or for another schema (there is not at this point any schema-level - security; all utPLSQL users can view the configurations of all other users). -

- -

The data that is currently maintained for a utPLSQL user are:

- -

- Test package directory - the location of the test package code - you want to run. You must specify a directory in order to allow utPLSQL - to automatically compile your test packages before each test run. -

- -

- Unit test prefix - the prefix used for test package names and - the program names within the package. If you do not specify a prefix, the - default of "ut_" is automatically applied. -

- -

- Unit test registration mode - This setting determines whether - utPLSQL will automatically identify the unit tests to be run (strongly - recommended) or if you have chosen to manually register your unit tests - in the test package setup procedure. -

- -

- Auto-compilation of test packages - By default, utPLSQL will - recompile your test package before execution. You can turn off this feature - and manually recompile only when you desire (a fine idea if your test package - has gotten very large!). -

- -

Return whose configuration is being used

- -

- By default, the configuration stored for the currently-connected user will - be used. However, it is possible to use configurations stored against - other usernames. To show whose configuration is currently being used - the following function is used: -

- -
-FUNCTION utConfig.tester RETURN VARCHAR2;
-
- -

Set whose configuration is being used

- -

- This returns the configuration that will be used whenever a username is - not specified. To set this, the following procedure is used: -

- -
-PROCEDURE utConfig.settester (username_in IN VARCHAR2 := USER);
-
- -

View a schema's configuration

- -

- Call the utconfig.showconfig procedure to view the configuration for a specified - schema. The header is: -

- -
-PROCEDURE utConfig.showconfig (username_in IN VARCHAR2 := NULL);
-
- -

- If you do not specify a schema, then the currently - used configuration is returned. Here is an example of output from this - procedure: -

- -
-SQL> exec utconfig.showconfig
-=============================================================
-utPLSQL Configuration for SCOTT
-   Directory: /apps/utplsql/code
-   Autcompile? Y
-   Manual test registration? N
-   Prefix = test_
-=============================================================
-
- -

And here is an example of calling showConfig for a different schema:

- -
-SQL> exec utconfig.showconfig ('COMP')
-=============================================================
-utPLSQL Configuration for COMP
-   Directory: M:\shared_apps\utplsql\comp
-   Autcompile? N
-   Manual test registration? N
-   Prefix = ut_
-=============================================================
-
- -

- You might want to put a call to showConfig in your SQL*Plus login file - so that you are reminded on startup as to what the current settings are. - Here is such a script (to be found in Examples\login_sample.sql): -

- -
-exec utconfig.setdir ('e:\openoracle\utplsql\utinstall\examples')
-SET SERVEROUTPUT ON SIZE 1000000 FORMAT WRAPPED
-exec utconfig.showconfig
-
- -

Set the directory containing the test package code

- -

- If you want utPLSQL to compile your test package, you must tell it the - directory in which your code is found. You can do this either when you - define your test suite and packages within the suite, or you can call the - utConfig.setdir procedure to set the directory for your current session. -

- -

- Note: as of v1.5.1, the value you pass in any of these programs is saved - in the configuration table and will be used in the future -- until you - change it by passing a different value. -

- -

The header for this procedure is:

- -
-PROCEDURE utConfig.setdir (dir_in IN VARCHAR2, username_in IN VARCHAR2 := NULL);
-
- -

- where dir_in is the directory and username_in is the name of the schema - to which this directory applies (NULL means the currently - used configuration is set), as in: -

- -
-SQL> exec utconfig.setdir ('e:\demo\utplsql');
-
- -

or, with the specification of a non-current schema:

- -
-SQL> exec utconfig.setdir ('e:\demo\utplsql', 'ANALYSIS');
-
- -

Note that this directory must be accessible through UTL_FILE.

- -

- You might consider putting the the call to utConfig.setdir into your - login.sql so that it is run automatically, each time your start up SQL*Plus - -- if you are always working from the same directory. -

- -

Return the directory containing the test package code

- -

You can obtain the current directory with a call to utConfig.dir:

- -
-FUNCTION utConfig.dir (username_in IN VARCHAR2 := NULL)
-      RETURN VARCHAR2;
-
- -

Set the default unit test prefix for your code.

- -

- The unit test prefix is very important in utPLSQL; the utility uses the - prefix to associate source code to be tested with the test package. The - prefix also allows utPLSQL to automatically identify the programs within - a test package that are to be executed as unit tests. -

- -

- The default prefix in utPLSQL is "ut_", but you can override this when - you call utPLSQL.test or by calling the utConfig.setprefix procedure: -

- -
-PROCEDURE utConfig.setPrefix (
-   prefix_in IN VARCHAR2, username_in IN VARCHAR2 := NULL)
-
- -

- where prefix_in is the prefix and username_in is the name of the schema - to which this prefix applies (NULL means the currently - used configuration is set), as in: -

- -
-SQL> exec utconfig.setPrefix ('tst#');
-
- -

or, with the specification of a non-current schema:

- -
-SQL> exec utconfig.setPrefix ('t_', 'ANALYSIS');
-
- -

Return the default unit test prefix for your code.

- -

You can obtain the current prefix with a call to utConfig.prefix:

- -
-FUNCTION utConfig.prefix (username_in IN VARCHAR2 := NULL)
-      RETURN VARCHAR2;
-
- -

- uPLSQL currently does not support the use of a suffix, or combination of - suffix and prefix, to identify test packages and unit test procedures. -

- -

Set the registration mode (manual or automatic).

- -

- As of utPLSQL v1.5.1, you no longer have to register your unit test procedures - in the setup procedure of your test package. Instead, utPLSQL will scan - the data dictionary (via theALL_ARGUMENTS view) for the names of all the - unit test procedures you have defined, and then run them. utPLSQL identifies - these programs by looking for all programs whose names start with the specified - prefix. -

- -

- If you so choose, you can request that utPLSQL turn off automatic detection - of unit test procedures and only run those programs listed in the setup - procedure. To do this, you call the utConfig.registerTest procedure: -

- -
-PROCEDURE utConfig.registerTest (
-      onoff_in IN BOOLEAN,
-      username_in IN VARCHAR2 := NULL
-   );
-
- -

as in:

- -
-SQL> exec utConfig.registerTest (TRUE)
-
- -

- Note: if you are using automatic unit test detection, any calls to utPLSQL.addtest - in the setup procedure will be ignored. -

- -

You can return the current registration mode using the following function:

- -
-FUNCTION registeringtest (username_in IN VARCHAR2 := NULL)
-   RETURN BOOLEAN;
-
- -

This returns TRUE if the registration mode has been set to manual and FALSE otherwise.

- -

Set autocompile feature

- -

- The default settings for utPLSQL is to re-compile - your base package before each unit test. This guarantees that any recent - changes will be tested. It also saves you the step of doing an explicit - compile. -

- -

In order to perform automatic compilation:

- - - -

- In general (and the default), you should allow your - test package to be recompiled with each execution. You might want to avoid - recompilation if: -

- - - -

Turning off Auto-compile

- -

- If you are working with products like SQL*Navigator, - you may be always editing from code stored in the database. In this case, - you will never want to have utPLSQL recompile your code for you - it will - already be compiled and you do not need to hassle with UTL_FILE. -

- -

You can avoid auto-recompilation in two ways:

- -

- 1. Pass a value of FALSE for the recompile_in argument - to utPLSQL.test or utPLSQL.testsuite. Here is an example: -

- -
-BEGIN
-   -- Define a test suite for PL/Vision
-   utsuite.add ('PLVision');
-  
-   -- Add two packages for testing
-   utsuite.addpkg (
-      'PLVision', 'PLVstr', dir_in => 'e:\utplsql');
-   utsuite.addpkg (
-      'PLVision', 'PLVdate', dir_in => 'e:\utplsql');
-  
-   -- Run the test suite
-   utplsql.testsuite (
-      'PLVision', recompile_in => FALSE);
-END;
-/
- -

- If you know that you will never want to recompilation, - however, you can set the default behavior at the schema level by calling - the autocompile procedure -

- -
-   PROCEDURE utConfig.autocompile (
-      onoff_in IN BOOLEAN,
-      username_in IN VARCHAR2 := NULL
-   );
-
- -

- So I can make the following - call to turn off autocompilation for the SCOTT schema: -

- -
-SQL> exec utconfig.autocompile (FALSE, 'SCOTT')
-
- -

- This program updates the ut_config table with your information and then - commits the setting. -

- -

- You can determine the current - setting for auto-compilation at any time by calling the following function: -

- -
-   FUNCTION utConfig.autocompiling (username_in IN VARCHAR2 := NULL)
-      RETURN BOOLEAN;
-
- -

- Note: When you set the schema-level recompilation - value to FALSE, that will override anything you pass in a call to utPLSQL.test - or utPLSQL.testsuite. -

- -

V2 Delimiter

- -

You can set the delimiter to be used in V2 procedure names using the following procedure:

- -
-PROCEDURE setdelimiter (
-  delimiter_in IN VARCHAR2, 
-  username_in IN VARCHAR2 := NULL
-); 
-
- -

while the current delimiter can be obtained by the function:

- -
-FUNCTION delimiter (username_in IN VARCHAR2 := NULL)
-  RETURN VARCHAR2;
-
- -

Turn off the display of successful test results

- -

- By default, the results of all the tests are shown. This includes both successful and unsuccessful - results. The following procedure allows you to limit the tests shown to only those that have failed: -

- -
-PROCEDURE showfailuresonly (
-     onoff_in      IN   BOOLEAN,
-     username_in   IN   VARCHAR2 := NULL
-   );
-
- -

the current setting can be obtained by the function:

- -
-FUNCTION showingfailuresonly (username_in IN VARCHAR2 := NULL)
-      RETURN BOOLEAN;
-
- -

Set and Get the default output reporter

- -

- By default, all results are sent to the screen via DBMS_OUTPUT. However, it is possible to use other output reporters as described in more detail - on this page. The following procedure allows you to set which output reporter should be used by default: -

- -
-PROCEDURE setreporter (
-      reporter_in   IN   VARCHAR2
-     ,username_in   IN   VARCHAR2 := NULL
-   );
-
- -

as usual, the current setting can be obtain by the following function:

- -
-FUNCTION getreporter (username_in IN VARCHAR2 := NULL)
-      RETURN VARCHAR2;
-
- - - -

< Previous Section: utPLSQL Package | Next Section: utResult Package >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/utgen.html b/docs/utgen.html deleted file mode 100644 index b0d0cba..0000000 --- a/docs/utgen.html +++ /dev/null @@ -1,844 +0,0 @@ - - - - - - - - - - - utGen Package - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: utAssert Package | Next Section: utOutput Package >

- - -

utGen Package

- -

This package contains the following procedures and functions:

- - - - - - - - - - - - - - - - - - -
utGen.testpkg (basic version)Generate skeleton test packages
- utGen.testpkg (grid version)
- utGen.testpkg_from_file
- utGen.testpkg_from_string -
Generate skeleton test packages with test cases
utGen.pkgstringGet skeleton as a string
- utGen.countRows -
utGen.firstRow -
utGen.firstBodyRow -
utGen.atFirstRow -
utGen.lastRow -
utGen.atLastRow -
utGen.setRow -
utGen.getRow -
utGen.nextRow -
utGen.prevRow -
utGen.showRows -
utGen.nthRow -
Get rows from generated skeleton test package as array
- -

Generate Skeleton Test Packages

- -

- The utGen contains a procedure that allows you to generate a starting point - for a unit test package. This package can be sent to the screen, - a file, a delimited string or - an array (best for interfacing with a front end). - You can generate a stand-alone test package or code "fragments" to be placed - inside an existing source package. -

- -

- We strongly recommend that you use utGen.testpkg - as a starting point for all of your utPLSQL unit test construction. By - taking this approach, you will most easily (and transparently) conform - to the most up to date guidelines for utPLSQL test packages. -

- -

- Note: While utGen.testpkg goes as far as - possible to generate sensible unit test code, you will need to edit this - code before you can compile and use it. -

- -

Here is the header of the testpkg procedure:

- -
-   PROCEDURE utGen.testpkg (
-      package_in IN VARCHAR2,
-      program_in IN VARCHAR2 := '%',
-      samepackage_in IN BOOLEAN := FALSE,
-      prefix_in IN VARCHAR2 := NULL,
-      schema_in IN VARCHAR2 := NULL,
-      output_type_in IN PLS_INTEGER := c_screen,
-      dir_in IN VARCHAR2 := NULL,
-      delim_in IN VARCHAR2 := c_delim
-   );
-
- -

And here is a description of the parameters:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Parameter NameUsage
package_in - The name of the package or stand-alone program for - which a test package is to be generated. -
program_in - The filter to be applied to the list of programs - for which unit test procedures will be generated. So if you only wanted - to generate unit tests for programs that start with "UPD", you would pass - 'UPD%' for this argument. -
samepackage_in - TRUE if you plan to insert the generated code into - the source package, FALSE if you want a stand-alone test package. -
prefix_in - The prefix to be used for the test package and/or - unit test procedures. See section " Organizing Your Test Code" for details. -
schema_in - The schema that owns the package or program specified - by package_in. The default is the currently connected schema. -
output_type_in - The type of output that will receive the generated - code. Valid options are defined as packaged constants: -
    -
  • utGen.c_file
  • -
  • utGen.c_screen
  • -
  • utGen.c_string
  • -
  • utGen.c_array
  • -
- The following sections explain the way you would - work with these constants and the resulting generated code. -
dir_in - The location of the file containing the generated - code. Used only if you specify utGen.c_file for the output type. -
delim_in - The delimiter used to separate lines of generated - code. Used only if you specify utGen.c_string for the output type. -
- -

- Before you use utGen.testpkg, you should make a few - decisions about your generated code: -

- - - -

Here are some examples of using utGen.testpkg:

- -
    -
  1. - Generate to the screen a stand-alone test package for the STR package: -
  2. -
- -
-
-
-SQL> exec utGen.testpkg ('str')
-
-
-
- -
    -
  1. - Generate to the screen unit test code to be embedded inside the STR package: -
  2. -
- -
-
-
-SQL> exec utGen.testpkg ('str', samepackage_in => TRUE)
-
-
-
- -
    -
  1. - Generate to the screen unit test code for all programs whose names contain - "STR" to be embedded inside the STR package,. -
  2. -
- -
-
-
-SQL> exec utGen.testpkg ('str', '%STR%', samepackage_in => TRUE)
-
-
-
- -

- Now let's explore how to direct the generated code - to different types of output. -

- -

Generating to Screen

- -

- The default behavior of utGen.testpkg is to generate - code to your screen (via DBMS_OUTPUT.PUT_LINE). So unless you specify some - other value for output_type_in, the code will be displayed on your screen - or within a window of your PL/SQL IDE (such as TOAD or SQL*Programmer and - so on). You can then transfer that content to a file, or move it to another - window for immediate editing and compilation. -

-

- Here is an example of using utGen.testpkg, while - also spooling to a file: -

- -
-SQL> set serveroutput on size 1000000
-SQL> spool str.pkg
-SQL> exec utgen.testpkg ('str')
-
- -

...out comes the code...

- -
-SQL> spool off
-
- -

- If DBMS_OUTPUT is not enabled in your session, then - utGen.testpkg will not generate any output. -

- -

Generating to File

- -

- If you are working with utGen in a command line - style (ie, you are not using a utGen-enabled GUI), then you will probably - find it most useful to generate testing code directly to file. You do this - by specifying utGen.c_file for the output type. You must also specify the - directory in which you want the files (one for the package specification - and another for the body)created. -

- -

- Here's a generation request that creates two files - named ut_str.pks and ut_str.pkb in the /newcode directory: -

- -
-SQL> exec utgen.testpkg ('str', output_type_in => utGen.c_file, dir_in => '/newcode')
-
- -

Notes on generating to file:

- -
    -
  1. - You do not have to specify a directory if you have previously (in your - current session) called utConfig.setdir to set the default directory for - all file-related utPLSQL operations. The following two lines of code are, - in other words, equivalent to the single line shown above: -
  2. -
- - -
-
-
-SQL> exec utconfig.setdir ('/newcode')
-SQL> exec utgen.testpkg ('str', output_type_in => utGen.c_file);
-
-
-
- -
    -
  1. - You set up the UTL_FILE package (add at least one utl_file_dir entry in - your database parameter initialization file) and make sure your directory - is accessible through UTL_FILE, before this operation can succeed. -
  2. -
- -

Generating to String

- -

- If you are accessing utPLSQL functionality through - a GUI, you might find it more useful to direct output to a string (or array, - see next section). You probably don't want to hassle with UTL_FILE (server-based - file IO) and grabbing information from DBMS_OUTPUT.PUT_LINE is just a general - hassle. -

- -

- If you generate to a string, you can then retrieve - that string value into a local variable and then parse it for display and - manipulation. Here is an example of redirection to string: -

- -
-BEGIN
-   utgen.testpkg ('str', output_type_in => utGen.c_string);
-END;
-
- -

- The generated code is composed of multiple lines - of information, so they need to be separated by a delimiter. The default - delimiter is the vertical bar, '|'. You can override that and provide your - own delimiter. In the following example, I have decided to use the carriage - return character as my delimiter: -

- -
-BEGIN
-   utgen.testpkg (
-      'str',
-      output_type_in => utGen.c_string,
-      delim_in => CHR(10));
-END;
-
- -

- Great, so the code has been put in a string. How - do you get all that generated code? Call the utGen.pkgstring function: -

- -
-FUNCTION utGen.pkgString RETURN VARCHAR2;
-
- -

Generating to Array

- -

- If you are accessing utPLSQL functionality through - a GUI, you might find it more useful to direct output to an array. You - probably don't want to hassle with UTL_FILE (server-based file IO) and - grabbing information from DBMS_OUTPUT.PUT_LINE is just a general hassle. -

- -

- If you generate to an array, you can then retrieve - the individual lines of code in the array through an API provided by utGen - (the array itself is "hidden"). Here is an example of redirection to the - utGen array: -

- -
-BEGIN
-   utgen.testpkg ('str', output_type_in => utGen.c_array);
-END;
-
- -

- Great, so the code has been put in an array. How - do you get all that generated code? Take advantage of the utGen - API to retrieve individual rows in the array, which offers these features: -

- -

Get the number of rows currently in the array:

- -
-   FUNCTION utGen.countRows RETURN PLS_INTEGER;
-
- -

Get the absolute index of the first row in the array:

- -
-   FUNCTION utGen.firstRow RETURN PLS_INTEGER;
-
- -

Get the absolute index of the last row in the array:

- -
-   FUNCTION utGen.lastRow RETURN PLS_INTEGER;
-
- -

- The API offers a set of programs to iterate through - the array, by maintaining a "current row" inside the package. You can: -

- -

- Find out if you are positioned at the first row - in the set: -

- -
-   FUNCTION utGen.atFirstRow RETURN BOOLEAN;
-
- -

- Find out if you are positioned at the last row in - the set: -

- -
-   FUNCTION utGen.atLastRow RETURN BOOLEAN;
-
- -

- Find the first relative row containing the start - of the package body definition. This is handy when you want to put the - code for the specification and body in separate windows and/or files: -

- -
-   FUNCTION utGen.firstBodyRow RETURN PLS_INTEGER;
-
- -

- Retrieve the text in the Nth row of the array. This - gives you "random access" to the contents of the array. You can even specify - a negative direction to get the Nth row from the end of the array. -

- -
-   FUNCTION utGen.nthRow (nth IN PLS_INTEGER, direction utGen.IN SIGNTYPE := 1) RETURN codeline_t;
-
- -

- Set the pointer in the array to the specified row - number. This allows you then move either forward or backward from that - row in the array (using nextRow and prevRow, respectively): -

- -
-   PROCEDURE utGen.setRow (nth IN PLS_INTEGER);
-
- -

- Retrieve the line of code stored in the current - row in the array (set via setRow, nextRow or prevRow): -

- -
-   FUNCTION utGen.getRow RETURN codeline_t;
-
- -

Go to the next row in the array:

- -
-   PROCEDURE utGen.nextRow;
-
- -

Go to the previous row in the array:

- -
-   PROCEDURE utGen.prevRow;
-
- -

Show the contents of the array using DBMS_OUTPUT.PUT_LINE:

- -
-   PROCEDURE utGen.showRows (
-      startRow IN PLS_INTEGER := NULL,
-      endRow IN PLS_INTEGER := NULL);
-
- -

- Here is the code I would write in PL/SQL using this - API to display the contents of the array (actually, it is the implementation - of showRows): -

- -
-   PROCEDURE showrows (
-      startrow IN PLS_INTEGER := NULL,
-      endrow IN PLS_INTEGER := NULL
-   )
-   IS
-      v_start PLS_INTEGER
-                    := NVL (startrow, 1);
-      v_end PLS_INTEGER
-         := NVL (endrow, utGen.countRows);
-   BEGIN
-      FOR indx IN 1 .. utGen.countRows
-      LOOP
-         DBMS_OUTPUT.put_line (utGen.getRow (indx));
-      END LOOP;
-   END;
-
- -

- Here is the code I would write to separate out the - contents of the specification from the body: -

- -
-   PROCEDURE showrows (
-      startrow IN PLS_INTEGER := NULL,
-      endrow IN PLS_INTEGER := NULL
-   )
-   IS
-      v_start PLS_INTEGER
-                    := NVL (startrow, 1);
-      v_end PLS_INTEGER
-         := NVL (endrow, utGen.countRows);
-   BEGIN
-      FOR indx IN 1 .. utGen.countRows
-      LOOP
-         IF indx = utGen.firstBodyRow
-         THEN
-            -- switch to Body window or file
-         END IF;
-         write_to_target (utGen.getRow (indx));
-      END LOOP;
-   END;
-
- - -

Generating Test Packages with Test Cases

- -

- The procedures to generate test packages with test cases are similar to - testpkg above, but with a number of extra parameters: -

- -
- PROCEDURE testpkg (
-      package_in           IN   VARCHAR2,
-      grid_in              IN   grid_tt,
-      program_in           IN   VARCHAR2 := '%',
-      samepackage_in       IN   BOOLEAN := FALSE,
-      prefix_in            IN   VARCHAR2 := NULL,
-      schema_in            IN   VARCHAR2 := NULL,
-      output_type_in       IN   PLS_INTEGER := c_screen,
-      dir_in               IN   VARCHAR2 := NULL,
-      delim_in             IN   VARCHAR2 := c_delim,
-      date_format_in       IN   VARCHAR2 := 'MM/DD/YYYY',
-      only_if_in_grid_in   IN   BOOLEAN := FALSE
-   );
-
-   PROCEDURE testpkg_from_file (
-      package_in           IN   VARCHAR2,
-      gridfile_loc_in      IN   VARCHAR2,
-      gridfile_in          IN   VARCHAR2,
-      program_in           IN   VARCHAR2 := '%',
-      samepackage_in       IN   BOOLEAN := FALSE,
-      prefix_in            IN   VARCHAR2 := NULL,
-      schema_in            IN   VARCHAR2 := NULL,
-      output_type_in       IN   PLS_INTEGER := c_screen,
-      dir_in               IN   VARCHAR2 := NULL,
-      field_delim_in       IN   VARCHAR2 := '|',
-      arg_delim_in         IN   VARCHAR2 := c_delim,
-      date_format_in       IN   VARCHAR2 := 'MM/DD/YYYY',
-      only_if_in_grid_in   IN   BOOLEAN := FALSE
-   );
-
-   PROCEDURE testpkg_from_string (
-      package_in           IN   VARCHAR2,
-      grid_in              IN   VARCHAR2,
-      program_in           IN   VARCHAR2 := '%',
-      samepackage_in       IN   BOOLEAN := FALSE,
-      prefix_in            IN   VARCHAR2 := NULL,
-      schema_in            IN   VARCHAR2 := NULL,
-      output_type_in       IN   PLS_INTEGER := c_screen,
-      dir_in               IN   VARCHAR2 := NULL,
-      line_delim_in        IN   VARCHAR := CHR (10),
-      field_delim_in       IN   VARCHAR2 := '|',
-      arg_delim_in         IN   VARCHAR2 := c_delim,
-      date_format_in       IN   VARCHAR2 := 'MM/DD/YYYY',
-      only_if_in_grid_in   IN   BOOLEAN := FALSE
-   );
-
- -

- In each case, the idea is the same. We have to provide not only the - arguments supplied to the basic version of testpkg, but also details of each of - the test cases in a grid. In the first case, this is as a PL/SQL table, in the - second this is as a file and in the final case, this is as a string. -

- -

The PL/SQL table passed to testpkg is defined as follows:

- -
 
-TYPE grid_rt IS RECORD (
-      progname                      VARCHAR2 (100),
-      overload                      PLS_INTEGER,
-      tcname                        VARCHAR2 (100),
-      message                       VARCHAR2 (2000),
-      arglist                       VARCHAR2 (2000),
-      return_value                  VARCHAR2 (2000),
-      assertion_type                VARCHAR2 (100));
-
-   TYPE grid_tt IS TABLE OF grid_rt
-      INDEX BY BINARY_INTEGER; 
-
- -

Where the definitions of the fields are as follows:

- -
    -
  1. progname - This is the name of the subprogram to be tested.
  2. -
  3. - overload - This is the version of the subprogram where - overladed versions exist. (You may have to look in the data dictionary to - work this out). -
  4. -
  5. tcname - The name of the test case.
  6. -
  7. message - The message to be used in the assertion code.
  8. -
  9. arglist - The list of arguments to be passed to the subprogram.
  10. -
  11. return_value - The return value to be checked against.
  12. -
  13. - assertion_type - The type of assertion to be used. - Currently this is ignored unless it contains 'EQ' or 'ISNULL' -
  14. -
- -

- In testpkg_from_file and testpkg_from_string, exactly the same fields need - to be passed (and in the same order). These fields are separated by the - character given by the field_delim_in parameter which defaults to '|', the pipe - symbol. In the case of testpkg_from_string, we can also specify the line - delimiter in the line_delim_in parameter, which defaults to an ASCII linefeed - character. -

- -

- In all cases, the arguments specified in the arglist field are separated - by yet another delimiter, which is passed in the arg_delim_in parameter ( - or just delim_in in the case of testpkg). This defaults to a semicolon. -

- -

- The remaining arguments passed to these routines are date_format_in and - only_if_in_grid_in. The former gives the date format used in dates passed - through the arglist and return_values fields. The latter specifies if - tests should only be generated for subprograms listed in the grid or not. -

- -

An Example

- -

All of this is probably best explained with an example. Suppose I have a package defined as:

- -
-CREATE OR REPLACE PACKAGE lottery AS
-  FUNCTION Draw (seed_in NUMBER := NULL, when_in DATE := NULL) RETURN VARCHAR2;
-END;
-
- -

- This returns a string describing a lottery draw, given a seed and a date. I - want to test the following conditions: (It doesn't make much sense, but hey, - it's only an example) -

- - - -

So to generate the skeleton I require I could run the following through SQL*Plus:

- -
-set serveroutput on size 1000000
-declare
-  a_grid utgen.grid_tt;
-begin
-  
-  a_grid(0).progname := 'Draw';
-  a_grid(0).tcname := 'Test Case 1';
-  a_grid(0).message := 'The First Test';
-  a_grid(0).return_value := '01 02 03 04 05 06';
-  a_grid(0).assertion_type := 'EQ';
-  a_grid(1).progname := 'Draw';
-  a_grid(1).tcname := 'Test Case 2';
-  a_grid(1).message := 'The Second Test';
-  a_grid(1).arglist := '7;2001-01-01';
-  a_grid(1).return_value := '23 24 27 37 39 48';
-  a_grid(1).assertion_type := 'EQ';
-  a_grid(2).progname := 'Draw';
-  a_grid(2).tcname := 'Test Case 3';
-  a_grid(2).message := 'The Third Test';
-  a_grid(2).return_value := NULL;
-  a_grid(2).arglist := '0;!SYSDATE';
-  a_grid(2).assertion_type := 'ISNULL';
-  
-  utgen.testpkg(
-    package_in => 'LOTTERY', 
-    grid_in => a_grid, 
-    date_format_in => 'YYYY-MM-DD');
-end;
-/
- -

or the equivalent:

- -
-set serveroutput on size 1000000
-begin
-  utgen.testpkg_from_string (
-      package_in => 'LOTTERY',
-      grid_in =>
-'Draw||Test Case 1|The First Test||01 02 03 04 05 06|EQ
-Draw||Test Case 2|The Second Test|7;2001-01-01|23 24 27 37 39 48|EQ
-Draw||Test Case 3|The Third Test|0;!SYSDATE||ISNULL',
-      date_format_in => 'YYYY-MM-DD'
-   );
-end;
-/ 
-
- -

which generate the following for the body of ut_draw (tidied up a little for compactness):

- -
-PROCEDURE ut_DRAW
-IS
-   -- Verify and complete data types.
-   against_this VARCHAR2(2000);
-   check_this VARCHAR2(2000);
-BEGIN
-   
-   -- Define "control" operation for "Test Case 1"
-   against_this := '01 02 03 04 05 06';
-    
-   -- Execute test code for "Test Case 1"
-   check_this := 
-   LOTTERY.DRAW (SEED_IN => '', WHEN_IN => '');
-    
-   -- Assert success for "Test Case 1"
-   -- Compare the two values.
-   utAssert.eq ( 'The First Test', check_this, against_this);
-
-   -- End of test for "Test Case 1"
-   
-   -- Define "control" operation for "Test Case 2"
-   against_this := '23 24 27 37 39 48';
-    
-   -- Execute test code for "Test Case 2"
-   check_this := LOTTERY.DRAW (SEED_IN => 7, WHEN_IN => TO_DATE ('2001-01-01', 'YYYY-MM-DD'));
-    
-   -- Assert success for "Test Case 2"
-   -- Compare the two values.
-   utAssert.eq ( 'The Second Test', check_this, against_this);
-
-   -- End of test for "Test Case 2"
-   
-   -- Define "control" operation for "Test Case 3"
-   against_this := NULL;
-    
-   -- Execute test code for "Test Case 3"
-   check_this := 
-   LOTTERY.DRAW (SEED_IN => 0, WHEN_IN => SYSDATE);
-    
-   -- Assert success for "Test Case 3"
-   -- Check for NULL return value.
-   utAssert.isNULL ( 'The Third Test', check_this);
-
-   -- End of test for "Test Case 3"
-   
-END ut_DRAW;
-
- -

- Note that the different data types are handled automatically. So '2001-01-01' is converted to - a date using TO_DATE and the specified date format. However, we wanted to enter SYSDATE for our - argument in one of these cases. How do we stop this being converted into a date? The answer - is that we need to prefix the value with a '!' (an exclamation mark). This causes utGen to - pass this along 'as is' without attempting any conversion. Note that this cannot currently - be overridden, so if your data starts with an exclamation mark, you'll have to work around - this problem. -

- - -

< Previous Section: utAssert Package | Next Section: utOutput Package >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/utoutput.html b/docs/utoutput.html deleted file mode 100644 index 51107ad..0000000 --- a/docs/utoutput.html +++ /dev/null @@ -1,233 +0,0 @@ - - - - - - - - - - - utOutput Package - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: utGen Package | Next Section: utRecEq Package >

- - -

utOutput Package

- -

This package contains the following procedures and functions:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
utOutput.saveTurn on the 'save' flag
utOutput.nosaveTurn off the 'save' flag
utOutput.savingReturn the 'save' flag
utOutput.extractPull text from the DBMS_OUTPUT buffer
utOutput.replaceReplace saved output in the DBMS_OUTPUT buffer
utOutput.nextLinePull the next line from the DBMS_OUTPUT buffer
utOutput.countCount the lines in the DBMS_OUTPUT buffer
- -

Outline of Usage

- -

- The problem with attempting to test output in PL/SQL is that there is a single - DBMS_OUTPUT buffer. When your test is run, there may already be output in the - buffer from other tests, or from the tested code. So what state should you - leave it in once you have finished? Perhaps you want all the output created by - your tested code to end up in the buffer as if it had been run normally (i.e. - not from within utPLSQL), or maybe you want only the text that was in the - buffer before you started to be left. -

- -

- This package attempts to allow to do any of these. There is a flag in the - package to determine whether text pulled from the output buffer should be - saved. This is set with 'save' and 'nosave' and returned by - 'saving'. Data is pulled from the buffer using 'extract', - while the procedure 'replace' puts any saved data back into the output - buffer. -

- -

The intent is that it is used like this:

- -
-PROCEDURE ut_my_test IS
-BEGIN
-
-  --Pull out any text already in the output buffer
-  utoutput.save;
-  utoutput.extract;
-
-  --Your testing code here, with saving turned on or off as you see fit
-
-  --Put text back in the output buffer 
-  utoutput.replace;
-
-END;
-
- -

- So to start with, we save any text already in the buffer. We then carry out - our testing. If we want the output generated by the testing to end up back in - the output buffer, we turn on saving. Finally, we put the saved text back. -

- -

Warning

- -

- In the current version of utPLSQL (2.0.9.1) use of this package is virtually impossible with - utPLSQL tracing turned on. The reason for this is that this facility writes output using - DBMS_OUTPUT every time an assertion is called. -

- -

Saving Output

- -

The three routines for handling the save flag are:

- -
-PROCEDURE save;
-
-PROCEDURE nosave;
-
-FUNCTION saving RETURN BOOLEAN;
-
- -

- Quite simply, 'save' turns the flag on, 'nosave' turns it off and 'saving' - returns its current value. -

- -

Extracting Output

- -

There are 4 versions of the extract routine to get text from the output buffer:

- -
-FUNCTION extract (
-   buffer_out    OUT DBMS_OUTPUT.CHARARR,
-   max_lines_in  IN INTEGER := NULL,
-   save_in       IN BOOLEAN := saving
-) RETURN INTEGER;
-
-PROCEDURE extract (
-   buffer_out    OUT DBMS_OUTPUT.CHARARR,
-   max_lines_in  IN INTEGER := NULL,
-   save_in       IN BOOLEAN := saving
-);
-
-FUNCTION extract(
-   max_lines_in  IN INTEGER := NULL,
-   save_in       IN BOOLEAN := saving
-) RETURN INTEGER;
-
-PROCEDURE extract(
-   max_lines_in  IN INTEGER := NULL,
-   save_in       IN BOOLEAN := saving
-);
-
- -

- The function versions return the number of lines extracted from the - DBMS_OUTPUT buffer. The other parameters are used as follows: -

- - - -

Replacing Output

- -

The replace procedure takes no parameters:

- -
-PROCEDURE replace;   
-
- -

- It simply puts the saved text back into the DBMS_OUTPUT buffer. Note that - the buffer is emptied at this point. -

- -

Checking Output Line-by-Line

- -

- The nextLine function makes it easy to check output line-by-line as it - simply extracts and returns the next line of output: -

- -
-FUNCTION nextLine(
-  raise_exc_in BOOLEAN := TRUE, 
-  save_in BOOLEAN := saving
-) RETURN VARCHAR2;   
-
- -

- The raise_exc_in flag determines if the function should throw the - exception utOutput.EMPTY_OUTPUT_BUFFER when asked for the next line from - an empty buffer. If no exception is thrown, NULL is returned. As with - extract, the save_in flag simply overrides the global save flag setting. -

- -

Size of Output

- -

This function simply counts the number of lines present in the output buffer:

- -
-FUNCTION count RETURN INTEGER;   
-
- -

Note that the output itself is left untouched.

- - -

< Previous Section: utGen Package | Next Section: utRecEq Package >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/utplsql.css b/docs/utplsql.css deleted file mode 100644 index fe4a5d0..0000000 --- a/docs/utplsql.css +++ /dev/null @@ -1,39 +0,0 @@ -/* utPLSQL Stylesheet */ -/*$Id$*/ - -/* For top-level headings and utPLSQL logo, we want a - purple bar across the page */ -H1, .purple_bar {font-family: Arial, Helvetica, Sans-Serif; - color: #ffffff; - background: #800080; - margin-left: 0px; - margin-right: 0px; - padding-left: 10px; - padding-top: 5px; - padding-bottom: 5px} - -/* Second level headings in purple */ -H2 {font-family: Arial, Helvetica, Sans-Serif; - color: #800080} - -/* Other headings in Sans Serif Font */ -H3, H4, H5, H6 {font-family: Arial, Helvetica, Sans-Serif} - -/* Pre formatted code is in a gray box, in monotype */ -Pre {font-family: Courier, Monotype; - font-size: smaller; - color: #000000; - background: #f0f0f0; - margin-left: 20px; - margin-right: 20px; - padding-left: 10px; - padding-top: 5px; - padding-bottom: 5px; - padding-right: 10px} - -/* Code in monotype */ -Code {font-family: Courier, Monotype; - font-size: smaller;} - -/* Copyright notice is tiny */ -.copyright {font-size: xx-small} diff --git a/docs/utplsql.html b/docs/utplsql.html deleted file mode 100644 index 339d5c7..0000000 --- a/docs/utplsql.html +++ /dev/null @@ -1,703 +0,0 @@ - - - - - - - - - - - utPLSQL Package - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: User Guide | Next Section: utConfig Package >

- - -

utPLSQL Package

- -

The utPLSQL package offers the following capabilities:

- - - - - - - - - - - - - - - - - - - - - - -
- utPLSQL.test
- utPLSQL.run -
- Run a test -
- utPLSQL.testsuite
- utPLSQL.runsuite -
- Run a test suite -
- utPLSQL.version - - Get the version of utPLSQL -
- utPLSQL.trc
- utPLSQL.notrc
- utPLSQL.tracing -
- Control utPLSQL's tracing mechanism -
- utPLSQL.addtest - - Register a unit test in a test package -
- -

Run a Test or Test Suite

- -

- With utPLSQL, you can run all the unit tests contained in a - single test package, or run the tests for a series of test packages defined in - a test suite. -

- -

- The utPLSQL package offers two procedures, test and testsuite, to make it - easy for you to run "red light, green light" tests. Before you can - use these programs, however, you must build - your own test package. -

- -

To run a test for a single package, use the utPLSQL.test procedure:

- -
-PROCEDURE utPLSQL.test (
-   package_in IN VARCHAR2,
-   samepackage_in IN BOOLEAN := FALSE,
-   prefix_in IN VARCHAR2 := NULL,
-   recompile_in IN BOOLEAN := TRUE,
-   dir_in IN VARCHAR2 := NULL,
-   suite_in in VARCHAR2 := NULL,
-   owner_in IN VARCHAR2 := NULL,
-   reset_results_in IN BOOLEAN := TRUE ,
-   from_suite_in         IN   BOOLEAN := FALSE,
-   subprogram_in         IN   VARCHAR2 := '%',
-   per_method_setup_in   IN   BOOLEAN := FALSE
-);
-
- -

where the parameters are defined as follows:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- package_in - - The name of the package or stand-alone program to be tested. -
- samepackage_in - - Pass TRUE if your unit test programs are defined in the same - package as the source code to be tested. The default is that you have created - a separate package. -
- prefix_in - - The prefix to be appended to package_in to come up with - the name of the test package. If you do not provide a value, the last prefix - you specified (or the default) will be used. -
- recompile_in - - Pass FALSE if you do not want utPLSQL to automatically recompile your test package - before running the test. -
- dir_in - - The directory containing the test package source code. If - you do not provide a value in your call to utPLSQL.test (the default) and if - you have not turned off automatic recompilation, utPLSQL will look for the - test package source code in the directory specified by a call to utConfig.setdir. If you do not provide a - value, the last directory you specified (if any) will be used. -
- suite_in - - The name of the suite that contains the specified test - package. This is an optional value and is used to update statistics - for the test. -
- owner_in - - The name of the schema that was specified when the test - suite was defined and the packaged added to the suite. This is an - optional value and is used to update statistics for - the test. -
- reset_results_in - - Pass FALSE to tell utPLSQL to not reset the results - information, in which case you will still be able to view results by calling utResult.show . Otherwise, utPLSQL clears the result - data after each test. -
- from_suite_in - - Pass TRUE to tell utPLSQL that this test is being run from - within a test suite (for internal use only). -
- subprogram_in - - Pass a string to restrict which of the test procedures - will be executed for this run. Default of % means all tests will be run. -
- per_method_setup_in - - Pass TRUE to run the setup and teardown procedure before - and after each unit test procedure is executed. Default of FALSE means that - these programs will be run once, at the start and end of the package test - execution as a whole. -
- override_package_in - - Override the automatic determination of package names thus removing the - one to one relationship between test package and package to test. - Default is NULL. Instead of using this parameter consider the procedure run. -
- -

Here are some examples of using the utPLSQL.test procedure:

- -

- 1. Run the unit test for the betwnstr function (by executing the ut_betwnstr - test package, since the default prefix is used). Do not recompile the test - package. -

- -
-SQL> exec utPLSQL.test ('betwnstr', recompile_in => FALSE)
-
- -

- 2. Run all of the unit tests for the te_employee package, - stored in a test package called "test_te_employee" in the /tmp - directory. Recompile the test package before execution. -

- -
-SQL> exec utPLSQL.test ('te_employee', prefix_in => 'test_', dir_in => '/tmp')
-
- -

- 3. Run all the unit tests for the corporate_polluters - package, located in the same package as the source code. -

- -
-SQL> exec utPLSQL.test ('te_employee', samepackage_in => TRUE)
-
- -

- Since utPLSQL follows the red light-green light approach on - reporting results, each time you run utPLSQL.test, it will display the results. - If successful, you will see output like this: -

- -
-SUCCESS: "betwnstr"
-
- -

If the test fails at some point, you will see output like this:

- -
-FAILURE: "betwnstr"
-BETWNSTR: IS NULL: NULL start
-BETWNSTR: End larger than string length; expected "cdeg", got "cdefg"
-
- - -

Running a Test the other way

- -

- The normal usage of the test procedure as described above assumes that for - each package you want to test, say mypackage, has a package for - testing this package having the same name but with an additional prefix: - ut_mypackage. Instead of using this approach, you can use the procedure - run. This procedure runs a test package directly without any further - conditions on the name or other packages. The only condition that still applies - is the naming conventions necessary to make it a valid test package. -

- -
-PROCEDURE run (
-    testpackage_in      IN VARCHAR2,
-    prefix_in           IN VARCHAR2 := NULL,
-    suite_in            IN VARCHAR2 := NULL,
-    owner_in            IN VARCHAR2 := NULL,
-    reset_results_in    IN BOOLEAN  := TRUE,
-    from_suite_in       IN BOOLEAN  := FALSE,
-    subprogram_in       IN VARCHAR2 := '%',
-    per_method_setup_id IN BOOLEAN  := FALSE);
-
- -

where the parameters are defined as follows:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- test_package_in - - The name of the test package to run. -
- prefix_in - - The prefix to be appended to package_in to come up with - the name of the test package. If you do not provide a value, NULL is used as - a default. i.e. the package name is used as provided in the first parameter -
- suite_in - - The name of the suite that contains the specified test - package. This is an optional value and is used to update statistics - for the test. -
- owner_in - - The name of the schema that was specified when the test - suite was defined and the packaged added to the suite. This is an - optional value and is used to update statistics for - the test. -
- reset_results_in - - Pass FALSE to tell utPLSQL to not reset the results - information, in which case you will still be able to view results by calling utResult.show . Otherwise, utPLSQL clears the result - data after each test. -
- from_suite_in - - Pass TRUE to tell utPLSQL that this test is being run from - within a test suite (for internal use only). -
- subprogram_in - - Pass a string to restrict which of the test procedures - will be executed for this run. Default of '%' means all tests will be run. -
- per_method_setup_in - - Pass TRUE to run the setup and teardown procedure before - and after each unit test procedure is executed. Default of FALSE means that - these programs will be run once, at the start and end of the package test - execution as a whole. -
- - - -

Running a Test Suite

- -

- In addition to running a test for a single test package, you - can set up a test suite that consists of one or more test packages. You can - then run an entire suite of tests with a call to utPLSQL.testsuite: -

- -
-PROCEDURE utPLSQL.testsuite (
-   suite_in IN VARCHAR2,
-   recompile_in IN BOOLEAN := TRUE,
-   reset_results_in IN BOOLEAN := TRUE
-   per_method_setup_in in BOOLEAN := FALSE
-   );
-
- -

- where suite_in is the name of the suite and recompiled_in - determines the auto compilation behavior. -

- -

- Here is an example of the call I would make to run all my tests for the - PL/Vision library: -

- -
-SQL> exec utplsql.testsuite ('plvision');
-
- -

- The parameter list for utPLSQL.testSuite is much shorter - than utPLSQL.test; rather than pass information like directory, owner name and - same-package through a parameter list, you define these characteristics in the - suite itself (stored in a series of utPLSQL tables). -

- -

- Before you can test an entire suite, you must define - the suite. -

- - -

Running a Test Suite the other way

- -

- Similiar to the run procedure for single packages, there is the - runsuite procedure to run testsuites. When you use this procedure - there is no relationship assumed between the names of test packages specified in the - test suite and the procedures to be tested. -

- -
-PROCEDURE utPLSQL.runsuite (
-   suite_in IN VARCHAR2,
-   reset_results_in IN BOOLEAN := TRUE
-   per_method_setup_in in BOOLEAN := FALSE
-   );
-
- -

- The usage of the parameters is just as in testsuite. -

- - -

Recording and Accessing Test Statistics

- -

- If you have defined test suites, and packages within those - test suites, utPLSQL will update those definitions with the follow statistics - after each test is run: -

- - - -

- All of this is done for you automatically. You can then write queries and reports against the - ut_package and ut_suite tables. -

- - -

Return utPLSQL version

- -

- Run the utPLSQL.version function to return the version of - utPLSQL you have installed: -

- -
-FUNCTION utPLSQL.version RETURN VARCHAR2
-
- -

utPLSQL Trace

- -

These routines are very simple and take no arguments:

- -
-PROCEDURE trc;
-
-PROCEDURE notrc;
-
-FUNCTION tracing RETURN BOOLEAN;
-
- -

- The procedures trc and notrc are used to turn tracing on and off - respectively. The function tracing returns TRUE if tracing is currently turned - on and FALSE otherwise. This facility is useful when writing code in utPLSQL - (the framework itself, not your test code). An example of the output generated - is: -

- -
-Initialized utPLSQL session...
-Setpkg to Lottery
-Package and program = ut_Lottery
-Same package? N
-Is package? Y
-Prefix = ut_
-Recompiling ut_Lottery in
-Runprog of ut_SETUP
-Package and program = ut_Lottery.ut_SETUP
-Same package? N
-Is package? Y
-Prefix = ut_
-Addtest
-Package and program = Lottery.UT_DRAW
-Same package? N
-Override? Y
-Prefix = ut_
-Runprog of UT_DRAW
-Package and program = ut_Lottery.UT_DRAW
-Same package? N
-Is package? Y
-Prefix = ut_
-.
->  FFFFFFF   AA     III  L      U     U RRRRR   EEEEEEE
->  F        A  A     I   L      U     U R    R  E
->  F       A    A    I   L      U     U R     R E
->  F      A      A   I   L      U     U R     R E
->  FFFF   A      A   I   L      U     U RRRRRR  EEEE
->  F      AAAAAAAA   I   L      U     U R   R   E
->  F      A      A   I   L      U     U R    R  E
->  F      A      A   I   L       U   U  R     R E
->  F      A      A  III  LLLLLLL  UUU   R     R EEEEEEE
-.
-FAILURE: "Lottery"
-.
-> Individual Test Case Results:
->
-FAILURE - EQ "Test of DRAW" Expected "01 02 05 27 43 49" and got "02 04 27 28 31 33"
->
->
-> Errors recorded in utPLSQL Error Log:
->
-> NONE FOUND
-Runprog of ut_TEARDOWN
-Package and program = ut_Lottery.ut_TEARDOWN
-Same package? N
-Is package? Y
-Prefix = ut_
-
-PL/SQL procedure successfully completed.
-
- -

Register a Unit Test

- -

- As of version 1.4.1, you - no longer have to explicitly register a unit test! The default - behavior of utPLSQL is now to extract from the data dictionary (via the - ALL_ARGUMENTS data dictionary view) the names of all the unit test procedures - you have defined, and then run them. utPLSQL identifies these programs by - looking for all programs whose names start with the specified prefix. -

- -

- If you decide that you want to explicitly register your unit - tests, then you will need to turn on manual registration: -

- -
-SQL> exec utConfig.registertest (TRUE)
-
- -

- This setting is immediately saved in the database for your - schema. To turn off manual registration: -

- -
-SQL> exec utConfig.registertest (FALSE)
-
- -

- So read no further unless you have turned on manual - registration! You might do this, for example, if you have already built a - number of test packages in a version of utPLSQL prior to 1.4.1 and do not want - to make any changes to your test package code. -

- -

- All aspects of manual registration of unit tests for a - program or package actually occur within the Unit Test Package itself, in the setup procedure. No persistent unit test information - is stored between runs of the unit test, unless you define that unit test - within a test suite. -

- -

Use the utPLSQL.addtest procedure to register a unit test.

- -
-   PROCEDURE utPLSQL.addtest (
-      NAME_IN IN VARCHAR2,
-      utprefix_in IN VARCHAR2,
-      iterations_in IN PLS_INTEGER := 1
-   );
- 
-   PROCEDURE utPLSQL.addtest (
-      package_in IN VARCHAR2,
-      NAME_IN IN VARCHAR2,
-      utprefix_in IN VARCHAR2,
-      iterations_in IN PLS_INTEGER := 1
-   );
-
- -

where

- -

- name_in is the name of the program you are - testing. Note that this is the name of the unit test procedure itself, - including the unit test prefix.. -

- -

- utprefix_in is the prefix to be applied to - name_in to construct the unit tst procedure. This is currently NOT IN USE; only - the package prefix specified in your call to utPLSQL.test and utPLSQL.testsuite - is used. -

- -

- iterations_in is the number of times you wish to - run the test (currently NOT IN USE). -

- -

- package_in is the name of the package containing - the unit test procedure. If you provide a package name when you call - utPLSQL.addtest, you will override the package name set when you called - utPLSQL.test -- but only for that one test. We recommend that you not change - the package name. -

- -

- Here is a setup procedure that sets up a series of tests for - a query-only encapsulation of the employee table: -

- -
-CREATE OR REPLACE PACKAGE BODY ut_te_employee
-IS
-   PROCEDURE ut_setup
-   IS
-   BEGIN
-      utplsql.addtest ('UT_EMP_DEPT_LOOKUPROWCOUNT');
-      utplsql.addtest ('UT_EMP_JOB_LOOKUPROWCOUNT');
-      utplsql.addtest ('UT_EMP_MGR_LOOKUPROWCOUNT');
-      utplsql.addtest ('UT_HIRE_DATE$VAL');
-      utplsql.addtest ('UT_I_EMPLOYEE_NAME$ROW');
-      utplsql.addtest ('UT_I_EMPLOYEE_NAME$VAL');
-      utplsql.addtest ('UT_ONEROW');
-      utplsql.addtest ('UT_PKYROWCOUNT');
-      utplsql.addtest ('UT_ROWCOUNT');
-      utplsql.addtest ('UT_SALARY$VAL');
-   END;
-
- -

- Once you have placed your addtest programs into your test - package's setup procedure, you are ready to build your own unit tests. -

- - - -

< Previous Section: User Guide | Next Section: utConfig Package >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/utplsql.jpg b/docs/utplsql.jpg deleted file mode 100644 index 288ee26..0000000 Binary files a/docs/utplsql.jpg and /dev/null differ diff --git a/docs/utreceq.html b/docs/utreceq.html deleted file mode 100644 index 6f71a85..0000000 --- a/docs/utreceq.html +++ /dev/null @@ -1,148 +0,0 @@ - - - - - - - - - - - utRecEq Package - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: utOutput Package | Next Section: Defining Test Suites >

- - -

utRecEq Package

- -

This package contains the following procedures and functions:

- - - - - - - - - - - - - - -
utRecEq.addAdd a record type comparison function
utRecEq.compileCompile a package's record type comparison functions
utRecEq.remRemove record type comparison functions
- -

Generate functions to compare record types

- -

- This package (created by Dan Spencer) allows the creation of functions to - allow the comparison of record types based on tables or views (%ROWTYPE - records in other words). They are generated by the add procedure: -

- -
-PROCEDURE add(
-   pkg_name_in IN ut_package.name%TYPE,
-   record_in  IN ut_receq.name%TYPE,
-   rec_owner_in  IN ut_receq.created_by%TYPE := USER
-);
-
- -

- The pkg_name_in parameter contains the name of a tested package you wish to - associate with this record type. Note that this package name should already - exist in the ut_package table. The record_in parameter contains the name of - the view or table whose record type is to be compared. The final (optional) - parameter contains the name of the schema in which the table or view exists. - It defaults to the current user. -

- -

- The generated function will be named EQ_{Record_Schema_}Record_Name. The - schema is only inserted when the record type is not within the current one. The - function will return TRUE if the two records are identical on a field-by-field - comparison and FALSE otherwise. Note that NULL fields are considered - equal. -

- -

- The details of the EQ_* functions and their association with tested packages held in two tables: -

- - - -

Compile a package's record comparison functions

- -

This routine recompiles all the EQ_* functions associated with a given package:

- -
-PROCEDURE compile(pkg_name_in IN ut_package.name%TYPE);
-
- -

- when autocompiling is turned on, this is called by - utplsql.test or utplsql.testsuite before the test packages themselves are recompiled. -

- -

Remove record comparison functions

- -

To remove record comparison functions, use the following:

- -
-PROCEDURE rem(
-   name_in  IN ut_receq.name%TYPE,
-   rec_owner_in   IN ut_receq.created_by%TYPE := USER
-   for_package_in IN BOOLEAN := FALSE
-);
-
- -

- If for_package_in is FALSE, then name_in is taken to refer to a record type to - remove, with rec_owner_in specifying the schema the record type is in. All package associations for this record type are removed and the EQ_* function is dropped. -

- -

- On the other hand, if for_package_in is TRUE, then name_in is taken to refer - to a package. In this case, all the package's associations are removed. If no - other package is associated with a given record, then the EQ_* function is - dropped. (Note that the rec_owner_in parameter is ignored here). -

- - -

< Previous Section: utOutput Package | Next Section: Defining Test Suites >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/docs/utresult.html b/docs/utresult.html deleted file mode 100644 index 49103fc..0000000 --- a/docs/utresult.html +++ /dev/null @@ -1,200 +0,0 @@ - - - - - - - - - - - utResult Package - - - - - - - - -
utPLSQL logo
-

[ Home - | Getting Started - | Build Test Packages - | Examples - | User Guide - | Release Notes - | Document Map ]

-

< Previous Section: utConfig Package | Next Section: utAssert Package >

- - -

utResult Package

- -

This package contains the following procedures and functions:

- - - - - - - - - - - - - - - - - - - - - - -
- utResult.init - - Initialize the results data -
- utResult.show -
utResult.showone -
utResult.showlast -
- Show results -
- utResult.success -
utResult.failure -
- Show the success or failure of the last test -
- utResult.firstresult -
utResult.nextresult -
utResult.nthresult -
utResult.resultcount -
- Iterate through the results array -
- utResult.include_successes
- utResult.ignore_successes -
- Control the display of passed tests -
- -

- The utResult package offers an API to the information - sent by the various utAssert assertion routines after a test is run. If - you employ the utPLSQL.test and utPLSQL.testsuite to run your tests, then - the results will be displayed by calling the utResult.show procedure. -

-

- So, generally, you do not have to do anything to see or evaluate the results of - a test (or suite of tests). The information will be displayed on your screen - using DBMS_OUTPUT, or elsewhere if you use a custom output reporter. You might, - however, want to access this information in another environment (say, Oracle - Forms or Java, etc.). You might also want to build your own assertion logic or - test engine. In either of these cases, you will want to use the programs in the - utResult package. -

- -

Initialize

- -

Initialize the utResult data, setting it all back to NULL:

- -
-PROCEDURE utResult.init;
-
- -

Show Results

- -

Show the results of your test with one of the following three procedures.

- -
-PROCEDURE utResult.show (reset_in IN BOOLEAN := FALSE);
-PROCEDURE utResult.showone (indx_in in pls_integer);
-PROCEDURE utResult.showlast;
-
- -

- Use the show procedure to display the full set of results stored - in the utResult array. If you pass TRUE for its single argument, the results - informatino will be initialized. -

- -

Use the showone procedure to show the Nth result.

- -

Use the showlast procedure to show the results of the last test run.

- -

Retrieve Test Status

- -

- The success and failure functions return the status of the most recently - executed test. -

- -
-FUNCTION utResult.success RETURN BOOLEAN;
-FUNCTION utResult.failure RETURN BOOLEAN;
-
- -

Scan Results Array

- -

- The utPLSQL.show procedure iterates through the contents of the utResult - array and displays the information found there. You can write the same - kind of logic by calling a combination of the following programs: -

- -
-PROCEDURE utResult.firstresult;
-
-FUNCTION utResult.nextresult RETURN utResult.result_rt;
-
-PROCEDURE utResult.nextresult (
-   name_out OUT VARCHAR2,
-   msg_out OUT VARCHAR2,
-   case_indx_out OUT PLS_INTEGER
-);
-
-FUNCTION utResult.nthresult (indx_in IN PLS_INTEGER)
-   RETURN utResult.result_rt;
-
-PROCEDURE utResult.nthresult (
-   indx_in IN PLS_INTEGER,
-   name_out OUT VARCHAR2,
-   msg_out OUT VARCHAR2,
-   case_indx_out OUT PLS_INTEGER
-);
-
-FUNCTION utResult.resultcount RETURN PLS_INTEGER;
-
- -

Control the Display of Success Messages

- -

- The following procedures turn on or off the display of success messages. In other words, - when turned on (as is the default) a message will be displayed for each successful assertion. - The specifications are as follows: -

- -
-procedure include_successes;
-procedure ignore_successes; 
-
- - -

< Previous Section: utConfig Package | Next Section: utAssert Package >

- -
utPLSQL logo
- -

- - Valid XHTML 1.0 Strict - -

- - - - \ No newline at end of file diff --git a/documenation.md b/documenation.md deleted file mode 100644 index c9eeefb..0000000 --- a/documenation.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -layout: page -title: Documentation -permalink: /documentation/ ---- - -We automatically publish the documentation of utPLSQL development branch with every build. -Each downloadable release also contains a "docs" folder with complete documentation for that release. - -**Latest documentation and documentation for individual versions is available [here](/utPLSQL/)** diff --git a/downloads.md b/downloads.md deleted file mode 100644 index bceadd9..0000000 --- a/downloads.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -layout: page -title: Downloads -permalink: /downloads/ ---- - -[Latest Release](https://github.com/utPLSQL/utPLSQL/releases/latest) - -Older releases can be found on our [releases page](https://github.com/utPLSQL/utPLSQL/releases). - -You can find the latest source code for [utPLSQL on GitHub](https://github.com/utplsql/utplsql) diff --git a/feed.xml b/feed.xml deleted file mode 100644 index a6628bd..0000000 --- a/feed.xml +++ /dev/null @@ -1,30 +0,0 @@ ---- -layout: null ---- - - - - {{ site.title | xml_escape }} - {{ site.description | xml_escape }} - {{ site.url }}{{ site.baseurl }}/ - - {{ site.time | date_to_rfc822 }} - {{ site.time | date_to_rfc822 }} - Jekyll v{{ jekyll.version }} - {% for post in site.posts limit:10 %} - - {{ post.title | xml_escape }} - {{ post.content | xml_escape }} - {{ post.date | date_to_rfc822 }} - {{ post.url | prepend: site.baseurl | prepend: site.url }} - {{ post.url | prepend: site.baseurl | prepend: site.url }} - {% for tag in post.tags %} - {{ tag | xml_escape }} - {% endfor %} - {% for cat in post.categories %} - {{ cat | xml_escape }} - {% endfor %} - - {% endfor %} - - diff --git a/index.html b/index.html deleted file mode 100644 index 05cf033..0000000 --- a/index.html +++ /dev/null @@ -1,25 +0,0 @@ ---- -layout: default ---- - -
- -

Announcements

- - - -

subscribe via RSS

- -
diff --git a/mkdocs.yml b/mkdocs.yml new file mode 100644 index 0000000..021ede6 --- /dev/null +++ b/mkdocs.yml @@ -0,0 +1,136 @@ +# Format documented here +# http://www.mkdocs.org/user-guide/configuration/ +# https://squidfunk.github.io/mkdocs-material/getting-started/ + +site_url: https://www.utplsql.org/ +site_name: utPLSQL +remote_branch: mkdocs_site +remote_name: origin +site_description: utPLSQL Ultimate Testing Framework for Oracle PL/SQL +copyright: > + Copyright © 2016 - 2026 utPLSQL Team + Change cookie settings +extra_css: + - assets/topbar.css + - stylesheets/extra.css +theme: + name: material + custom_dir: docs/overrides + palette: + # Palette toggle for light mode + - media: "(prefers-color-scheme: light)" + scheme: default + toggle: + icon: material/lightbulb-outline + name: Switch to dark mode + # Palette toggle for dark mode + - media: "(prefers-color-scheme: dark)" + scheme: slate + toggle: + icon: material/lightbulb + name: Switch to light mode + logo: assets/icon-transparent.png + favicon: assets/favicon.png + features: + - navigation.instant + - navigation.indexes + - navigation.tabs + - navigation.tracking + - navigation.expand + - navigation.top + - toc.follow + - toc.integrate + - search.suggest + - search.highlight + - content.code.copy + - content.code.annotate + - content.code.select + +extra: + # sets scope of cookies to use a common path (root) +# scope: "/" + analytics: + provider: google + property: G-WMFVR98J0Q + feedback: + title: Was this page helpful? + ratings: + - icon: material/emoticon-happy-outline + name: This page was helpful + data: 1 + note: >- + Thanks for your feedback! + - icon: material/emoticon-sad-outline + name: This page could be improved + data: 0 + note: >- + Thanks for your feedback! Help us improve this page by + using our GitHub Discussions. + social: + - icon: fontawesome/brands/twitter + link: https://twitter.com/utPLSQL + - icon: fontawesome/regular/comment + link: https://github.com/utPLSQL/utPLSQL/discussions + - icon: fontawesome/brands/github + link: https://github.com/utPLSQL + - icon: fontawesome/solid/envelope + link: mailto:utPLSQL@utPLSQL.org + consent: + title: Cookie consent + description: >- + We use cookies to recognize your repeated visits and preferences, as well + as to measure the effectiveness of our documentation and whether users + find what they're searching for. With your consent, you're helping us to + make our documentation better. + # the cookie: utplsql-consent allows for shred cookie across all documentation versions and the global site + cookie: utplsql-consent + version: # disable for offline docs + provider: mike # disable for offline docs +markdown_extensions: + - admonition + - pymdownx.highlight: + anchor_linenums: true + line_spans: __span + pygments_lang_class: true + - pymdownx.inlinehilite + - pymdownx.snippets + - pymdownx.superfences + - pymdownx.caret + - pymdownx.mark + - pymdownx.tilde + - toc: + permalink: true +use_directory_urls: false +#strict: true + +plugins: + - search + - git-committers: + repository: utPLSQL/utPLSQL.github.io + branch: main + token: !ENV ["API_TOKEN_GITHUB"] + - git-revision-date-localized: # disable for offline docs + enable_creation_date: true # disable for offline docs + type: datetime # disable for offline docs + - include-markdown + - blog: + blog_dir: announcements + post_date_format: long # e.g. "June 10, 2026" + post_url_format: "{slug}" # keeps URLs clean + archive: false + categories: true +nav: + - Home: index.md + - Announcements: + - announcements/index.md + - Documentation: + - documentation.md + - utPLSQL framework: utPLSQL/latest + - utPLSQL-cli: utPLSQL-cli.md + - utPLSQL-maven plugin: utPLSQL-maven-plugin.md + - SQLDeveloper extension: utPLSQL-SQLDeveloper.md + - PL/SQL Developer plugin: utPLSQL-PLSQL-Developer.md + - Downloads: downloads.md + - Resources: resources.md + - About: about.md + - Contributing: contributing.md diff --git a/site-template/README.md b/site-template/README.md new file mode 100644 index 0000000..250a9f2 --- /dev/null +++ b/site-template/README.md @@ -0,0 +1,43 @@ +# utPLSQL Sub-site Template + +Copy the files from this directory into your repository to get the shared +utPLSQL.org top navigation bar automatically. + +## Setup + +**1. Copy the overrides directory into your repo's `docs/` folder:** + +``` +docs/ + overrides/ + main.html ← copied from site-template/overrides/main.html +``` + +**2. Tell MkDocs to use the overrides directory — add `custom_dir` to your `mkdocs.yml`:** + +```yaml +theme: + name: material + custom_dir: docs/overrides + # ... rest of your theme config +``` + +That's it. The topbar is loaded from `https://utplsql.org/assets/topbar.js` at +runtime, so any navigation changes made in the central org repo are picked up +automatically by all sub-sites without any further changes on your end. + +## How it works + +- `docs/overrides/main.html` extends Material's base template and injects + `topbar.js` into the `` of every page. +- `topbar.js` is published by the [utPLSQL.github.io](https://github.com/utPLSQL/utPLSQL.github.io) + repo and contains the full nav link list for utplsql.org. +- The script inserts a sticky bar above the MkDocs Material header and adjusts + the header/sidebar positions automatically. + +## Updating the shared nav + +To add or change links in the topbar, edit +[`docs/assets/topbar.js`](https://github.com/utPLSQL/utPLSQL.github.io/blob/main/docs/assets/topbar.js) +in the **utPLSQL.github.io** repo only. All sub-sites pick up the change on +next page load — no per-repo changes needed. diff --git a/site-template/overrides/main.html b/site-template/overrides/main.html new file mode 100644 index 0000000..fdfe1a3 --- /dev/null +++ b/site-template/overrides/main.html @@ -0,0 +1,12 @@ +{% extends "base.html" %} +{# + Sub-repository template override. + Loads the shared utPLSQL.org top navigation bar from the central org site. + The topbar.js file is the single source of truth — update nav links there only. +#} + +{% block extrahead %} + {{ super() }} + + +{% endblock %}