Dove devo archiviare i dati del test?

Come gestire file di grandi dimensioni in una catena di build

Mi piace usare uno strumento di compilazione che gestisca le dipendenze, come ad esempio maven o gradle. I file sono archiviati in un repository web e lo strumento si occupa del download e del caching automatico quando incontra la dipendenza. Elimina anche l'installazione extra (configurazione NAS) per le persone che vogliono eseguire il test. E rende i dati abbastanza rinfrescanti (è versione).

Che cosa è troppo grande per inserire 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 (stile maven).

Idealmente, ti piacerebbe solo nella roba RCS che è umanamente modificabile, diffondibile, o dove vorresti tracciare la 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 il principale: un file sorgente gigante (cattiva pratica) appartiene sicuramente al controllo del codice sorgente. Un piccolo binario compilato non lo fa.

Sii pronto a scendere a compromessi per la comodità dello sviluppatore.

When the NAS isn't working, is slow, or is down than we can't run a full test.

Ovviamente, questo può essere risolto solo copiando il 5GB dal NAS al disco locale. Ma non è necessario farlo manualmente.

The second reason is that when someone first clones a repository the unit tests fail so they have to figure out how to mount things with a certain name and the syntax used to build the testing path file.

Potresti fornire un semplice script di shell che fa esattamente questo: monta il NAS con un certo nome e copia i dati sul tuo disco locale quando non è già lì, o quando il set di dati sul NAS è più recente di quello locale set di dati. Assicurati che lo script venga eseguito automaticamente durante la fase di inizializzazione dei test delle tue unità.

Naturalmente, quando non c'è 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.

...when someone first clones a repository the unit tests fail so they have to figure out how to mount things with a certain name and the syntax used to build the testing path file.

In primo luogo, 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 .

Da un punto di vista pratico: trovo una buona pratica per mantenere i test di unità e integrazione separati , perché hanno punti di forza e punti deboli diversi.

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

In questo modo, le build locali sono veloci e affidabili (poca / nessuna dipendenza esterna) e i test di integrazione sono gestiti dal potente server CI. Questo evita il problema che descrivi.

Come mantenere i dati:

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