sql >> Databáze >  >> RDS >> Oracle

Jak (unit-)testovat datově náročnou PL/SQL aplikaci

Existuje několik různých testovacích nástrojů pro PL/SQL. Steven Feuerstein napsal dva z nich, utplsql a Quest Code Tester pro Oracle (dříve QUTE). Jsem velkým fanouškem utplsql, ale už nemá aktivní komunitu podpory (což je škoda). Bývá také poměrně podrobný, zejména pokud jde o nastavení testovacích zařízení. Má kardinální virtuál, že jde o čisté PL/SQL balíčky; zdrojový kód je trochu drsný, ale je to FOSS.

QCTO přichází s GUI, což znamená - stejně jako ostatní produkty Quest, tj. TOAD - pouze Windows. Neautomatizuje přesně generování testovacích dat, ale poskytuje rozhraní, které je podporuje. Stejně jako ostatní produkty Quest je QCTO licencováno, ačkoli existuje jeho freewarová kopie.

Steven (odhalení, je to jeden z mých hrdinů Oracle) napsal srovnání funkcí všech testovacích nástrojů PL/SQL. Je zřejmé, že QOTC vychází nejlépe, ale myslím, že srovnání je upřímné. Podívejte se.

Rady ohledně testovacích přípravků v utplsql

Správa testovacích dat pro testování jednotek může být skutečnou bolestí v krku. Bohužel utplsql nenabízí mnoho, aby břemeno nesl. Takže

  • Vždy testujte podle známých hodnot :
    • Vyhněte se použití dbms_random;
    • Zkuste omezit použití sekvencí na sloupce, na jejichž hodnotách nezáleží;
    • Data jsou také složitá. Vyhněte se pevnému kódování dat:použijte proměnné, které jsou vyplněny sysdate. Naučte se ocenit add_months() , last_day() , interval , trunc(sysdate, 'MM') atd.
  • Izolujte testovací data od ostatních uživatelů. Postavte si to od začátku. Kdykoli je to možné, používejte odlišné hodnoty.
  • Vytvářejte pouze tolik testovacích dat, kolik potřebujete. Objemové testování je jiná odpovědnost.
  • Při testování procedur, které mění data, vytvářejí specifické záznamy pro každý test jednotky.
  • Také:nespoléhejte na úspěšný výstup z jednoho testu, který poskytne vstup z jiného testu.
  • Při testování postupů, které jednoduše reportují s daty, sdílejí záznamy mezi jednotkovými testy, je-li to vhodné.
  • Sdílejte rámcová data (např. odkazované primární klíče), kdykoli je to možné.
  • Použijte volná textová pole (jména, popisy, komentáře) k určení, který test nebo testy používají záznam.
  • Minimalizujte práci spojenou s vytvářením nových záznamů:
    • Přiřazujte pouze hodnoty, které jsou nezbytné pro testovací sadu a omezení tabulky;
    • Používejte výchozí hodnoty co nejvíce;
    • Co nejvíce postupujte.

Další věci, které je třeba mít na paměti:

  • Nastavení testovacího zařízení může být časově náročné. Pokud máte hodně dat, zvažte vytvoření procedury pro nastavení statických dat, která lze spustit jednou za relaci, a zahrňte do ut_setup pouze nestálá data sám. To je užitečné zejména při testování funkčnosti pouze pro čtení.
  • Pamatujte, že vytváření testovacích dat je samo o sobě programátorské cvičení, a proto je náchylné k chybám.
  • použijte všechny funkce utplsql. utAssert.EqQuery , utAssert.EqQueryValue , utAssert.EqTable , utAssert.EqTabCount a utAssert.Eq_RefC_Query jsou všechny velmi užitečné funkce, pokud jde o odvození hodnot nestálých dat.
  • při diagnostice testovacího běhu, který neproběhl tak, jak jsme očekávali, může být užitečné mít data, která byla použita. Zvažte tedy dutý ut_teardown proceduru a vymazání testovacích dat na začátku ut_setup .

Zacházení se starším kódem

Komentování Garyho příspěvku mi připomnělo ještě jednu věc, která se vám může hodit. Steven F napsal ulplsql jako implementaci PL/SQL JUnit, Java předvoje hnutí Test First. Techniky TDD však lze aplikovat také na velké množství staršího kódu (v tomto kontextu je starším kódem jakákoliv sada programů bez testů jednotek).

Klíčová věc, kterou je třeba mít na paměti, je, že nemusíte vše okamžitě otestovat. Začněte postupně. Vytvářejte testy jednotek pro nové věci, Nejdříve otestujte . Před použitím změny vytvořte testy jednotek pro bity, které se chystáte změnit, abyste věděli, že po provedení změny stále fungují.

V této oblasti se hodně přemýšlí, ale (nevyhnutelně, i když hanebně) pochází hlavně od OO programátorů. Michael Feathers je hlavní chlap. Přečtěte si jeho článek Efektivní práce se starším kódem . Pokud to považujete za užitečné, následně napsal knihu stejného jména.



  1. Oracle optimalizuje OR + IN na OR + EXISTS, což je velmi pomalé

  2. MySQL odstraní duplicitní záznamy, ale ponechá nejnovější

  3. Problém s výkonem při aktualizaci tabulky z jiné tabulky

  4. Jak se dotazovat na hodnoty, které mají nejvyšší počet hlasů a žádné příznaky v PostgreSQL?