Come scrivere test unitari per programmi di utilità

2

Sto lavorando su un'applicazione console C # che carica i dati da una terza parte e inserimenti di massa in tabelle. Fondamentalmente il codice consiste in un metodo statico con istruzioni di registrazione. In questi scenari, come si scrivono i casi di test unitario?

Codice di esempio

void Main(string[] args)
{
    // for loop here to read config from XML file

    // initialize third party library
    ReportLib objLib = new ReportLib();


    DataTable dt = objLib.Refresh("test");

    //call SQL bulk copy
    DBHelper.BulkCopy(dt, dictmappings, destTblName);//dbhelper is static class

}
    
posta Sunny 11.07.2013 - 02:55
fonte

6 risposte

7

In realtà, dato il tuo caso è davvero così piccolo e semplice come sembra nel tuo codice di esempio, probabilmente ometterei qualsiasi unit test e scrivere invece un test di integrazione o di sistema automatizzato.

Ecco il mio profilo di tale test:

  • fornire un file di configurazione XML fisso come parte della suite di test
  • cancella la tabella di destinazione nel tuo database di test
  • esegui il tuo programma (sia come processo separato, o spostando il contenuto della tua funzione Main in una funzione separata in una DLL separata, puoi facilmente fare riferimento e chiamare dalla tua DLL di prova)
  • controlla se la tabella di destinazione ha ora i contenuti previsti

Puoi anche usare uno strumento come NUnit per un tale tipo di test, come per i test di unità "reali" (ecco perché le persone a volte chiamano questo tipo di test in modo errato anche per le unit test).

    
risposta data 11.07.2013 - 08:11
fonte
2

usa una fonte di dati simulata, un'interfaccia dati falsa e un registro fittizio. Se il tuo codice legge solo dati e chiama i metodi di qualcun altro, questo è il test dell'unità.

Sentiti libero di utilizzare il tuo framework di test unitario per testare l'intero processo, se possibile, ma potrebbe essere più di un test di integrazione.

    
risposta data 11.07.2013 - 03:36
fonte
1

Sposta tutto il codice che fa effettivamente il lavoro in una libreria autonoma. Spezzarlo in piccoli pezzi e scrivere un test per ogni pezzo. Se riesci a vedere un blocco di codice e dire "questo codice fa (inserisci azione) e ..." allora devono essere due o più metodi o classi separati. Scrivi il tuo livello di accesso ai dati in modo che tu possa scrivere classi di simulazione per trasmettere dati falsi alla tua logica durante il test.

Se strutturi la tua applicazione in livelli logici, puoi facilmente falsificare le parti che non ti interessano durante il test di un singolo pezzo di codice.

    
risposta data 11.07.2013 - 03:25
fonte
1

Inoltre, ricorda che un test unitario è un test unitario. Non un test di integrazione. Non cadere in un pozzo familiare e prova a testare l'intero funzionamento del tuo strumento da riga di comando.

Prova i frammenti della tua utilità. Se ciò sembra impossibile perché hai solo una piccola classe, decidi di saltare l'unittesting perché l'utilità è banale o dividi il tuo programma in modulest separati che sono testabili.

    
risposta data 11.07.2013 - 15:12
fonte
1

La maggior parte delle volte, le mie utilità sono semplici script a 20 righe che uso quotidianamente / settimanalmente / mensilmente, e faccio una cosa. Se esegui l'utility, sarà immediatamente evidente che lo script non funziona.

Non hai bisogno di test unitari per tali utility.

    
risposta data 11.07.2013 - 15:20
fonte
1

Aggiungi un paio di righe alla fine dello script che verificano i dati inseriti nelle tabelle. In caso contrario, lanciare un'eccezione o registrare l'errore. KISS è sicuramente la strada da percorrere per questo genere di cose. Se questo script diventa parte di un sistema più grande, puoi sempre rifattorizzare questo semplice codice di cattura in un test di integrazione.

    
risposta data 11.07.2013 - 15:46
fonte

Leggi altre domande sui tag