I dati di test devono essere controllati nel controllo di versione?

Il tuo sistema di controllo delle versioni dovrebbe contenere tutto ciò che è necessario per compilare, compilare, test e pacchettizzare un'applicazione per la distribuzione (ad es. MSI, RPM). Vorrei anche sostenere configurazioni di build e altri script dovrebbero anche essere in controllo di versione.

Dovrei essere in grado di controllare un progetto e disporre di un ambiente di compilazione, di compilazione e di test completo.

Esistono due approcci per il controllo dei dati di test. Innanzitutto, è possibile verificare i dati di prova stessi (in questo caso i PDF). In secondo luogo, è possibile verificare i dati di origine che possono essere utilizzati per generare dati di test (se applicabile). Potrebbe trattarsi di uno script SQL caricato in un database vuoto contenente dati di test o magari un file di testo che può essere compilato in un PDF o altro file.

Gli altri potrebbero non essere d'accordo nel controllare tutto nel controllo della versione, ma ho trovato nella mia esperienza professionale che è fondamentale garantire che un ambiente completo possa essere ricostruito da zero.

Se i test sono inutili senza i file di installazione che hai preparato, allora ha senso includere i file nel tuo VCS insieme al codice di test.

Sebbene i file utilizzati nel test non siano codice, è possibile visualizzarli come una dipendenza su cui si basa il codice. Quindi c'è il merito nel mantenere tutto insieme.

Come contrappunto, alcuni VCS non gestiscono bene i file binari di grandi dimensioni, e altri hanno una strong opposizione a includere qualsiasi tipo di file binario in un VCS. Se uno di questi casi si applica a te, anche la memorizzazione dei file di test in una posizione ben nota a cui è facilmente accessibile avrebbe senso.

Prenderò in considerazione la possibilità di inserire un commento nel codice di test che dice "fa affidamento su foo.pdf per poter eseguire tutti i test."

Se si tratta di dati statici, allora sì mettilo in controllo di versione. Quei file non cambieranno davvero una volta che sono stati registrati; verranno rimossi se tale funzionalità non è più necessaria o verranno aggiunti nuovi file di test. In entrambi i casi, non devi preoccuparti del fatto che i diff binari sono scarsi e occupare spazio.

Se stai generando dati di test, ad es. casualmente, quindi dovresti salvarlo automaticamente quando un test fallisce, ma scartalo altrimenti. Tutti i dati salvati in questo modo dovrebbero essere trasformati in regolari test di regressione, in modo che questi edge case siano definitivamente testati in futuro, piuttosto che affidarsi alla fortuna del sorteggio.

Includere sicuramente quei dati con i test e il codice dell'applicazione principale. Aiuta ad avere una suite di test davvero ben organizzata - quindi se stai testando l'estrazione di pdf (e hai quel codice ben incapsulato) dovresti essere in grado di costruire un percorso per i tuoi dati di test, in base al percorso del codice dell'app - Ha sempre funzionato per me.

Con git puoi configurare un .gitignore per impedire che l'output temporaneo o la registrazione del test danneggino il tuo repository.