¿Deben almacenarse las pruebas unitarias en el repositorio?

50

Soy un programador en crecimiento que finalmente está poniendo en práctica las pruebas unitarias para una biblioteca que estoy almacenando en GitHub.

Se me ocurrió que podría incluir las suites de prueba en el repositorio, pero al mirar otros proyectos, la inclusión de pruebas parece impredecible.

¿Se considera esto una mala forma? ¿Es la idea de que los usuarios solo están interesados en el código de trabajo y de todos modos probarán en su propio marco?

version-control unit-testing

— Parisminton
fuente

13

Por qué no? Las pruebas deben venir junto con el proyecto o son apenas inútiles.

61

El hecho de que algunos proyectos no incluyan pruebas unitarias en su repositorio es más probable debido a la inexistencia de estas pruebas en primer lugar.

— prasopes

44

Se construyen por separado, pero de lo contrario las pruebas U están estrechamente relacionadas con el código. Para garantizar la coherencia debe haber algún tipo de gestión de dependencia. Ya sea poniéndolos en el mismo repositorio, subrepositorio o manteniendo el "enlace" controlado por versión para probar el repositorio, etc.

— MaR

2

@stoupa tiene toda la razón: sería maravilloso asumir lo mejor, que hay un maravilloso caché de pruebas ocultas en alguna parte, pero en el mundo real, los programadores son flojos.

— Cascabel

2

Tenga en cuenta que consideraría una buena idea deshabilitar la compilación de la clase de prueba en su script de compilación.

— user606723

119

Definitivamente deberías poner tus pruebas en el repositorio. En mi opinión, las pruebas son parte del código y pueden ayudar inmensamente a otros a comprenderlo (si está bien escrito). Además, pueden ayudar a otros al cambiar o contribuir a su base de código. Las buenas pruebas pueden darle la confianza de que sus cambios no rompen nada sin darse cuenta.

Sin embargo, el código de prueba debe estar bien separado del código de producción. Maven, por ejemplo, logra esto colocando el código de producción y prueba en diferentes carpetas. La pregunta "es este archivo parte de la producción o del código de prueba" nunca debería surgir.

Yo personalmente no escribo pruebas unitarias para bibliotecas usadas en mi propio código. Espero que funcionen (al menos cuando uso una versión de lanzamiento, aunque obviamente pueden aparecer errores). Obtiene cierta cobertura de prueba en las pruebas de integración, pero eso no es suficiente.

— ftr
fuente

1

Como otro ejemplo, eche un vistazo a la carpeta de pruebas de ipython . Si alguien lo revisa, sin importar dónde lo coloque, los enlaces relativos para las pruebas siguen siendo ciertos. Resulta trivial probarlo, lo cual es importante para determinar si su nueva máquina de desarrollo está configurada correctamente.

— Spencer Rathbun

Las pruebas no son solo parte del código, sino también parte de la documentación y, a menudo, parte de la especificación. Las pruebas (que se ejecutan y pasan) son "documentación viva".

— Michael Pascua

54

Si no incluye las pruebas unitarias en el código fuente registrado, entonces:

¿Cómo va a verificar alguien que descarga y crea su propia copia de ese código que está funcionando de la manera prevista? Los errores de compilación y biblioteca son raros, y los errores de datos (particularmente los que no hacen que el código fuente sea imposible de compilar) son aún más raros, pero definitivamente pueden recortarse, particularmente cuando no puede dictar el entorno de compilación en la medida en que El empleador puede dictar qué herramientas se utilizan.
¿Cómo va a recuperar las pruebas si algo le sucede a su copia local del código fuente?
¿Cómo va a verificar un nuevo desarrollador que sus cambios no rompan nada en la base de código existente?

En pocas palabras, consideraría que no incluir ninguna prueba unitaria escrita en el repositorio oficial de código fuente es algo muy malo.

— un CVn
fuente

7

Por supuesto, debe colocar pruebas unitarias en el repositorio, por varias razones:

es fácil volver a la versión anterior
otras personas que trabajan en el proyecto también obtienen acceso a pruebas unitarias
Algunas personas consideran las pruebas unitarias como parte de la documentación (TDD y BDD)

— BЈовић
fuente

6

Si hay alguna posibilidad de ejecutarlos en otra computadora, inclúyalos definitivamente. Deben construirse por separado, para que los usuarios no tengan que hacerlo, y pueden tener dependencias adicionales, pero definitivamente deben incluirse.

Sospecho firmemente que la mayoría de los proyectos que no incluyen pruebas en el repositorio simplemente no tienen ninguno.

Puede haber una razón para tener las pruebas como un módulo separado, para que pueda ejecutar fácilmente nuevas pruebas contra el código anterior. Sería útil para la biblioteca estable de API o las pruebas de recuadro negro a través de la línea de comandos; La utilidad para los lenguajes compilados donde las nuevas pruebas probablemente no se compilarán con código anterior es limitada.

— Jan Hudec
fuente

5

Absolutamente. Los puntos de bonificación adicionales aquí están en la capacidad de rastrear que la versión X de un archivo fuente va con la versión Y de una prueba. En otras palabras, debe poder volver a una versión anterior y extraer las pruebas apropiadas diseñadas para esa versión (en caso de un cambio de API o algo así).

— luego
fuente

3

Acabo de terminar de leer "Desarrollo de aplicaciones Brownfield en .Net" , y esto proporciona algunos consejos excelentes sobre la estructura de una aplicación, incluido el control de origen y dónde / cómo / por qué incluir pruebas unitarias (particularmente en el área de Integración continua) . Si eres un desarrollador de .Net, lo recomendaría.

— seanfitzg
fuente