TDD: come testare le uscite dei file?

Ho fatto questo usando una libreria per analizzare i file. Sembra che tu ne abbia già uno disponibile, quindi dovresti usare questo.

Anche se potessi confrontare la totalità dei file binari, non lo consiglierei. Diciamo che hai 100 test che stanno testando varie cose confrontando l'intero output binario. Quindi viene introdotto un nuovo requisito in base al quale il titolo di ogni file deve essere cambiato da "Foo" a "Bar". Supponendo che tutti i tuoi file di output emettessero un titolo di "Foo", ora hai 100 test non funzionanti da correggere.

Un modo migliore è testare solo una cosa in un test che non si sovrapponga agli altri test. In questo contesto, solo alcuni test dovrebbero essere responsabili della verifica del titolo. Quindi se arriva lo stesso requisito, solo quei pochi test dovrebbero essere cambiati.

How are this kind of things usually dealt with?

Non testando i file unitamente.

Generalmente, esiste un formato intermedio che definisce il contenuto del file. Dovresti verificare che il contenuto intermedio che ti aspetti venga inviato per essere PDF-ified. In pratica, isola tutto ma in realtà codificando l'output in PDF. In un mondo ideale, quel lavoro sarà fatto da qualche libreria, quindi non è necessario testarlo.

In un mondo realistico, hai bisogno che gli umani guardino i PDF per assicurarti che siano ben formati e "perfetti" comunque (e caricati correttamente in Acrobat su piattaforme diverse, ecc.), quindi chiedi loro di controllare il contenuto pure. Non tutto è adatto per TDD.

Il test dei file di output è sempre una cosa difficile, lo stesso vale per testare il download di file dal web o l'output sulla console.

Una domanda che dovresti porci è: "Fino a che punto posso testare fino a quando non ho bisogno del file?" La maggior parte della logica può essere testata usando un qualche tipo di codice sostitutivo o un semplice generatore di file di testo.
Osservando la tua domanda puoi generare più file, quindi suppongo che tu abbia già una sorta di separazione tra il codice che fornisce i dati e il codice che sta generando il file. Quindi la mia risposta sarà basata sul presupposto che esiste un tipo di fabbrica che genera il file vero e proprio.

Una domanda che ti puoi porre è: quanto è complessa la fabbrica, contiene molta logica extra o chiama solo funzioni da un'altra libreria che sta creando i file per te?
Se la fabbrica ha molta logica, è la stessa per tutti i tipi di uscite o diversa per ogni uscita? Quando è lo stesso, dovresti pensare di rifarlo dalla fabbrica o aggiungere un formato facile da testare (come un file di testo).
Quando chiama solo una libreria, devi testarla automaticamente? non stai andando a testare la libreria che stai usando?

Quindi in pratica testerei il più possibile che non mi imponga di creare un file complesso. I file di testo normale, inclusi html e json, sono relativamente facili da testare perché sono leggibili e confrontabili. Per testare le uscite binarie, probabilmente creerò un semplice file di esempio da testare e scriverò un test che usa la fabbrica per generare lo stesso file e testare il file a livello di byte. Generato con gli stessi parametri dovrebbe generare lo stesso file più e più volte.

L'output del file di solito appartiene ai test di integrazione (= avere alcuni componenti che lavorano insieme) e non ai unittests (= testare un componente in isolamento)

se la tua generazione di PDF è implementata in modo che lo stesso input produca sempre lo stesso output puoi provare approvaltests che fa un binario confronta con il risultato della chiamata precedente. se non ci sono risultati precedenti o il confronto binario è diverso, una gui ti chiede se la vecchia e la nuova versione sono uguali e mostra entrambi i file pdf con acrobat reader.

In questo modo sei informato ogni volta che l'output cambia, che potrebbe essere ok o meno. Esempio

Nota:

se la generazione di PDF inserisce la data corrente nell'output, l'uscita sarà diversa per ogni chiamata.

Se fornisci la data come parametro per il pdf-api, puoi generare un output identico.

Esistono diversi modi per testare i file:

1. Confronto binario . Emettere un file di risultato "d'oro" per ciascun test; conferma manualmente è giusto; memorizzalo e confrontalo con i futuri output di file. Pro: semplice. Contro: fragile. Prona a falsi negativi (specialmente se i file contengono metadati, come "data di creazione" che cambiano anche quando i dati "payload" non cambiano.)
2. Analisi del file . Utilizzare una libreria per analizzare il file (Excel, PDF, testo, ...). Esegui asserzioni sui dati analizzati. Pro: meno fragile del confronto binario. Può facilmente evitare il fluttuarsi dei metadati. Contro: più difficile e complesso da codificare. Non tutti i formati di file sono prontamente analizzati, né le interessanti funzionalità dell'output sono riconducibili a una serie concisa e descrittiva di asserzioni di test.
3. Confronto reso . Emetti il file; utilizzare un motore di rendering per convertire il file in una rappresentazione più confrontabile (ad esempio un file immagine senza perdita di dati). Pro: può essere meno fragile del puro confronto binario e più semplice da codificare rispetto all'analisi e alle asserzioni. Si concentra facilmente sul "carico utile" piuttosto che sui metadati. Contro: dipendente dal renderer e dall'entità di rendering (inclusa una versione specifica del renderer). Richiede gli stessi file "golden image" come semplici confronti binari. Potrebbe richiedere operazioni di ritaglio, filtraggio e ordinamento per allineare e confrontare solo le parti pertinenti.