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.

Currently I use UTPLSQL as it’s “the tool of a choice” for unit testing my Oracle code. Before that I used ruby-plsql.
Interestingly, while unit testing with ruby-plsql I saw quite few people getting “test infected”, using UTPLSQL I see many developers preferring test-avoidance technique instead. I’m not sure if it’s a matter of skills, education or the tool of choice.

Through last years I’ve came to realize that writing good tests is really hard.
It’s actually quite impossible to write good unit tests without one of those things happening:

  • receiving solid portions of good mentoring
  • lots of reading on unit testing and TDD
  • lots of painful failures and refactorings of your tests

It took all of the above for me, before I’ve learned how to write tests in a way that they are

  • usable
  • useful
  • maintainable

It was a long journey with many hard lessons, but it was and still is a journey to better. Today I can’t imagine having a complex database with multiple packages and dependencies without unit-test coverage. It just doesn’t feel safe any more. It actually never felt safe, but I just didn’t realise how safe I can be doing changes in database.

So I’ve learned that writing good and maintainable tests is not simple. What I’ve also learned recently is that it’s not just your skills but also the tools you choose, that impact quality of your tests and your productivity.
Yes, I do manage to get decent tests with UTPLSQL, but it is really hard effort and I’m still unable to get rid of the feeling that the code just smells bad and there’s actually not much I can do about it.
Despite the facts that I used Ruby for nothing except unit testing of Oracle code, I cant resist the feeling that the power of the language is just amazing.

There were moments where using ruby-plsql for unit testing made my face as if I would be having a test-drive of Tesla P85D in Insane Mode.

Ruby as a language surprised me with it’s syntax and flexibility that I often made me happy as a sandboy.

It was a big challenge to categorize and articulate the exact reasons why I prefer ruby-plsql over UTPLSQL.
It was even a bigger challenge to put it into a comparison that would be dense and more focused on facts than gut-feeling and “it just feels nicer”.


7 comments on “UTPLSQL vs. ruby-plsql – Oracle unit testing frameworks for developers comparison

  • Hi Jacek.

    Thanks for all the work you put into that website and for the promotion of ruby-plsql.
    I’m coding PL/SQL for 10 years now and automatic unit testing remains a really interesting topic for me even if I’ve never been on any project using it.

    The question of chosing one tool for unit-testing has always been something who prevented me to do unit testing.
    Some years ago, I’ve come to develop an Excel spreadsheet with VBA where you configure your input datas, program calls, expected results. VBA do the call for you and you have a visual way of checking that your tests performed well. That was pretty cool but not an industry standard by the way (and I’ve only been using it on just 1 complex package).
    So now I’m looking for a more standard way to test PL/SQL that can be as “fun” as possible.

    By the way, it’s amazing to see Steven Feuerstein also admitting that he don’t like using the tools he helped to develop as they are a bit boring to use.

    I feel like Ruby-plsql can solve this problem. I will give it a try and hope to be convinced 🙂
    Learning a new language can be frightening so maybe it’s preventing the rise of ruby-plsql unit testing but I feel like it’s worth the effort.

    Please keep up the good work to spread the good word about unit testing with ruby.

    • Thanks for sharing Monika.
      I will have a look. I’m on my may for creating a post on Unit Testing/TDD and why should we care.
      I’ve already spent quite a few evenings researching, gathering materials and thoughts 😉

  • Jacek,

    interesting stuff.
    Like you, I’ve used utPLSQL in the past.
    Whilst it’s a marked improvement on what went before ( i.e. there wasn’t really any ut framework for PL/SQL), it does often feel like there’s a lot of effort required to create and maintain tests.

    After reading your posts on ruby-plsql I’m definitely going to give it a try (now added to my ever-lengthening “To do” list ) 🙂


    • Hi Mike,
      It’s nice to hear you getting interested in this 🙂
      I bet your “to do” list is quite big, just like mine is.
      Sometimes it’s hard to choose between what is important and what is interesting, specially when they do not align.
      I think that TDD is of great importance, though it’s still a land to be discovered in the database world.
      The more I read and listen about agile practices and software craftsmanship, the more I’m dedicated and convinced that it’s both interesting and important.

      There is an effort needed to create and maintain tests.
      The worse the design the bigger the cost.
      This pays-off greatly however, if you run your tests continuously to maintain a full regression safety harness.
      – you’re free to do redesign and performance improvements fearlessly.
      – your code is production-ready when you finish coding it.
      just to name a few.
      TDD itself, when done right, is promoting the clean and minimal solutions, as you code only what is needed for the test to pass. No over-design, no over-coding.
      I believe my next posts will be on the subject of TDD practices with databases.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.