¿Dónde debo almacenar los datos de prueba?

Tengo pruebas unitarias más pequeñas que usan fragmentos pequeños de conjuntos de datos reales. También me gustaría probar mi programa contra conjuntos de datos completos por una multitud de razones. El único problema es que un único conjunto de datos real es de aproximadamente ~ 5 GB. No he encontrado ningún número difícil para lo que los repositorios de Git pueden almacenar, pero eso parece demasiado.

De acuerdo con esta publicación de los Programadores, debería mantener todos mis datos necesarios para probar el proyecto en el repositorio.

La solución que mi equipo ha adoptado es que el proyecto tiene un archivo que contiene una ruta a un sistema de archivos conectado a la red que contiene nuestros datos de prueba. El archivo es Git ignorado.

Siento que esta es una solución imperfecta por dos razones. Cuando el NAS no funciona, es lento o está inactivo, entonces no podemos ejecutar una prueba completa. La segunda razón es que cuando alguien clona un repositorio por primera vez, las pruebas unitarias fallan, por lo que tienen que descubrir cómo montar cosas con un nombre determinado y la sintaxis utilizada para construir el archivo de ruta de prueba.

Entonces mi pregunta es doble. ¿Cuántos datos son demasiados datos para almacenar en el control de revisión?

¿Cuál es una mejor manera de manejar grandes cantidades de datos de prueba?

Cómo manejar archivos grandes en una cadena de compilación

Me gusta usar una herramienta de compilación que gestiona dependencias, como maven o gradle. Los archivos se almacenan en un repositorio web, y la herramienta se encarga de descargar y almacenar en caché automáticamente cuando se encuentra con la dependencia. También elimina la configuración adicional (configuración NAS) para las personas que desean ejecutar la prueba. Y hace que la actualización de los datos sea bastante indolora (está versionada).

¿Qué es demasiado grande para poner en control de revisión?

Hay una gran área gris. Y si decide que algo no pertenece a un RCS, ¿cuáles son sus alternativas? Es una decisión más fácil si limita sus opciones entre el RCS y un repositorio binario (estilo maven).

Idealmente, solo querrías en el material RCS que sea humanamente editable, difusa o donde quieras rastrear el historial. Cualquier cosa que sea producto de una construcción o algún otro tipo de automatización definitivamente no pertenece allí. El tamaño es una restricción, pero no la principal: un archivo fuente gigante (mala práctica) definitivamente pertenece al control fuente. Un pequeño binario compilado no lo hace.

Esté listo para comprometerse para la conveniencia del desarrollador.

Cuando el NAS no funciona, es lento o está inactivo, entonces no podemos ejecutar una prueba completa.

Obviamente, esto solo se puede resolver copiando los 5 GB del NAS a su disco local. Pero no hay necesidad de hacer esto manualmente.

La segunda razón es que cuando alguien clona un repositorio por primera vez, las pruebas unitarias fallan, por lo que tienen que descubrir cómo montar cosas con un nombre determinado y la sintaxis utilizada para construir el archivo de ruta de prueba.

Podría proporcionar un script de shell simple que haga exactamente esto: monte el NAS con un nombre determinado y copie los datos en su unidad local cuando aún no esté allí, o cuando el conjunto de datos en el NAS sea más nuevo que el conjunto de datos local. Asegúrese de que el script se ejecutará automáticamente durante la etapa de inicialización de sus pruebas unitarias.

Por supuesto, cuando no solo hay uno de esos conjuntos de datos, sino un montón de dependencias a archivos externos fuera de su repositorio de código fuente, entonces una herramienta como las mencionadas por @ptyx podría ser la mejor solución.

... cuando alguien clona por primera vez un repositorio, las pruebas unitarias fallan, por lo que tienen que descubrir cómo montar cosas con un nombre determinado y la sintaxis utilizada para construir el archivo de ruta de prueba.

Primero, solo para tener una terminología consistente: este tipo de prueba (grandes dependencias externas, datos reales) generalmente no se considera una prueba unitaria, sino más bien una prueba de integración o de sistema .

En una nota práctica: me parece una buena práctica mantener las pruebas de unidad e integración separadas , porque tienen diferentes fortalezas y debilidades.

• separe los dos tipos de pruebas en el código (convención de nomenclatura, proyecto separado, ...)
• proporcionar una forma de ejecutar solo uno de los dos conjuntos de pruebas
• ejecutar solo las pruebas unitarias durante las compilaciones normales
• ejecutar las pruebas de integración bajo demanda y en un servidor CI (integración continua)

De esta forma, las compilaciones locales son rápidas y confiables (dependencias externas poco / nada), y las pruebas de integración son manejadas por el robusto servidor CI. Esto evita el problema que usted describe.

En cuanto a cómo mantener los datos:

Una buena opción es algún tipo de gestión de artefactos como la respuesta de ptyx describe. Otra sería colocar los datos de prueba en un repositorio separado . Los datos no se liberan junto con la compilación principal de todos modos, y tener un repositorio separado evita obligar a todos a buscar los datos de prueba junto con el código fuente. En otras palabras, use un segundo repositorio como su administración de artefactos :-).