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.
Oracle database does not support ability to obtain number of rows inserted/updated/deleted by a merge operation.
The only value you can obtain is the total number of rows affected by merge operation.
Foreword
Over a month ago I've made a big decision and a shift in my life. I've decided to move to Ireland and start a new career there. Since I moved, I have significant amount of free time, as I no longer waste 3 hours each day on commuting. Also, since my wife still leaves in Poland (for now), I'm all on my own when I finish my work.
Well, maybe that's not 100% true, since now we have Internet with Skype/Hangouts/appear.in and others.
Anyway. I'm not feeling lonely, but rather take advantage of the time that is given to me, to catch up on things I've neglected for some time.
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?
In my previous post I've shown and measured the performance loss on passing the parameters to and from procedure/function call inside PL/SQL code. In this article I'm about to reveal another bottleneck that is often forgotten and not so easy to overcome.
When writing a PL/SQL code, I usually use following strategy:
There are however some situations, when I tend to break the rule, and this is due to performance.
Today I came up with idea to overcome the issue: SQLPlus ERRORLOGGING does not keep error log on rollback. The resolution is to use autonomous transactions to log the errors reported by SQL Plus. What we need to do is to somehow catch the error that is about to be logged and wrap it in an autonomous transaction.
Before I started working at Pragmatists I never actually took time or effort to research the web for automating the testing process in Oracle databases. My previous job was more about delivering solutions, advisory, analysis, design and implementation using the traditional cascade product delivery approach. I don't want to get into too many details on how it happened, that me, being a Oracle database developer, landed in Pragmatist, which is an Agile Software Development company specializing in Java, but all I need to say, is that nothing else but good came out of it for me.
While working heavily on script automation I came across the issue of having an SQLPlus script with optional parameter. Oracle does not allow that by default, and one needs to use a dirty trick to make it work. Vladimir made a great article on how to achieve that. Thank you Vlad, this is really helpful. Vladimir's Diary: On SQL*Plus Defines.