¿Pruebas unitarias en el código de versión de producción?

Question

Un par de preguntas:

1.) ¿Prueba el código de liberación de la unidad?

2.) En caso afirmativo, ¿deja intactas las pruebas unitarias para que las pruebas en sí mismas existan en el entorno de producción?

Veo el valor en el n. ° 1, pero ¿es una "buena práctica" crear dependencias en producción para, por ejemplo, los ensamblajes NUnit?

Dame tu opinión.

Answer 1

1. Absolutamente. Si nuestra construcción pasa el conjunto de pruebas unidad entonces es etiquetada y un candidato para la producción
2. No. Los despliegues no incluyen pruebas ni las librerías de soporte (por ejemplo, bibliotecas de prueba de unidad, etc.) burlones

Lo anterior es mi regla general (generalmente estoy implementando para usuarios no técnicos). Sin embargo, tengo una excepción, que es una utilidad de programación que se prueba con ~ 130 scripts de prueba. Debido a que los scripts de prueba son dos ejemplos, los implemento junto con la versión de producción y, en consecuencia, mejoran la documentación existente.

Definitivamente vale la pena implementar pruebas con código de código abierto. Permite que las personas jueguen, modifiquen y envíen parches, mientras que pueden ejecutar las pruebas que pasaron con éxito para permitir que se libere el artefacto original.

Answer 2

Sí y sí, el comportamiento de la aplicación puede ser diferente entre las compilaciones de versión y depuración, por lo tanto, como parte del proceso de publicación, la compilación de versión debe pasar todas sus pruebas unitarias.

Answer 3

1. Sí, por supuesto! Las pruebas unitarias se ejecutan en todas las configuraciones de compilación.

2. Las pruebas de unidad están siempre intactas, pero esto no significa que los conjuntos enviados dependan de nada relacionado con las pruebas. Las pruebas siempre se escriben en un ensamblaje paralelo (en el mismo entorno de compilación) que luego prueba el ensamblaje de producción. El ensamblaje paralelo no se envía ya que solo contiene las pruebas.

Answer 4

1. Sí, recuerdo el error clásico "Afirmar con efectos secundarios" que debe ser capturado también. Pero este no necesita hacerse tan a menudo como la compilación de depuración, donde se debe realizar una prueba completa todos los días.
2. Normalmente, las pruebas unitarias se realizan en diferentes unidades de traducción y en un proyecto diferente, de modo que una versión de lanzamiento del proyecto principal no las toca en absoluto. Sin embargo, si sus pruebas unitarias están en las mismas unidades de traducción que el código probado, puede usar la compilación condicional para excluirlas de las versiones.

Answer 5

Depende del proyecto. Sí al número 1. Siguiendo con el principio de que todo debería verificarse en el control del código fuente y debería ser sencillo poner en marcha un nuevo desarrollador. Hazlos parte de la base de código. Las nuevas personas pueden hacer un check out y ejecutar las pruebas.

Si se implementan en la producción es un problema diferente. No he trabajado en un proyecto que necesitaba allí.El modelo de despliegue de Rails es (en general) simplemente un check-out de todo el proyecto en una máquina de producción, entonces sí están ahí. Los proyectos Java/Maven tienen un paso completo de compilación/embalaje, y generalmente las pruebas unitarias pueden (y son) eliminarse al compilar el archivo .war final.

De cualquier manera, no esperas que se ejecuten. En el entorno actual, en realidad no importa si se ubican allí; la memoria y el disco son tan baratos que en realidad no es un problema. He escuchado el argumento de que no desea el código de prueba en el servidor de producción para que no exista riesgo de que se ejecute, pero no he oído hablar de un escenario cuando esto realmente suceda.