Per caricare o non caricare dati per unit test da file esterni

Quando collaudo le unità mi trovo spesso a discutere della quantità di dati a cui mi rivolgo e mi aspetto dalle mie unità in prova, dovrei includere nei file di prova effettivi.

Il compromesso con cui continuo a lottare è:

• Se gran parte del test (nel volume del codice) è costituito da dati di input e output, mi sembra difficile leggere effettivamente il test, ma riesco a vedere facilmente gli input e output effettivi.
• Se carico i dati di test dai file, posso facilmente testare una serie di variazioni sul possibile input di dati, riutilizzare facilmente i dati di test per più test, ma devo lasciare il codice sorgente per guardare un altro file per vedere quali sono esattamente gli input .

Uno di questi è un anti-pattern?

Per rispondere direttamente alla tua domanda - no, non credo che sia un anti-pattern se usato correttamente.

--- Risposta più dettagliata ---

Dalla mia esperienza, penso che questo dipenda fortemente dall'obiettivo del tuo test. Ecco la regola empirica che ho usato in passato e mi ha aiutato a decidere:

Stai effettivamente testando una piccola unità di codice? (Un vero test unitario)

Se sì, allora ho scoperto che è molto più semplice creare i dati all'interno del test stesso proprio perché posso vedere cosa viene passato. In questi casi, cercherò di solito una libreria simile a Jasmine da usare perché trovo che semplifica la creazione e la gestione dei dati di test. Questa è una preferenza personale, però: usa tutto ciò che semplifica il tuo lavoro.

In caso contrario, probabilmente stai effettivamente testando il sistema stesso. In questi casi, carico spesso dati da una fonte esterna, i motivi qui sono:

1. Questo test non riguarda la chiarezza del codice per i programmatori (anche se è ancora importante - qualcuno deve mantenerlo), si tratta di eseguire abbastanza diversi tipi di dati attraverso l'intero blocco del sistema per essere ragionevolmente sicuro che funzioni.
2. Spesso scrivo il codice idraulico per caricare e utilizzare i dati del test, ma i dati stessi vengono creati da qualcun altro (di solito un membro dello staff QA nel mio caso). Queste persone di solito non sono programmatori, quindi non posso aspettarmi che stiano modificando il codice.

Risposta così lunga, dipende da cosa stai testando e perché. Entrambi gli approcci sono utili e hanno il loro posto: scegli ciò che funziona meglio per la tua situazione.

Non vedo un compromesso qui. Il codice sorgente dovrebbe descrivere algoritmi, o almeno una logica aziendale, non grandi quantità di dati. Se scrivi una trasformata di Fourier, vuoi verificare che un tono sinusale sia correttamente mappato su un singolo picco, un suono misto su più picchi ecc., Ma per questo è completamente sufficiente alimentare un file nominato sinus.wavnella routine e verificare che la struttura di output è quella che ti aspetti.

Certo, tecnicamente non hai la certezza immediata che sinus.wavcontenga davvero un tono sinusale, ma come hai detto, elencare i 100.000 valori di ampiezza nella fonte non ti dà nemmeno questo - in realtà, è peggio , perché tu può almeno riprodurre un file esterno con un lettore audio da controllare, mentre i valori dei dati sepolti nel codice sorgente sono sostanzialmente impossibili da eseguire.