¿Cómo se llama a los desarrolladores de la suite de prueba antes de registrarse? [cerrado]

Estoy trabajando en un proyecto donde estamos agregando pruebas automatizadas a un proyecto existente. Comenzamos con un componente central y configuramos ambas pruebas unitarias en el nivel del módulo de código y las pruebas que se ejecutan en todo el componente, aunque en el entorno del desarrollador. La intención es que este conjunto de pruebas debe pasar antes del check-in del código y será ejecutado por un sistema de integración continua en cada rama de desarrollo.

¿Cómo deberíamos llamar a esto? En este momento lo llamamos "pruebas de unidad de desarrollo", pero el lado pedante de mí dice que no está del todo bien, porque contiene más que pruebas de unidad. Y nuestra visión es que esta suite crecerá con el tiempo para incluir pruebas de aceptación de productos completos.

¿Alguna entrada aquí? ¿O deberíamos dejar de discutir sobre nombres e ir a escribir pruebas?

Actualizar

Todos, gracias por una buena discusión! Creo que la conclusión a la que estoy llegando es que no existe realmente una definición "común": cada proyecto / equipo presenta nombres que tengan más sentido para ese proyecto, dependiendo de las tecnologías (Java, C #, ruby, etc.) y metodologías (old-skool waterfall, Scrum, XP, etc.) en uso.

Se conocen como "registros cerrados" en MSFT TFS. http://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated-check-in.aspx

Llámalos como quieras, no importa. Lo que importa es la calidad de las pruebas y que se ejecutan.

Nuestras pruebas son pruebas de aceptación automatizadas, pero las llamamos "pruebas" aquí en mi trabajo. Como en:

• arregla tus "pruebas"
• rompiste las "pruebas"
• ¿Escribiste una "prueba"?
• esta "prueba" apesta, así que la reescribí

Los llamo "las pruebas" con la implicación de que estoy hablando de las "pruebas unitarias automatizadas" y con el corolario de que son rápidas (de unos segundos a unos minutos es lo que he experimentado con más frecuencia).

A veces habrá otras pruebas que se ejecutan automáticamente en un check-in, o una vez por la noche, por ejemplo. Estos tienden a tomar más tiempo. Algo entre 30 minutos y unas pocas horas. Normalmente los llamamos "las pruebas funcionales", o "las pruebas de regresión" o incluso "las pruebas lentas".

De mis experiencias:

Una prueba unitaria es una prueba o conjunto de pruebas que cubre un módulo en particular. En la programación OO, un módulo es típicamente una función o clase. Las pruebas unitarias se agrupan en conjuntos de pruebas. Las pruebas unitarias son los componentes básicos de las pruebas de regresión y de humo, y en algunos casos pueden servir como documentación para el comportamiento previsto de un sistema o partes de un sistema.

La prueba de regresión es el acto de ejecutar la mayoría o todas las pruebas unitarias en un módulo modificado. Esto garantiza que el módulo modificado continúe funcionando como se espera después de los cambios.

La prueba de humo es el acto de ejecutar un número (pequeño - desea que la prueba de humo sea bastante rápida) de pruebas unitarias en módulos no modificados para garantizar que un cambio en un módulo no tenga ningún efecto secundario no deseado en otros módulos. El enfoque generalmente está en las clases que tienen asociaciones con la clase modificada, así como en los módulos que proporcionan funcionalidad clave a la aplicación.

Dependiendo de su entorno de compilación, cualquiera de estos puede ser automatizado o ejecutado por el desarrollador. Un conjunto de cambios comprometido debe ser lo suficientemente pequeño como para que las pruebas de regresión no tomen una cantidad de tiempo inaceptablemente larga, y las pruebas de humo están diseñadas para ser bastante rápidas. Por lo general, ejecuto al menos las pruebas de regresión y humo en el código antes de que incluso se registre para no romper la compilación. Por lo general, he visto que el sistema de compilación está diseñado para ejecutar e informar sobre el estado de todos los casos de prueba de forma regular, que varía de diario a semanal, dependiendo de la tasa de desarrollo y el tiempo para construir y ejecutar las pruebas.

Si lo ejecuta a través de la base de código antes de registrarse, es una prueba de regresión.

si solo prueba el bit que ha cambiado, es una prueba unitaria.

Cuando agrega una prueba para un error a nivel del sistema, luego corríjala, es una prueba de regresión.

Sus pruebas si estás retrocediendo: yendo hacia atrás.

Vale la pena hacer pruebas de regresión porque los errores tienden a agruparse en ciertos lugares, y algunos errores se repiten.

Si puede soportar la disciplina de tener pruebas de nivel de sistema, agregar pruebas de regresión allí vale la pena. Cualquier subsistema frágil termina en una prueba de regresión.

Historia verdadera.

Las pruebas unitarias automatizadas es lo que siempre las he llamado.

No estoy seguro de si hay un término oficial o no, pero los llamaría Pruebas automatizadas. Estoy de acuerdo con usted en que la palabra unidad que se encuentra allí no es precisa.

El término "Pruebas automatizadas" cubre el espectro de Pruebas unitarias, Pruebas de regresión, Pruebas de integración, Pruebas de aceptación, etc.

Generalmente los llamamos pruebas de humo, pruebas de cordura o pruebas de prioridad 1. Las pruebas de prioridad 2 ocurren después de un registro y luego las pruebas de prioridad 3 se ejecutan en las compilaciones programadas. Nuestro conjunto final de pruebas, las pruebas de prioridad 4, ocurren cuando tenemos una compilación especial que ocurre durante un fin de semana, ya que demoran tanto tiempo en ejecutarse.