¿Deben almacenarse las pruebas unitarias en el repositorio?

Definitivamente deberías poner tus pruebas en el repositorio. En mi opinión, las pruebas son parte del código y pueden ayudar a otros a entenderlo (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 inadvertidamente.

Sin embargo, el código de prueba debe estar bien separado del código de producción. Maven, por ejemplo, logra esto al colocar el código de producción y de prueba en diferentes carpetas. La pregunta "es esta parte del archivo de producción o del código de prueba" nunca debe 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.

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

• ¿cómo alguien que descarga y construye su propia copia de ese código va a verificar que está funcionando de la manera en que fue diseñado? Los errores de compilación y de 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 recortar, particularmente cuando no puede dictar el crear un entorno en la medida en que un empleador pueda dictar qué herramientas se utilizan.
• ¿cómo se recuperarán 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 rompen nada en la base de código existente?

En conclusión, consideraría que no , incluyendo cualquier prueba de unidad escrita en el repositorio de código fuente oficial, es algo muy malo.

Por supuesto, debe poner las 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)

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

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

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

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 realizar las pruebas apropiadas diseñadas para esa versión (en caso de un cambio de API o algo así).

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