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.
Most of use-cases for current Oracle databases involve some kind of application server that is managing database connection pool. The pool is keeping database connections open for long time to avoid the overhead of connect/disconnect handshakes. Taking into consideration, that deployment of database changes, is more and more often required to be done seamlessly, with minimum or even zero down time, the changes must be applied in a way that they do not significantly impact the open connections and do not enforce the connection pool recycling. This is related to the fact that we want to minimize the scale of impact of particular deployment on a working, living environment.
Some time back I've read Mike Smithers Blog on SQL and PL/SQL standards. I really like reading his blog. He is a great story-teller. Being Oracle developer for over 15 years should make me comply with all of the mostly demanding standards there are. My nature however always tells me to look at the balance the costs and benefits of my actions. Mike pointed out a good amount of issues, when it comes to introducing coding standards and how important it is to keep it simple. Naming conventions can also become a true bottleneck and make the database structures and code change-resistant.
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.
I have finished my previous post with comparison of basic reporting capabilities build into UTPLSQL and ruby-plsql frameworks for Oracle unit testing.
In my previous post I have described the conceptual differences between UTPLSQL and ruby-plsql frameworks for unit testing of Oracle database code. I have used a message_api package and unit tests for that API using both frameworks as an example. In this post I will focus on getting the tests to run and the feedback that we can we get from the tests using both frameworks.
Unit Testing is around for quite a while. Since it started to become more and more popular, quite a few tools became available for Oracle database to allow unit testing of the database. There are the UI based tools like Quest Code Tester (now Dell Code Tester for Oracle), Oracle SQL Developer unit testing. There is DBFit by Goyko Adzic for regression and functional testing of databases (including but not limited to Oracle), there are probably many more of that kind, that I'm not aware of. There are also pure programming language based frameworks like UTPLSQL and ruby-plsql. There are probably (and hopefully) many more of that sort that I'm not aware of. Unit tests are meant to be created and maintained by software developers and are to help developers keep their code clean and valid throughout entire project life cycle. UI based frameworks for unit testing are putting a high abstraction and tight facade between the code and the developer. Those frameworks tend to limit the richness and variety of possible implementations for a test case and therefore are not suited for software developers. The time and cost of development and maintenance for UI-based unit tests is usually way beyond the benefits. Variety of program units that are possible to develop is infinite and the only limitations to what the unit can do are the programming language boundaries and developers creativity. For this reason itself, it is best to use a programming language of similar or higher flexibility to describe and test the behaviour for a unit. In this series of article I will focus on two programming language-based unit testing frameworks for Oralce, that I got familiar with and had opportunity to use.
Last week I revealed the numbers standing behind the overhead of calling a Pl/SQL function from within an SQL statement. I've left two questions open: - Is it always a performance issue, when you call a PL/SQL function from a SQL statement? - What can be done to maintain the function encapsulation (have the code DRY) and keep high performance?