Dove devo conservare i dati dei test?

Ho test di unità più piccoli che utilizzano piccoli frammenti di set di dati reali. Vorrei anche testare il mio programma su set di dati completi per una moltitudine di ragioni. L'unico problema è che un singolo set di dati reale è di circa 5 GB. Non ho trovato numeri concreti per ciò che i repository Git possono archiviare, ma sembra troppo.

Secondo questo post programmatori dovrei conservare tutti i miei dati necessari per testare il progetto nel repository.

La soluzione che il mio team ha adottato è che il progetto ha un file che contiene un percorso a un file system collegato in rete che contiene i nostri dati di test. Il file viene ignorato da Git.

Sento che questa è una soluzione imperfetta per due motivi. Quando il NAS non funziona, è lento o è inattivo, non è possibile eseguire un test completo. Il secondo motivo è che quando qualcuno clona per la prima volta un repository i test unitari falliscono, quindi devono capire come montare le cose con un certo nome e la sintassi usata per costruire il file del percorso di test.

Quindi la mia domanda è duplice. Quanti dati sono troppi dati da archiviare nel controllo di revisione?

Qual è il modo migliore per gestire grandi quantità di dati di test?

Come gestire file di grandi dimensioni in una catena di build

Mi piace usare uno strumento di compilazione che gestisca le dipendenze, ad esempio Maven o Gradle. I file sono archiviati in un repository Web e lo strumento si occupa di scaricare e memorizzare nella cache automaticamente quando incontra la dipendenza. Elimina inoltre l'installazione extra (configurazione NAS) per le persone che desiderano eseguire il test. E rende l'aggiornamento dei dati abbastanza indolore (è versionato).

Cosa c'è di troppo grande per mettere il controllo di revisione

C'è una grande area grigia. E se decidi che qualcosa non appartiene a un RCS, quali sono le tue alternative? È una decisione più semplice se limiti le tue scelte tra RCS e un repository binario (maven style).

Idealmente, si vorrebbe solo nelle cose RCS che è umanamente modificabile, diffondibile o dove si desidera tenere traccia della cronologia. Tutto ciò che è il prodotto di una build o qualche altro tipo di automazione sicuramente non appartiene a questo. La dimensione è un vincolo, ma non quello principale: un file sorgente gigante (cattiva pratica) appartiene sicuramente al controllo del codice sorgente. Un piccolo binario compilato no.

Preparati a scendere a compromessi per comodità degli sviluppatori.

Quando il NAS non funziona, è lento o è inattivo, non è possibile eseguire un test completo.

Ovviamente, questo può essere risolto solo copiando i 5 GB dal NAS sull'unità locale. Ma non è necessario farlo manualmente.

Il secondo motivo è che quando qualcuno clona per la prima volta un repository i test unitari falliscono, quindi devono capire come montare le cose con un certo nome e la sintassi usata per costruire il file del percorso di test.

È possibile fornire un semplice script shell che fa esattamente questo: montare il NAS con un determinato nome e copiare i dati sull'unità locale quando non è già presente o quando il set di dati sul NAS è più recente del set di dati locale. Assicurati che lo script venga eseguito automaticamente durante la fase di inizializzazione dei test delle unità.

Naturalmente, quando non esiste solo uno di questi set di dati, ma un sacco di dipendenze da file esterni al di fuori del repository del codice sorgente, uno strumento come quelli menzionati da @ptyx potrebbe essere la soluzione migliore.

... quando qualcuno clona per la prima volta un repository i test unitari falliscono, quindi devono capire come montare le cose con un certo nome e la sintassi usata per costruire il file del percorso di test.

Innanzitutto, solo per avere una terminologia coerente: questo tipo di test (grandi dipendenze esterne, dati reali) di solito non è considerato un test unitario, ma piuttosto un test di integrazione o di sistema .

In pratica: trovo una buona pratica tenere separati i test unitari e di integrazione , perché hanno punti di forza e punti deboli diversi.

• separare i due tipi di test nel codice (convenzione di denominazione, progetto separato, ...)
• fornire un modo per eseguire solo una delle due suite di test
• eseguire solo i test unitari durante le build normali
• eseguire i test di integrazione su richiesta e su un server CI (integrazione continua)

In questo modo, le build locali sono veloci e affidabili (dipendenze esterne scarse / nulle) e i test di integrazione sono gestiti dal server CI rinforzato. Questo evita il problema che descrivi.

Come conservare i dati:

Una buona opzione è una sorta di gestione degli artefatti come la risposta di ptyx descrive. Un altro sarebbe quello di mettere i dati di test in un repository separato . I dati non vengono comunque rilasciati insieme alla build principale e avere un repository separato evita di costringere tutti a recuperare i dati di test insieme al codice sorgente. In altre parole, utilizzare un secondo repository come gestione di artifacdt :-).