Coffee, PL/SQL and utPLSQL – Meet Sabine Heimsath

Already tonight at 20:00 CEST we’ll meet during a webinar hosted by Sabine Heimsath: utPLSQL – The Perfect Testing Tool for Lazy People.

Before we dive into testing and PL/SQL, let’s get to know Sabine a little better 😊

Sabine is a freelance Oracle APEX and PL/SQL developer from Germany with many years of experience working with Oracle databases across different industries. She’s also a familiar face at conferences like DOAG, POUG and UKOUG, where she shares her knowledge and passion for the Oracle community.

I invite you to a short conversation with Sabine before the webinar starts!

*****

To start with a bit of background — when did you start using utPLSQL for testing? What did it look like before that approach became your standard? Do you remember the days when testing meant just running a procedure and thinking “yeah, it looks fine”? 😄

 I can’t remember exactly, but the most likely story is that I heard about it on Twitter. I knew the old version by Steven Feuerstein, but wasn’t using it. The new version by Jacek Gebal, being more like JUnit, fitted well with our project at the time. I definitely remember “the old days” – a wild collection of scripts and a lot of ad hoc testing 😊

 Is utPLSQL your default choice in every project, or are there situations where you skip it? Would you say it’s a must-have you don’t start a project without, or more of a tool you pick depending on the context?

I would use it in every project unless the customer insists on a different approach. But utPLSQL fits well with CI/CD, so I don’t see many potential obstacle.

How do you usually approach writing tests? Do you go with test-first (TDD), or do you write the code first and add tests later? In other words, more “test first” or classic “make it work first, then protect it”? 😄

It’s a mixture. In my last project we increasingly moved towards defining various tests already at the specification stage, which also brought more clarity to this phase of the process. During development more tests were added.

In your biggest project in terms of unit tests — roughly how many tests did you have? And what did it feel like in practice: were test runs taking seconds, minutes, or was it more like time for a coffee break? 😄

The number of tests was not the determining factor. Our business logic was relatively complicated and “procedural”, so that accounted for the largest part of the test runtime. So yes – coffee break time, but no blame on utPLSQL.

And finally — what’s your biggest “fuck up” related to tests or bugs? Something that tests were supposed to catch but didn’t… or the opposite — where tests saved you at the last possible moment? 😄

Our tests definitely saved us many times! Of course, you sigh and curse when tests fail, but in the end, there was always a good explanation. And we all know: “fail fast” is better than “fail in production”.

Thank you, Sabine :)

***

Join us for our webinar!

🎙️ Speaker: Sabine Heimsath, passionate about automation and code quality.

🗓️ Data: 27.05.2026, 20:00 CEST

✅ Temat: utPLSQL – The Perfect Testing Tool for Lazy People

💰 Koszt: 0 PLN / FREE

🔗 Szczegóły: https://how2ora.pl/en/pwow

✍️ Zapisy: https://pwowwebinar3.konfeo.com/en/groups

 

📅 Kalendarz PWOW: https://how2ora.pl/en/pwow

📅 Kalendarz POUG: https://poug.org/kalendarz-wydarzen/