¿Cuál es el equilibrio correcto entre la unidad y las pruebas funcionales en una aplicación web típica?

Question

Las pruebas unitarias son más baratas de escribir y mantener, pero no cubren todos los escenarios. ¿Cuál es el equilibrio correcto entre ellos?

Answer 1

Me gusta el cuadrante de Brian Marick en pruebas automatizadas donde las distinciones son negocios frente a tecnología y programación de soporte versus producto crítico.

Con ese marco, la cuestión del equilibrio se convierte en ¿qué necesito ahora mismo?

Answer 2

es importante distinguir entre la intención y el alcance de estos dos tipos de pruebas:

• a prueba de unidad generalmente prueba una característica específica a nivel de módulo / clase , p.ej create-X, update-Y, foo-the-bar, compact-the-whizbang, etc. Una clase puede tener múltiples pruebas unitarias

• a prueba funcional , también llamada 'prueba de aceptación', generalmente prueba una escenario de uso desde la interfaz más externa hasta el final del procesamiento, p. ej. desde la interfaz de usuario a la base de datos y viceversa, desde el proceso de entrada hasta la utilidad de notificación, etc.

estos dos tipos de pruebas son no intercambiables , y en general son disjuntos . Por lo tanto, la noción de lograr un "equilibrio" entre ellos no tiene sentido. Los necesitas o no.

si se refiere a la facilidad de codificar cada tipo de prueba en su marco de prueba, esa es una pregunta diferente, pero el uso del marco (por ejemplo, NUnit vs. un usuario-bot) no cambia el tipo / naturaleza de la prueba.

el mejor "balance", en general, sería una prueba unitaria de confianza e integridad, y una prueba funcional para la aceptación del cliente

Answer 3

Estoy de acuerdo con Steven Lowe en que no existe una compensación entre las pruebas unitarias y las pruebas funcionales, ya que se utilizan para fines muy diferentes.

Las pruebas unitarias tratan sobre la verificación de métodos y tipos, y también las pruebas de regresión. Las pruebas funcionales son sobre pruebas funcionales, de escenario y de factibilidad. En mi opinión, casi no hay superposición,

Si ayuda, aquí están mis categorías de prueba.

Los desarrolladores comienzan desde adentro y trabajan hacia afuera, enfocándose en el código:

• Afirmaciones: verificar el flujo de datos y las estructuras
• Depurador: verifique el flujo de código y los datos
• Prueba de unidad: verifique cada función
• Pruebas de integración: verificar subsistemas
• Prueba del sistema: verificar la funcionalidad
• Pruebas de regresión: verifique que los defectos permanezcan fijos
• Pruebas de seguridad: verifique que el sistema no pueda ser penetrado fácilmente.

Los probadores comienzan desde afuera y trabajan hacia adentro, enfocándose en las características:

• Pruebas de aceptación: verificar los requisitos del usuario final
• Pruebas de escenarios: verificar situaciones del mundo real
• Pruebas globales: verificar entradas viables
• Pruebas de regresión: verifique que los defectos permanezcan fijos
• Pruebas de usabilidad: verifique que el sistema sea fácil de usar
• Pruebas de seguridad: verifique que el sistema no pueda ser penetrado fácilmente
• Cobertura de código: prueba de código intacto
• Compatibilidad - con versiones anteriores
• Buscando peculiaridades y bordes ásperos.

Los usuarios finales trabajan desde el exterior, y generalmente tienen poca atención:

• Pruebas de aceptación: verificar los requisitos del usuario final
• Pruebas de escenarios: verificar situaciones del mundo real
• Pruebas de usabilidad: verifique que el sistema sea fácil de usar
• Buscando peculiaridades y bordes ásperos.

Answer 4

En la aplicación en la que estoy trabajando en este momento, probablemente hay 10: 1 unidad para pruebas funcionales. La prueba de unidad funciona simplemente como recuperar entidades de la base de datos, pruebas de manejo de errores para conectividad db / network, etc. Estas cosas se ejecutan rápidamente, minutos o menos y los desarrolladores las ejecutan diariamente.

las pruebas funcionales, mientras que menos tienden a ser el enfoque del fregadero de la cocina, ¿pueden los usuarios completar el pedido, etc. tienden a cubrir el dominio del negocio? Estas cosas tardan semanas en ejecutarse y, por lo general, finalizan un ciclo de lanzamiento.

Answer 5

Mi proyecto actual tiene aproximadamente un 60% de cobertura de pruebas unitarias y todas las historias de usuarios tienen una cobertura feliz de las historias de usuarios en las pruebas de selenio, algunas tienen cobertura adicional.

Continuamente estamos discutiendo esto: ¿hay realmente algún punto de impulsar la cobertura de prueba unitaria de escenarios cada vez más absurdos para una cobertura mucho más alta?

El argumento es que expandir las pruebas de selenio aumenta la cobertura de pruebas en cosas que tienen valor comercial. ¿El cliente realmente se preocupa por los casos de esquina de prueba de unidad que pueden fallar?

Cuando obtienes buenos resultados en las pruebas de selenio, el costo de escribir nuevas pruebas con valor comercial disminuye. Para nosotros son tan simples como las pruebas unitarias.

El costo de tiempo de ejecución es otro problema. Tenemos un pequeño grupo de cajas que ejecutan estas pruebas todo el tiempo.

Por lo tanto, tendemos a favorecer más las pruebas web, probablemente porque hemos logrado escribirlas y proporcionan un valor comercial innegable.

Answer 6

Originalmente me incliné mucho hacia preferir las pruebas unitarias sobre las pruebas funcionales / de aceptación debido al factor de costo inicial de las pruebas de aceptación. Sin embargo, con el tiempo he cambiado mi filosofía y ahora soy un firme defensor de elegir pruebas de aceptación siempre que sea posible y solo usar pruebas unitarias cuando las pruebas de aceptación no pueden satisfacer mis necesidades.

El racional básico detrás de elegir la aceptación sobre las pruebas unitarias es el mismo que el racional básico para código SOLID . Su implementación debería poder cambiar drásticamente con la refactorización, etc., pero todos los casos de negocios (pruebas de aceptación) deberían poder permanecer sin cambios y demostrar un comportamiento aceptable del sistema (las pruebas pasan). Con las pruebas unitarias, a menudo existe un fuerte acoplamiento natural de la prueba con el código de implementación. A pesar de que es un código de prueba, todavía debe evitarse el código y el fuerte acoplamiento como sabemos. Al elegir las pruebas de aceptación, a menudo se lo conduce por la espiral del éxito para crear APIs desacopladas bien planificadas y consumibles que permiten que su implementación cambie detrás de escena sin forzar que cambien sus pruebas. Además, sus pensamientos de implementación del desarrollador están en línea con los pensamientos de comportamiento del sistema empresarial. Al final, encuentro que todo esto es mejor para los negocios y para la satisfacción del codificador.

Desde un punto de vista teórico, a menudo me pregunto si un fragmento de código no se puede probar mediante una prueba de aceptación ¿por qué debería existir ese fragmento de código? IE: si no es parte de un escenario comercial válido, ¿ese código agrega valor o es actualmente y seguirá siendo el único costo?

Además, si comenta / documenta bien sus pruebas de aceptación, esos comentarios / documentos generalmente son el lenguaje más actual y preciso del sistema, lo que generalmente le permitirá evitar otros enfoques de documentación menos valiosos. Las pruebas unitarias no se prestan a esa forma de "término comercial" comunicación.

Por último, no he formado este punto de vista solo por mi desarrollo personal, ha demostrado ser exitoso con un par de equipos de proyectos diferentes en mi "muy corporativo". ambiente de trabajo.

JB http://jb-brown.blogspot.com

Answer 7

Las pruebas deben ejecutarse rápidamente y ayudar a localizar problemas. Las pruebas unitarias le permiten hacer esto solo probando el módulo en cuestión. Sin embargo, se puede hacer que las pruebas funcionales / de integración / aceptación se ejecuten lo suficientemente rápido en la mayoría de los escenarios web.

Answer 8

Una vez leí que una prueba unitaria es un "requisito ejecutable", lo que tiene mucho sentido para mí. Si su prueba no se enfoca en probar un requisito comercial, entonces realmente no sirve de nada. Si tiene requisitos detallados (y esa es la prueba de fuego), entonces escribirá una serie de pruebas unitarias para ejercer cada posible escenario, lo que a su vez garantizará la integridad de sus algoritmos y lógica de estructura de datos. Si está probando algo que no es un requisito pero sabe que debe ser cierto para que la prueba sea aprobada, es muy probable que no cumpla con los requisitos.