Skip to content

testing

Defining code coverage scope with regular expressions in utPLSQL-cli

A coverage report is only useful when the information it provides is meaningful.

Useful information would be: "How much of MY application code is covered by tests?"

Until now, obtaining precise coverage for your project with utplsql-cli was only possible by mapping project files into database objects or by providing a complete list of objects to include or exclude when gathering coverage.

Since version 3.2.2, utplsql-cli lets you describe the scope of the coverage report with regular expressions, so the included/excluded scope follows your naming conventions instead of an object list.

Testing for exceptions with --%throws

Throwing exceptions is a common practice of handling situations when the program meets unsupported combination of data or conditions. Oracle PL/SQL language provides several mechanisms for raising and capturing exceptions.

utPLSQL provides the --%throws annotation that allows for verification of expected exceptions. Exception testing in utPLSQL is done through this annotation, not through ut.expect(...).

utPLSQL starter tips - Annotations configure tests

You configure utPLSQL test suite in special comments — called annotations — right inside the PL/SQL package specification.

Annotations are comment lines starting with --%. They tell the framework what is a suite, what is a test, what procedures need to be called for setup or cleanup logic. The framework reads them at runtime so no extra configuration is needed.

utPLSQL starter tips - creating test suite

Testing PL/SQL code does not need to mean writing throwaway scripts or using a complicated graphical user interface.

utPLSQL gives you a proper test framework — right inside database.

A utPLSQL test is just a package annotated as --%suite with procedures annotated as --%test. The framework finds them automatically.

  • in testing
  • 5 min read

Test Driven Development in PLSQL with utPLSQL v3 - intro

The biggest challenge around unit testing is to make it work for you (as an engineer), not against you.

Many developers struggle, when writing unit tests. This is mainly due to the fact that while we are educated in design and implementation of database software, we are not mentored on unit testing. The struggle leads to dissatisfaction, frustration, poor test quality and lack of confidence in values of unit testing as a practice. Common statements and questions raised in regards to unit testing are:

  • unit tests don't bring any value
  • unit testing is too time consuming / too hard
  • the functionality is too complex to be unit tested
  • why should I write unit tests, my code already works as expected

How I got into utPLSQL v3 development

Winter is coming and the 7th season of Game of Thrones now just a memory. While I do love watching TV series it was not them that dragged me away from my blog.

For last 18 months or so, I was heavily involved in design and development of new version of utPLSQL v3. After a year of development, we've published utPLSQL version 3.0.0 in May 2017 and now we are at version 3.0.3.