Today is my birthday and to celebrate it I want to give something to the utPLSQL (and wider PL/SQL development) community:
A new and updated utPLSQL CheatSheet
You can download it directly from here or go to the official Cheatography-page
This goes with a huge “THANK YOU” to the amazing people in the Oracle community. Since I started contributing to utPLSQL, I met a lot of wonderful people, learned a ton and got an amazing lot of help. The utPLSQL project and the people around it had a major impact on my career and personal development during the last 3 years.
A special thanks goes to Jacek Gebal: There would not be a utPLSQL v3 without him and the current framework wouldn’t be in the mature and stable shape it is today.
Thank you Jacek for your fantastic work, for your commitment and the endless stream of effort you donate!
After I published my last post, some folks rightly pointed out that the way I implemented the
add_popular_sith procedure was not well-testable and that I should rather change my code than trying to control the underlying sequence.
And I totally agree. For several reasons:
- Controlling the sequence adds a lot of complexity to my testing code
- It invalidates depending packages (and yes, there are ways around that problem)
- It also forces me to touch internals. That means when I change the sequence (even if it’s the sequence name) my test will fail even though the procedure still works. Same happens if I replace the sequence with an identity column.
The whole test-setup around controlling the sequence is a “smell” that shows me one thing: I have functionality that is hard to test (and therefore probably also hard to change and maintain).
A nasty problem has been haunting me for a while now in my codebase: Every time I run my full utPLSQL test suite, one specific test-package fails every test with
ORA-04061 - Existing state of Package has been invalidated. But when I run this specific test package, everything works fine.
Today I followed the rabbit hole and to get a better understanding of what’s going on I tried to extract what I learned into a simple example in my favourite universe.
This article has been published in German in the Red Stack Magazine and in English in the PTK Magazine.
The lament in the headline might be very familiar to most developers and even more painfully to quite a few users. “What happened between yesterday and today to cause my application to break? And why did it have to be reported by my user?”
After some contemplation, we remember a small change we made yesterday, shortly before leaving for home. The customer asked for a new column in the View
v_starwars_ characters which we added on the fly. Nothing special, but very urgent, and it seemed so simple: just a new field with information about the movies in which the Star Wars characters appear:
There’s a great talk by Kevlin Henney about Structure and Interpretation of Test Cases that inspired me to rethink my approach of writing tests.
With the features added in the latest version 3.1.9 of utPLSQL, this approach is even easier to pull off as I want to showcase:
We start with the friend or foe detection system of the deathstar, which decides based upon the weapon and clothing of indiviudals whether they are friend or foe to the empire (you know: red lightsabers mean sith, which are friends, blue or green lightsabers mean jedi, which are foes etc.)
The full example is available on my github repo as always, I’ll skip some parts here.
This year’s DOAG conference and exhibition really embraces the topic of automated Self-Testing from a developer’s perspective – and I am so glad about that! Too long practices like TDD have been a niche topic in the database world, but times are changing.
To help people interested in automated self-testing practices, I compiled a list of all talks centered around that topic in order of their appearance (talks by utPLSQL maintainers get a little highlight, though. Yes, I’m biased and it’s my list).
The list is highly subjective, there are several presenters I don’t know and while I read through a very large amount of abstracts it is absolutely possible I missed something.
If so, don’t hesitate to reach out to me so I can add the talk to the list or correct the very short description.
(Make sure to revisit this post once in a while for it is a “living” document)
Most developers have – at some point – to deal with code they don’t know. Sometimes they don’t even have a clue what something is doing, but are expected to understand and probably change that something quickly. The situation gets worse if the functionality contains some side-effects or non obvious functionality, triggers for example in the database sphere.
I often encourage people to use unit tests to explore an unknown scenario or functionality, and utPLSQL provides a great tool to do that (since version 3.1.6): The
I recently played around a bit with the various utPLSQL annotations and found them pretty powerful.
I’m pretty sure I will write some more about how you can use annotations like
--%context to make your tests more expressive, but today I just want to showcase some techniques and tell the story of the original Star Wars movies.
For the interesting part is completely in the package specification I will skip the body in the highlighted code here. Each procedure implementation only contains a call to
dbms_output.put_line with some text.
You can get the whole example as always from my github.
One of the really great features of utPLSQL are contexts. They allow to further organize tests inside a test suite (which can also be organized hierarchically by suitepaths).
Contexts can help with several things:
- They can reduce the setup/teardown time (things can be done once per context instead of before every test)
- They can help to reveal the intention by grouping several tests
- They can be used to avoid duplication
For this example we build upon the active deathstar protocol which in our case controls how the security system reacts to an unknown, hooded person (you all know that hooded strangers on a deathstar are always undercover jedi).
We already looked at utPLSQL’s cursor comparison with user-defined types. If we have to deal with updatable views, we can use an even simpler approach and create nested table collections from %ROWTYPEs.
The scenario is similar to the previous one: we have a number of planets with or without garrisons. Now we want to be able to update the view with a garrison-ID which then automatically creates a new garrison-entry.