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.
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 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.
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:
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.
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.
I recently use utPLSQL in my daily work as a testing framework and I've noticed that the framework is doing quite bad job on exception handling on the tested code. I'll try to demonstrate it with a simple/yet realistic scenario.
I've finished my previous post a bit too soon and was not precise on the ruby-plsql unite test results analysis.
I've decided to dig a bit deeper to validate that ruby-plsql (RSpec) actually support datatype mismatch exceptions where utPLSQL unit testing fails due to oracle implicit datatype conversion.
This post is a continuation of the utPLSQL vs. ruby-plsql series, you might want to have a look at my previous post for introduction and some basics.
In my previous posts I did some writngs on UTPLSQL and ruby-plsql. For long time, while developing Oracle code I was using ruby-plsql to do test driven development for SQL and PL/SQL. I used to frequently forget how to use some of the functionalities of ruby-plsql, specially after having a longer break and so each time I was referring the Unit Tests supplied for the ruby-plsql library as a reference. They are really nicely documenting how things work and how can they be used. It usually took me few minutes to find the thing I needed.