È considerata una cattiva pratica utilizzare un file flat quando si eseguono i test unitari? Se un'applicazione legge file flat e li analizza, sarebbe un approccio migliore rispetto alle stringhe di hard coding nei test di unità stessi?
È solo una cattiva pratica assicurarsi che i file di testo non siano controllati nel controllo di versione.
Non c'è nulla di estremamente sbagliato nella lettura dei file di testo, a condizione che i file di testo siano nel controllo del codice sorgente accanto alla classe che lo legge.
Tuttavia, personalmente preferirei codificare tutti i valori in un gruppo di elenchi perché vengono utilizzati per i test delle unità. Non c'è niente di sbagliato in questo. Dove lavoro lavoro su software che analizza dati da sensori del mondo reale. Ho scritto script Python che prenderanno i file di testo flat e li convertiranno in file di classe statici C # pronti per essere inseriti nei test di unità.
Il file flat contiene informazioni che possono essere rese in una forma leggibile dall'uomo? In tal caso, memorizza le informazioni nel formato più leggibile dall'uomo.
es. File di script, rappresentazione dei dati basata su testo, ecc. Questi possono essere inseriti insieme al codice di test dell'unità e controllati nel controllo di versione.
es. File immagine, file audio. Il modo naturale per render un file immagine è di lasciarlo come un file immagine, in modo che possa essere aperto da qualsiasi visualizzatore di immagini. Non tentare di archiviare i file di immagine di prova in un formato che li rende non riproducibili (ad esempio salvarli come Base64 in un file XML, a meno che non si stia testando una libreria che esegue quella conversione e si disponga di un visualizzatore di immagini in grado di eseguire il rendering immagine per te)
es. dati binari sintetici. In questo caso, è meglio scrivere una funzione di test helper che generi al volo i dati binari sintetici. La funzione di test helper è la "forma leggibile dall'uomo" che spiega come vengono generati i dati; nessuno può capirlo guardando solo i dati.
Personalmente penso che dipenda da ciò che stai testando. Tendo a cercare di abbattere i miei test unitari il più piccolo possibile e di testare solo un pezzo di funzionalità.
Mi sembra che tu stia provando a testare due cose qui: 1. Lettura in un file 2. Analizzare quel file
Potrei abbattere i test unitari per soddisfare entrambi i casi e nel caso di 2. Quindi prenderemo in considerazione le stringhe di codifica hard in una situazione valida.
Non importa molto. Se la lingua di prova supporta i letterali stringa multi-linea, potrebbe essere un po 'più facile e veloce includere i dati nel codice di test. Se il linguaggio di test ha scarso supporto per i letterali di stringa su più righe (ad esempio Java), sarà più semplice utilizzare un file flat.
C'è niente sbagliato con valori hard-coding (che siano stringhe, numeri, oggetti, ecc.). Il test unitario è un test rigoroso che determina il comportamento di un tipo di input singolo . Avere tutte le informazioni nel test dell'unità fornisce un valore immutabile ed è più chiaro vedere cosa viene testato.
Il vantaggio dei file flat è che puoi inserire molti dati lì per alimentare i test. Il framework di test dell'unità Django funziona con fixtures , file con dati per questo scopo (in questo caso usa json o xml).
Un altro vantaggio è che il tuo codice di test è stato scritto per prelevare i dati da quel file ed è pronto per testare dati sintetici generati a mano (ormai) o per macchina, quindi puoi rilasciare quel file, salvare lo script che genera l'apparecchiatura e non devi cambiare il test.
Leggi altre domande sui tag unit-testing