Już dziś o 20:00 CEST spotkamy się podczas webinaru prowadzonego przez Sabine Heimsath: „utPLSQL – The Perfect Testing Tool for Lazy People”.
Zanim zanurzymy się w świat testów i PL/SQL, poznajmy Sabine nieco lepiej 😊
Sabine jest niezależną programistką Oracle APEX i PL/SQL z Niemiec. Od wielu lat pracuje z bazami danych Oracle w różnych branżach. Jest także uczestniczką konferencji takich jak DOAG, POUG czy UKOUG, gdzie dzieli się swoją wiedzą i pasją do społeczności Oracle.
Zapraszam na krótką rozmowę z Sabine przed webinarem!
Na początek trochę historii — kiedy zaczęłaś używać utPLSQL do testowania? Jak wyglądało to wcześniej, zanim takie podejście stało się Twoim standardem? Pamiętasz jeszcze czasy, gdy testowanie polegało na uruchomieniu procedury i stwierdzeniu „tak, wygląda dobrze”? 😄
Nie pamiętam dokładnie, ale najprawdopodobniej usłyszałam o utPLSQL na Twitterze. Znałam starą wersję stworzoną przez Stevena Feuersteina, ale z niej nie korzystałam. Nowa wersja autorstwa Jacka Gębala, bardziej przypominająca JUnit, świetnie pasowała do projektu, nad którym wtedy pracowaliśmy. Zdecydowanie pamiętam jednak „stare czasy” — dziką kolekcję skryptów i mnóstwo doraźnych testów 😊
Czy utPLSQL jest Twoim domyślnym wyborem w każdym projekcie, czy zdarzają się sytuacje, w których z niego rezygnujesz? To narzędzie, bez którego nie zaczynasz projektu, czy raczej coś, co wybierasz zależnie od kontekstu?
Używałabym go w każdym projekcie, chyba że klient nalegałby na inne podejście. utPLSQL bardzo dobrze współpracuje z procesami CI/CD, więc nie widzę przeszkód w jego stosowaniu.
Jak zwykle podchodzisz do pisania testów? Stosujesz podejście test-first (TDD), czy najpierw piszesz kod, a testy dodajesz później? Innymi słowy: bardziej „najpierw test”, czy klasyczne „najpierw niech działa, potem przetestujemy”? 😄
To mieszanka obu podejść. W moim ostatnim projekcie coraz częściej definiowaliśmy różne testy już na etapie specyfikacji wymagań, co dodatkowo wnosiło większą przejrzystość do tej fazy procesu. W trakcie rozwoju projektu dochodziły kolejne testy.
W największym projekcie pod względem liczby testów — mniej więcej ile ich było? I jak to wyglądało w praktyce: uruchomienie testów zajmowało sekundy, minuty, czy raczej był to czas na kawę? 😄
Liczba testów nie była tutaj najważniejszym czynnikiem. Nasza logika biznesowa była dość złożona i mocno proceduralna, więc to ona odpowiadała za największą część czasu wykonywania testów. Tak więc tak — był czas na kawę, ale nie z winy utPLSQL.
I na koniec — jaka była Twoja największa testowa lub programistyczna „wpadka”? Coś, czego testy powinny były wykryć, ale nie wykryły… albo odwrotnie — sytuacja, w której uratowały Cię w ostatniej chwili? 😄
Nasze testy wielokrotnie nas uratowały! Oczywiście, kiedy testy się wywalają, człowiek wzdycha i trochę przeklina, ale ostatecznie zawsze znajdowało się dobre wyjaśnienie. A wszyscy znamy zasadę: „fail fast” jest lepsze niż „fail in production”.
Dziękuję, Sabine! :)
🎙️ 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/
Komentarze
Prześlij komentarz