Se stai scrivendo unit test , stai creando un programma per verificare che il codice di destinazione, dato un insieme specifico di input, restituisca un output noto e previsto. Per effettuare test unitari per i tuoi rapporti, devi:
- Un database fittizio su cui vengono eseguiti i rapporti di test.
- Dati fittizi sufficienti per generare rapporti.
- Esempi noti dell'output che i report dovrebbero generare quando vengono inviati i dati simulati nel database mock.
A meno che non si stia effettivamente lavorando allo sviluppo del software Oracle stesso, non è necessario testare cose come "date date in realtà" o "ogni colonna ha un'intestazione". Devi solo abbinare il tuo input simulato all'output simulato ed espandere la tua suite di test fino a coprire tutte le applicazioni necessarie per gli usi in produzione.
OTOH, se in realtà stai andando a testare come il report restituisce gli elementi basati sul tuo database live, stai scrivendo integration test ed eventualmente anche controlli di produzione . (I test verranno eseguiti ogni volta che viene eseguito il report o solo quando una nuova versione di codice viene trasferita in produzione?)
In tutti i casi, testerei solo ciò che è importante per l'utente finale ("è la colonna di vendita in realtà vendite?") o altrimenti parte delle specifiche di progettazione ("UserCancellation Report include solo gli utenti contrassegnati per l'annullamento . ").
Sapere con esattezza quanti test scrivere e cosa scrivere richiede molta conoscenza del dominio, non ultimo il numero di volte in cui questi test sono eseguiti e come è il tuo framework di test. ( stai usando una suite di test automatizzata di qualche tipo, OSS o acquistata da un fornitore o addirittura cresciuta in casa, vero?)
