Istnieje kilka różnych narzędzi testowych dla PL/SQL. Steven Feuerstein napisał dwa z nich, utplsql i Tester kodu Quest dla Oracle (dawniej QUTE). Jestem wielkim fanem utplsql, ale nie ma już aktywnej społeczności wsparcia (a szkoda). Jest również dość gadatliwy, zwłaszcza jeśli chodzi o konfigurowanie urządzeń testowych. Ma kardynalną wirtualizację bycia czystymi pakietami PL/SQL; kod źródłowy jest trochę szorstki, ale to FOSS.
QCTO jest dostarczane z graficznym interfejsem użytkownika, co oznacza - podobnie jak inne produkty Quest, np. TOAD - tylko dla systemu Windows. Nie dokładnie automatyzuje generowanie danych testowych, ale zapewnia interfejs do jego obsługi. Podobnie jak inne produkty Quest, QCTO jest licencjonowane, chociaż istnieje bezpłatna kopia.
Steven (ujawnienie, on jest jednym z moich bohaterów Oracle) napisał porównanie funkcji wszystkich narzędzi testujących PL/SQL. Oczywiście najlepsze jest QOTC, ale myślę, że porównanie jest uczciwe. Sprawdź.
Porada dotycząca urządzeń testowych w utplsql
Zarządzanie danymi testowymi do testów jednostkowych może być prawdziwym bólem szyi. Niestety utplsql nie oferuje zbyt wiele do udźwignięcia ciężaru. Więc
- Zawsze testuj ze znanymi wartościami :
- Unikaj używania dbms_random;
- Spróbuj ograniczyć użycie sekwencji do kolumn, których wartości nie mają znaczenia;
- Daty też są trudne. Unikaj stałego kodowania dat:używaj zmiennych, które są wypełniane przez sysdate. Naucz się doceniać
add_months(),last_day(),interval,trunc(sysdate, 'MM')itp.
- Odizoluj dane testowe od innych użytkowników. Zbuduj go od podstaw. W miarę możliwości używaj charakterystycznych wartości.
- Twórz tylko tyle danych testowych, ile potrzebujesz. Testy wolumetryczne to inna odpowiedzialność.
- Podczas testowania procedury, które zmieniają dane, tworzą określone rekordy dla każdego testu jednostkowego.
- Również:nie polegaj na pomyślnym wyniku jednego testu, aby dostarczyć dane wejściowe z innego testu.
- Podczas testowania procedur, które po prostu raportują dane, udostępniają rekordy między testami jednostkowymi, gdy jest to właściwe.
- Udostępniaj dane frameworka (np. przywoływane klucze podstawowe), gdy tylko jest to możliwe.
- Użyj wolnych pól tekstowych (nazw, opisów, komentarzy), aby określić, który test lub testy wykorzystują rekord.
- Zminimalizuj pracę związaną z tworzeniem nowych rekordów:
- Przypisuj tylko wartości, które są niezbędne do zestawu testów i ograniczeń tabeli;
- W miarę możliwości używaj wartości domyślnych;
- Proceduruj jak najwięcej.
Inne rzeczy, o których należy pamiętać:
- Konfigurowanie urządzenia testowego może być czasochłonnym ćwiczeniem. Jeśli masz dużo danych, rozważ zbudowanie procedury konfiguracji danych statycznych, które mogą być uruchamiane raz na sesję i zawierają tylko dane nietrwałe w
ut_setupsamo. Jest to szczególnie przydatne podczas testowania funkcji tylko do odczytu. - Pamiętaj, że tworzenie danych testowych jest samodzielnym ćwiczeniem programistycznym i dlatego jest podatne na błędy.
- wykorzystywanie wszystkich funkcji utplsql.
utAssert.EqQuery,utAssert.EqQueryValue,utAssert.EqTable,utAssert.EqTabCountiutAssert.Eq_RefC_Queryto bardzo przydatne funkcje, jeśli chodzi o wnioskowanie wartości danych lotnych. - podczas diagnozowania przebiegu testowego, który nie przebiegł zgodnie z naszymi oczekiwaniami, przydatne mogą być dane, które zostały użyte. Rozważ więc posiadanie pustego
ut_teardownprocedura i usuwanie danych testowych na początkuut_setup.
Postępowanie ze starszym kodem
Komentowanie wpisu Gary'ego przypomniało mi jeszcze jedną rzecz, która może okazać się przydatna. Steven F napisał ulplsql jako implementację PL/SQL JUnit, awangardy Java ruchu Test First. Jednak techniki TDD można również zastosować do dużych ilości starszego kodu (w tym kontekście starszy kod to dowolny zestaw programów bez żadnych testów jednostkowych).
Kluczową rzeczą, o której należy pamiętać, jest to, że nie musisz od razu poddawać wszystkiego testom jednostkowym. Zacznij stopniowo. Twórz testy jednostkowe dla nowych rzeczy, Najpierw test . Kompiluj testy jednostkowe dla bitów, które zamierzasz zmienić, przed zastosowaniem zmiany, aby wiedzieć, że nadal działają po wprowadzeniu zmiany.
W tej dziedzinie jest dużo myśli, ale (nieuchronnie, jeśli wstyd) pochodzi ona głównie od programistów OO. Głównym bohaterem jest Michael Feathers. Przeczytaj jego artykuł Skuteczna praca ze starszym kodem . Jeśli uznasz to za pomocne, napisał później książkę o tym samym tytule.
