Reporting test results with utPLSQL
utPLSQL comes with several output reporters for different use cases: human-readable text, JUnit XML, TeamCity, TFS for CI pipelines, SonarQube-compatible coverage reports and more.
testing¶
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(...).
Testing query output with cursor comparison
utPLSQL can compare results of two queries in single line call to ut.expect(). Within your test, define the SQL queries as SYS_REFCURSOR variables.
utPLSQL starter tips - The expectations API
utPLSQL provides expectations syntax through the ut.expect() methods. This post covers the most commonly used expectation matchers and how failure output works.
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.
What is the equivalent of utassert eqtable / eqquery in utPLSQL v3
In utPLSQL v2 you had to use 'quoted text to compare tables / queries. utPLSQL v3 allows you to compare table data using native refcursors without usage of dynamic SQL.
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.
utPLSQL v2 vs. ruby-plsql – Oracle unit testing frameworks for developers comparison
Last two months I was blogging quite a lot about UTPLSQL vs ruby-plsql.
There are lots of aspects that I did not manage to cover so far. I've had a ambitious plan to go through all of the details and dig into the darkest corners to show all the differences. Time is however one thing I'm really short on recently, so instead of going into all the details as planned I've decided to give a high level overview of main differences between UTPLSQL and ruby-plsql.
This will be a summary of the series for now, as I feel like moving into other topics. I might get back to it later if I find good reasons for doing so.