Skip to content

Blog

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.

Beware of raise_application_error from within exception when others

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.

PL/SQL and SQL naming conventions

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.

utPLSQL v2 vs. ruby-plsql – Oracle unit testing frameworks for developers comparison

UTPLSQL_vs_RSpec 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.

ruby-plsql cheatsheet

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.