I dati di test devono essere controllati nel controllo versione?

40

Sto scrivendo un codice di prova per una funzione che elabora i file PDF. L'idea alla base dei test è che li indico su alcuni PDF che ho selezionato appositamente, li elaborano e controllo che l'output sia quello che mi aspetto.

La mia domanda è: dove dovrei conservare questi file PDF di grandi dimensioni? Devo controllarli nel controllo della versione insieme al codice? O metterli altrove? Ovviamente, il codice di test è inutile senza i PDF (o anche con PDF diversi) ma, comunque, metterli nel nostro repository sembra sbagliato.

testing version-control data

— Swiftheart
fonte

2

possibile duplicato di Test unitari devono essere archiviati nel repository?

— un CVn

19

@ MichaelKjörling:Tests != Test Data

— Robert Harvey,

4

@RobertHarvey Vero, ma se i dati del test sono necessari affinché il test funzioni, penso che dovrebbe essere considerato parte del test. Questo è anche l'approccio adottato finora da tutte e tre le risposte, per quanto io le capisca.

— un CVn

84

Il sistema di controllo della versione dovrebbe contenere tutto ciò di cui ha bisogno per compilare, compilare, testare e impacchettare un'applicazione per la distribuzione (ad es. MSI, RPM). Direi anche che le configurazioni di build e altri script dovrebbero essere nel controllo della versione.

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

Esistono due approcci per il check-in dei dati di test. Innanzitutto, è possibile controllare i dati del test stesso (PDF in questo caso). 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 forse un file di testo che può essere compilato in un PDF o in un altro file.

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

20

Sì. Assolutamente si. È il 2014, non esiste alcuna giustificazione per l'utilizzo del controllo di revisione che non gestisce i file binari in modo uniforme.

— Kilian Foth,

4

Sono d'accordo, ma vuoi assolutamente evitare la situazione in cui stai controllando anche gli oggetti spazzatura. Ad esempio, se i dati del test includono una cartella "output" che contiene tutti i file pdf generati dai test, non sarà necessario includerli nel repository. Ma sono d'accordo sul fatto che i test stessi dovrebbero far parte del repository e di tutti i pacchetti necessari per eseguirlo.

— Kenneth Garza,

1

@KennethGarza Non è difficile, davvero. Come regola generale, dovrebbe essere incluso qualsiasi contenuto originale (codice sorgente, codice sorgente di test, dati di test, media, documentazione [reale], librerie di terze parti, script di compilazione, script di strumenti, script di conversione, ecc.), Mentre tutti i dati che può essere generato in tempi ragionevoli dai dati originali non dovrebbe essere. Inoltre, dato che sono gli output dei test, probabilmente hanno senso solo dopo aver eseguito i test da soli, altrimenti non stai testando il tuo programma, stai testando la capacità del software VCS di preservare l'integrità dei tuoi file :)

— Thomas,

1

@ MarnenLaibow-Koser: un progetto a cui ho lavorato per rilevare guasti elettrici nei conduttori di pacemaker impiantati aveva una suite di test di oltre 40 GB. Non esiste un VCS in cui gestirlo non è odioso. Avere due repository è una vera seccatura di amministrazione, ma a volte può essere la scelta migliore.

— whatsisname

1

@ MarnenLaibow-Koser ce l'hai. I test di integrazione sono in repository separati e se l'utente desidera eseguirlo localmente, la gestione delle dipendenze recupererà il file zip per lui e lo decomprimerà. Di solito il server / farm di integrazione continua ha il compito di eseguire test di integrazione e impedirà di unire il ramo delle funzionalità fino al superamento dei test di integrazione.

— user482745

15

Se i test sono inutili senza i file di installazione che hai preparato, 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'è merito nel tenere tutto insieme.

Come contrappunto, alcuni VCS non gestiscono bene i file binari di grandi dimensioni, mentre altri hanno una forte opposizione all'inclusione di 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 è possibile accedere facilmente avrebbe senso.

Vorrei anche prendere in considerazione di inserire un commento nel codice di test che dice "si basa su foo.pdfper eseguire tutti i test".

Non vedo nulla di sbagliato nel fare in modo che i test controllino i dati dei test, se non li trovano, provano a ottenerli (es. Da un URL) e falliscono se nessuno dei due funziona. Affidarsi alla rete è una cattiva idea perché rende i test più lenti e fragili; ma provare è meno fragile di così, e ottenere automaticamente (e memorizzare nella cache localmente) i dati giusti è più veloce della lettura manuale di documenti / commenti, ottenerli e metterli in atto.

— Warbo,

7

Se si tratta di dati statici, sì, inseriscili nel controllo versione. Quei file non cambieranno davvero una volta registrati; verranno rimossi se tale funzionalità non è più necessaria o verranno aggiunti nuovi file di test. In entrambi i casi, non è necessario preoccuparsi che i diff diffondi binari occupino spazio.

Se stai generando dati di test, ad es. in modo casuale, quindi dovresti salvarlo automaticamente quando un test fallisce, ma scartalo altrimenti. Tutti i dati salvati in questo modo dovrebbero essere trasformati in test di regressione regolari, in modo che tali casi limite siano definitivamente testati in futuro piuttosto che fare affidamento sulla fortuna del sorteggio.

— Warbo
fonte

2

Se stai generando dati di test in modo casuale, allora dovresti davvero uscire e acquistare un libro sulla scrittura di test automatizzati riproducibili.

— Dawood dice di ripristinare Monica il

5

@DavidWallace Quindi stai dicendo che interi campi come il test fuzz, il controllo delle proprietà e il test del software statistico non sono solo sbagliati, ma dannosi?

— Warbo,

5

@DavidWallace random! = Non riproducibile.

— congusbongus,

5

@DavidWallace puoi chiamarlo come vuoi allora. Dati di test casuali, registrare input, riciclare se necessario, ergo riproducibile. Non porta a un mondo di dolore.

— congusbongus,

2

@DavidWallace "invece di smettere di pensare a quali casi di test sono effettivamente necessari" non significa "nessun test casuale", significa "non solo test casuali". Per quanto riguarda "non riesci a riprodurre i dati che hanno trovato il bug", hai effettivamente letto la risposta che stai commentando? ;)

— Warbo,

0

Includi sicuramente quei dati con i tuoi test e il tuo codice principale dell'applicazione. 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, basato sul percorso del codice dell'app - ha sempre funzionato per me.

Con git è possibile configurare un .gitignore per impedire che qualsiasi output temporaneo o registrazione di test inquinino il repository.

— NickJHoran
fonte