Esistono diversi strumenti di test per PL/SQL. Steven Feuerstein ne ha scritti due, utplsql e Quest Code Tester per Oracle (ex QUTE). Sono un grande fan di utplsql, ma non ha più una comunità di supporto attiva (che è un peccato). Tende anche ad essere piuttosto prolisso, specialmente quando si tratta di impostare dispositivi di prova. Ha il cardinale virtuale di essere pacchetti PL/SQL puri; il codice sorgente è un po' nodoso ma è FOSS.
QCTO viene fornito con una GUI, il che significa che, come altri prodotti Quest, ad esempio TOAD, è solo Windows. Non automatizza esattamente la generazione dei dati di test, ma fornisce un'interfaccia per supportarla. Inoltre, come altri prodotti Quest, QCTO è concesso in licenza anche se è disponibile una copia freeware.
Steven (divulgazione, lui è uno dei miei eroi Oracle) ha scritto un confronto delle funzionalità di tutti gli strumenti di test PL/SQL. Ovviamente, QOTC esce al top, ma penso che il confronto sia onesto. Dai un'occhiata.
Consigli sui dispositivi di prova in utplsql
La gestione dei dati dei test per i test unitari può essere un vero dolore al collo. Sfortunatamente utplsql non offre molto per assumersi l'onere. Quindi
- Verifica sempre con valori noti :
- Evita di usare dbms_random;
- Cerca di limitare l'uso delle sequenze alle colonne i cui valori non contano;
- Anche le date sono complicate. Evita la codifica delle date:usa le variabili che sono popolate con sysdate. Impara ad apprezzare
add_months(),last_day(),interval,trunc(sysdate, 'MM'), ecc.
- Isola i dati del test da altri utenti. Costruiscilo da zero. Utilizzare valori distintivi ove possibile.
- Crea solo i dati di test di cui hai bisogno. Il test volumetrico è una responsabilità diversa.
- Quando si verificano procedure che modificano i dati creano record specifici per ogni unit test.
- Inoltre:non fare affidamento sull'output di successo di un test per fornire l'input di un altro test.
- Quando si verificano procedure che si limitano a confrontare i record di condivisione dei dati tra gli unit test, quando appropriato.
- Condividi i dati del framework (ad es. chiavi primarie referenziate) quando possibile.
- Utilizza campi di testo liberi (nomi, descrizioni, commenti) per identificare quale test o test utilizzano il record.
- Riduci al minimo il lavoro necessario per la creazione di nuovi record:
- Assegna solo i valori necessari alla suite di test e ai vincoli della tabella;
- Utilizza il più possibile i valori predefiniti;
- Procedura il più possibile.
Altre cose da tenere a mente:
- l'impostazione di un dispositivo di prova può richiedere molto tempo. Se hai molti dati, considera la creazione di una procedura per impostare i dati statici che possono essere eseguiti una volta per sessione e includere solo dati volatili in
ut_setupsi. Ciò è particolarmente utile durante il test della funzionalità di sola lettura. - ricorda che la creazione di dati di test è un esercizio di programmazione a sé stante e quindi soggetto a bug.
- usa tutte le funzionalità di utplsql.
utAssert.EqQuery,utAssert.EqQueryValue,utAssert.EqTable,utAssert.EqTabCounteutAssert.Eq_RefC_Querysono tutte caratteristiche molto utili quando si tratta di dedurre i valori di dati volatili. - durante la diagnosi di un'esecuzione di test che non è andata come ci aspettavamo, può essere utile disporre dei dati che sono stati utilizzati. Quindi considera di avere un
ut_teardownvuoto procedura e cancellare i dati del test all'inizio diut_setup.
Gestione del codice legacy
Commentare il post di Gary mi ha ricordato un'altra cosa che potresti trovare utile. Steven F ha scritto ulplsql come implementazione PL/SQL di JUnit, l'avanguardia Java del movimento Test First. Tuttavia, le tecniche di TDD possono essere applicate anche a grandi quantità di codice legacy (in questo contesto, il codice legacy è qualsiasi insieme di programmi senza unit test).
La cosa fondamentale da tenere a mente è che non devi mettere tutto sotto test unitario immediatamente. Inizia in modo incrementale. Crea unit test per nuove cose, Prima verifica . Crea unit test per i bit che intendi modificare prima di applicare la modifica, in modo da sapere che funzionano ancora dopo aver apportato la modifica.
C'è molto da pensare in quest'area, ma (inevitabile anche se vergognosamente) viene principalmente dai programmatori OO. Michael Feathers è il capo principale. Leggi il suo articolo Lavorare efficacemente con il codice legacy . Se lo trovi utile ha successivamente scritto un libro con lo stesso nome.
