¿Se deben verificar los datos de prueba en el control de versiones?

40

Estoy escribiendo un código de prueba para una función que procesa archivos PDF. La idea básica detrás de las pruebas es que las apunto a algunos archivos PDF que he seleccionado especialmente, los procesan y compruebo que el resultado es lo que espero.

Mi pregunta es: ¿dónde debería almacenar estos archivos PDF de gran tamaño? ¿Debo registrarlos en el control de versiones junto con el código? O ponerlos en otro lugar? Obviamente, el código de prueba es inútil sin los PDF (o incluso con diferentes PDF) pero aún así, ponerlos en nuestro repositorio se siente mal.

testing version-control data

— Swiftheart
fuente

2

posible duplicado de ¿Deben almacenarse las pruebas unitarias en el repositorio?

— un CVn

19

@ MichaelKjörling:Tests != Test Data

— Robert Harvey

44

@RobertHarvey Verdadero, pero si se requieren los datos de prueba para que la prueba funcione, creo que debería considerarse parte de la prueba. Ese es también el enfoque adoptado por las tres respuestas hasta ahora, según tengo entendido.

— un CVn

84

Su sistema de control de versiones debe contener todo lo que necesita para construir, compilar, probar y empaquetar una aplicación para distribución (por ejemplo, MSI, RPM). También argumentaría que las configuraciones de compilación y otros scripts también deberían estar en el control de versiones.

Debería poder revisar un proyecto y tener un entorno completo de compilación, compilación y prueba.

Hay dos enfoques para verificar los datos de prueba. Primero, puede verificar los datos de prueba en sí (PDF en este caso). En segundo lugar, puede registrar los datos de origen que se pueden usar para generar datos de prueba (si corresponde). Esto podría ser una secuencia de comandos SQL cargada en una base de datos en blanco que contiene datos de prueba, o tal vez un archivo basado en texto que se puede compilar en un PDF u otro archivo.

Otros pueden estar en desacuerdo con la verificación todo en el control de versiones, pero en mi experiencia profesional he descubierto que es fundamental para garantizar que un entorno completo pueda reconstruirse desde cero.

20

Sí. Absolutamente sí. Es 2014, no hay justificación alguna para usar el control de revisión que no maneja archivos binarios a la perfección.

— Kilian Foth

44

Estoy de acuerdo, pero definitivamente quieres evitar la situación en la que también estás registrando artículos basura. Por ejemplo, si los datos de prueba incluyen una carpeta de "salida" que contiene todos los archivos pdf generados por las pruebas, entonces no querrá incluirlos en el repositorio. Pero sí estoy de acuerdo en que las pruebas en sí mismas deberían ser parte del repositorio, así como cualquier paquete necesario para ejecutarlo.

— Kenneth Garza

1

@KennethGarza No es difícil, de verdad. Como regla general, se debe incluir cualquier contenido original (código fuente, código fuente de prueba, datos de prueba, medios, documentación [real], bibliotecas de terceros, scripts de compilación, scripts de herramientas, scripts de conversión, etc.), mientras que todos los datos que puede generarse en un tiempo razonable a partir de los datos originales no debe ser. Además, dado que esas son las salidas de prueba, probablemente solo tengan sentido después de ejecutar las pruebas usted mismo, de lo contrario no está probando su programa, está probando la capacidad del software VCS para preservar la integridad de sus archivos :)

— Thomas

1

@ MarnenLaibow-Koser: un proyecto en el que trabajé para detectar fallas eléctricas en cables marcapasos implantados tenía un conjunto de pruebas de más de 40 GB. No existe un VCS en el que lidiar con eso no sea desagradable. Tener dos repos es una molestia de administración propia, pero a veces puede ser la mejor opción.

— cuál es

1

@ MarnenLaibow-Koser lo tienes. Las pruebas de integración están en un repositorio separado y si el usuario desea ejecutarlo localmente, la administración de dependencias buscará el archivo zip para él y lo descomprimirá. Por lo general, el servidor / granja de integración continua tiene la tarea de realizar una prueba de integración y evitará la fusión de la rama de características hasta que pasen las pruebas de integración.

— user482745

15

Si las pruebas son inútiles sin los archivos de configuración que ha preparado, entonces tiene sentido incluir los archivos en su VCS junto con el código de prueba.

Si bien los archivos utilizados en la prueba no son código, puede verlos como una dependencia en la que se basa el código. Así que hay mérito en mantener todo junto.

Como contrapunto, algunos VCS no manejan bien los archivos binarios grandes, y otros tienen una fuerte oposición a incluir cualquier tipo de archivo binario en un VCS. Si alguno de esos casos se aplica a usted, entonces también tendría sentido almacenar los archivos de prueba en una ubicación conocida a la que se pueda acceder fácilmente.

También consideraría poner un comentario en el código de prueba que diga "depende foo.pdfpara ejecutar todas las pruebas".

No veo nada malo en hacer que las pruebas verifiquen los datos de la prueba, si no se encuentran, intenten obtenerlos (por ejemplo, desde una URL) y fallen si ninguno funcionó. Confiar en la red es una mala idea porque hace que las pruebas sean más lentas y frágiles; pero intentar es menos frágil que no y obtener automáticamente (y almacenar en caché localmente) los datos correctos es más rápido que leer documentos / comentarios manualmente, obtenerlos y ponerlos en su lugar.

— Warbo

7

Si se trata de datos estáticos, sí, póngalo en control de versiones. Esos archivos realmente no cambiarán una vez que estén registrados; se eliminarán si ya no se necesita esa funcionalidad o se agregarán nuevos archivos de prueba. De cualquier manera, no necesita preocuparse por las diferencias binarias pobres que ocupan espacio.

Si está generando datos de prueba, por ejemplo. al azar, debe guardarlo automáticamente cuando falla una prueba, pero descartarlo de lo contrario. Cualquier dato guardado de esta manera debe convertirse en pruebas de regresión regulares, de modo que esos casos límite se prueben definitivamente en el futuro en lugar de depender de la suerte del sorteo.

— Warbo
fuente

2

Si está generando datos de prueba al azar, entonces debería salir y comprar un libro sobre cómo escribir pruebas automatizadas reproducibles.

— Dawood dice que reinstalará a Monica el

55

@DavidWallace Entonces, ¿estás diciendo que campos completos como la prueba de fuzz, la verificación de propiedades y la prueba de software estadístico no solo son incorrectos, sino perjudiciales?

— Warbo

55

@DavidWallace random! = Irreproducible.

— congusbongus

55

@DavidWallace puedes llamarlo como quieras entonces. Datos de prueba aleatorios, entradas de registro, reciclaje si es necesario, ergo reproducible. No conduce a un mundo de dolor.

— congusbongus

2

@DavidWallace "en lugar de detenerse a pensar qué casos de prueba se necesitan realmente" no significa "no hay pruebas aleatorias", significa "no solo pruebas aleatorias". En cuanto a "no puede reproducir los datos que encontraron el error", ¿realmente leyó la respuesta que está comentando? ;)

— Warbo

0

Definitivamente incluya esos datos con sus pruebas y su código de aplicación principal. Ayuda a tener un conjunto de pruebas realmente bien organizado, por lo que si está probando la extracción de PDF (y tiene ese código bien encapsulado), entonces debería poder construir una ruta a sus datos de prueba, en función de la ruta al código de la aplicación - Eso siempre funcionó para mí.

Con git puede configurar un .gitignore para evitar que cualquier salida temporal o registro de prueba contamine su repositorio.

— NickJHoran
fuente