¿Cuándo utilizar scripts de prueba sobre pruebas unitarias?

Question

Actualmente estoy trabajando en un proyecto que ha estado en producción durante más de dos años. El proyecto hace un uso extensivo de pruebas unitarias y pruebas de interfaz de usuario con guiones. Las pruebas unitarias de inicio cubrieron el marco del sistema, las reglas comerciales y las transiciones de estado (o flujo de trabajo). Los scripts de prueba se usan para las pruebas de caja negra. Sin embargo, con el tiempo, el costo de mantener nuestro conjunto completo de pruebas unitarias se ha vuelto cada vez más costoso, especialmente los relacionados con el estado.

Después de un poco de investigación, hemos encontrado que los scripts de prueba son más efectivos (es decir, proporcionan una mejor cobertura) y son más económicos de mantener que las pruebas unitarias relacionadas con el flujo de trabajo. Esto no quiere decir que el valor de las pruebas unitarias haya sido completamente negado, pero plantea la pregunta de si algunas clases de pruebas unitarias pueden descartarse en favor de los scripts de prueba.

Nuestro proyecto se ejecuta en un modelo incremental iterativo.

Answer 1

Una de las respuestas sobre SO a la pregunta sobre "las limitaciones de la prueba unitaria" fue que las pruebas unitarias se complican cuando se usa para probar cualquier cosa que tenga que ver con la INTEGRACIÓN en lugar de la función. La conexión y el uso de servicios externos (base de datos, SSH'ing a otro servidor, etc.) e interfaces de usuario fueron dos de los ejemplos utilizados.

No es que NO PUEDA usar la Prueba de Unidad para estas cosas, es solo que la dificultad de cubrir todas las bases hace que no valga la pena usar este método de prueba excepto en casos donde la confiabilidad es primordial.

Utilizo "pruebas de guiones" para todos mis códigos personalizados de interfaz de usuario de JavaScript (motor de plantilla, efectos y animaciones, etc.) y me parece rápido y confiable si se hace bien.

Answer 2

dos cosas diferentes

• Pruebas Unitarias - Desarrollador - verificar si el código es correcto
• Pruebas de Aceptación - Cliente/GC/BA - verificar que se desarrolla el código correcto.

Las dos categorías deben ser distintas y ambas juegan un papel igualmente importante ... Dejar caer una no es un buen augurio. Los scripts de prueba como ha mencionado caen en la segunda categoría. Yo recomendaría algo como FIT/Fitnesse para este propósito. Si eso no es factible, pruebe las herramientas de estilo de escritura/reproducción de registros. Pero no deseche las buenas pruebas unitarias. ¿Qué quiere decir con "el costo de mantener las pruebas se ha vuelto caro"?

Answer 3

Normalmente utiliza pruebas unitarias para hacer exactamente esto: unidades de prueba. Más exactamente, para probar si una unidad cumple con su especificación/contrato de interfaz. Si falla una prueba unitaria, usted sabe exactamente dónde está el problema: está dentro de la unidad probada. Esto facilita la depuración, especialmente porque el resultado de una prueba unitaria puede procesarse automáticamente. Las pruebas de regresión automática vienen a la mente aquí.

Empieza a utilizar las pruebas de IU con guiones si desea abandonar el alcance de las pruebas unitarias o desea probar cosas que no se pueden probar bien con las pruebas unitarias. P.ej. cuando prueba código que interactúa con muchas API externas que no puede simular. Ahora puede provocar ciertos errores, pero rastrear dónde exactamente está enterrado el fallo en el código es mucho más difícil.

Answer 4

En realidad, hay cuatro niveles de pruebas, 3 de ellas pueden implicar secuencia de comandos, la primera no.

pruebas
• unidad: probar una clase o método en completo aislamiento del resto del sistema
• pruebas de montaje: probar un escenario dentro del sistema en completo aislamiento de otros componentes externos al sistema (es decir, de una dominio funcional diferente)
• pruebas de integración: pruebe el sistema, incluidas las entradas provenientes de una parte externa, y las salidas que van a otro sistema externo (es decir, desde otros dominios funcionales).
• prueba de aceptación: las validaciones finales, como dice Gishu, para verificar el código correcto (es decir, las funciones correctas) están ahí.

Ejemplo de dominio funcional: Service Layer Bus, es decir, todos los proyectos (normalmente encapsulando algunas bases de datos referenciales principales) pueden exponer sus servicios en un bus.
Usted puede hacer:

• pruebas unitarias para su clase editor
• prueba de ensamblaje para su mecanismo de editor en colaboración con otro componente de su
• prueba de integración SLB para usted el servicio SLB y otros componentes desarrollados fuera de SLB y cliente de sus servicios
• pruebas de aceptación para todo el sistema.

Como he dicho, los últimos 3 tipos de pruebas pueden implicar secuencias de comandos pesadas y pueden cubrir rápidamente más de su código. Dependiendo del gran número de clases/métodos para la prueba unitaria, una buena prueba de ensamblaje puede ser un mejor enfoque.

Answer 5

En más de un sentido he experimentado el mismo tipo de dolor que tiene con las pruebas unitarias, especialmente en proyectos donde los miembros no están entusiasmados con las pruebas unitarias y muchos de ellos simplemente ignoran o comentan Pruebas de salida para poder engañar el control de fuente, ahorrar tiempo, etc. Un ex colega incluso acuñó el término "Desarrollo impulsado por fecha límite" para esto.

En mi opinión cuando se enfrentan a este tipo de desafío, las siguientes son algunas pautas vis-a-vis las pruebas unitarias:

• Desechar las pruebas obsoletas - A veces no tiene sentido tratar de actualizar cientos a miles de líneas de pruebas si son, en esencia, inexactas o irrelevantes. Deseche las pruebas inmediatamente. No los "ignore", no los comente. Eliminarlos por completo.
• Pruebas de escritura para la nueva funcionalidad - Toda nueva funcionalidad aún debe ser probada y escrita de manera unitaria.
• Escribir pruebas de corrección de errores - Cuando la prueba de regresión de la aplicación, puede ser relevante para garantizar que las correcciones de errores tengan pruebas de unidad que aseguren que la falla se ha solucionado.
• Al infierno con código de cobertura - Esto podría ganar algunos votos a favor, estoy seguro, pero there is a fine line between ensuring functionality and using tests as an excuse to delay work. El objetivo debe ser garantizar la funcionalidad central que seguir cualquier porcentaje de cobertura de código arbitrario.

Dicho esto, sigo pensando que las pruebas unitarias no se deben descartar por completo. Los scripts de prueba y las pruebas unitarias tienen sus propios fines.Pero debe lograrse un equilibrio entre un intento demasiado entusiasta de mantener TDD y enfrentar las realidades del desarrollo de aplicaciones empresariales.

Answer 6

Mi hipótesis es que el esfuerzo de mantenimiento para las pruebas de su unidad aumenta porque se permitió que la arquitectura de su aplicación se viniera abajo. Dado que nadie más que usted realmente sabe lo que hay en su código, es posible que desee aplicar el método de los cinco poros para decidir cuál es su problema de raíz real y esencial. Las pruebas de la unidad IME nunca deberían ser costosas de mantener, siempre que emplee una arquitectura altamente desacoplada, basada en interfaces.