¿Por qué las pruebas funcionales no son suficientes? ¿Qué ofrecen las pruebas unitarias?

Question

Acabo de tener una conversación con mi desarrollador principal que no estuvo de acuerdo con que las pruebas unitarias sean todas las necesarias o importantes. Desde su punto de vista, las pruebas funcionales con una cobertura de código lo suficientemente alta deberían ser suficientes, ya que cualquier refactorización interna (cambios de interfaz, etc.) no provocará que las pruebas sean reescritas o examinadas nuevamente.

Intenté explicar pero no llegué muy lejos, y pensé que ustedes podrían hacerlo mejor. ;-) Entonces ...

¿Cuáles son algunas buenas razones para el código de prueba unitaria que las pruebas funcionales no ofrecen? ¿Qué peligros hay si todo lo que tienes son pruebas funcionales?

Edit # 1 Gracias por todas las buenas respuestas. Quería agregar que mediante pruebas funcionales no me refiero solo a pruebas en todo el producto, sino que también a pruebas en módulos dentro del producto, pero no en el bajo nivel de una prueba unitaria con burla si es necesario, etc. Tenga en cuenta también que nuestras pruebas funcionales son automáticas y se ejecutan continuamente, pero solo demoran más que las pruebas unitarias (que es una de las grandes ventajas de las pruebas unitarias).

Me gusta el ejemplo de brick vs. house. Creo que lo que me está diciendo desarrollador principal está poniendo a prueba las paredes de la casa es suficiente, no es necesario para poner a prueba los ladrillos individuales ... :-)

Answer 1

De la parte superior de mi cabeza

• Las pruebas unitarias son repetibles sin esfuerzo. Escriba una vez, ejecute miles de veces, sin esfuerzo humano, y una retroalimentación mucho más rápida que la obtenida de una prueba funcional
• Las pruebas unitarias prueban unidades pequeñas, por lo tanto, señale inmediatamente el "sector" correcto en el que ocurre el error. Las pruebas funcionales señalan errores, pero pueden ser causados ​​por muchos módulos, incluso en cooperación.
• Apenas llamaría a una interfaz cambiar "una refactorización interna". Los cambios de interfaz tienden a romper una gran cantidad de código, y (en mi opinión) obligan a un nuevo bucle de prueba en lugar de ninguno.

Answer 2

Puede ser mucho más difícil encontrar la fuente de problemas si falla una prueba funcional, porque está probando la base de código completo todo el tiempo. Por el contrario, las pruebas unitarias compartimentan las áreas problemáticas potenciales. Si todas las otras pruebas de la unidad tienen éxito pero esta, tiene la seguridad de que el problema está en el código que está probando y no en otra parte.

Answer 3

Los errores deben detectarse lo antes posible en el ciclo de desarrollo: si los errores cambian de diseño a código o código para probar o (con suerte) la producción aumenta el costo y el tiempo necesarios para solucionarlo.

Nuestra tienda hace cumplir las pruebas unitarias por esa sola razón (estoy seguro de que hay otras razones, pero eso es suficiente para nosotros).

Answer 4

pruebas unitarias son para desarrolladores para ver donde el código no

pruebas funcionales corresponden a la empresa para ver si el código hace lo que pidieron

Answer 5

pruebas unitarias son para desarrolladores para ver donde el código no

pruebas funcionales corresponden a la empresa para ver si el código hace lo que pidieron

unidad las pruebas están comprobando que ha fabricado sus ladrillos correctamente

pruebas funcionales que comprueban que la casa cumple con las necesidades del cliente.

Son cosas diferentes, pero esta última será mucho más fácil, si la primera se ha llevado a cabo.

Answer 6

Si utiliza una metodología pura de Programación Extrema/Desarrollo Ágil, siempre se requieren las pruebas de Unidad, ya que son los requisitos para el desarrollo.

En XP pura/un ágil hace que todos los requisitos en base a las pruebas que se van a llevar a cabo para la aplicación

• Pruebas funcionales - Generar requerimientos funcionales.
• Pruebas unitarias: genere funciones u objetos.

Aparte de eso, las pruebas de unidad se pueden utilizar para mantener un seguimiento constante de los requisitos de función.

es decir, Si necesita cambiar el modo de funcionamiento de una función, pero los campos de entrada y la salida permanecen intactos. Entonces, la prueba unitaria es la mejor manera de seguir el seguimiento de posibles problemas ya que solo necesita ejecutar las pruebas.

Answer 7

En TDD/BDD, se necesitan pruebas unitarias para escribir el programa. El proceso va

prueba no -> código -> prueba que pasa -> refactor -> repetir

El artículo vinculado también menciona los beneficios de TDD/BDD. En resumen:

• se acerca mucho a eliminar el uso de un depurador (sólo lo uso en pruebas ahora y muy rara vez para aquellos)
• Código no puede estar desordenado por más de unos pocos minutos
• ejemplos de documentación para una API incorporados
• Fuerzas acoplamiento débil

El enlace también tiene un (tonto) a pie-a través del ejemplo de TDD/BDD, pero es en PowerPoint (EW), por lo que here 's una versión html.

Answer 8

Supongamos por un momento que ya tiene un conjunto completo de pruebas funcionales que verifican todos los casos de uso posibles disponibles y está considerando agregar pruebas unitarias. Dado que las pruebas funcionales detectarán todos los errores posibles, las pruebas unitarias no ayudarán a detectar errores. Sin embargo, hay algunas desventajas en el uso de pruebas funcionales exclusivamente en comparación con una combinación de pruebas unitarias, pruebas de integración y pruebas funcionales.

• Las pruebas de unidad se ejecutan más rápido. Si alguna vez trabajó en un gran proyecto en el que el conjunto de pruebas tarda horas en ejecutarse, puede comprender por qué las pruebas rápidas son importantes.
• En mi experiencia, prácticamente hablando, las pruebas funcionales tienen más probabilidades de ser escamosas. Por ejemplo, a veces el navegador headybara-webkit sin cabeza simplemente no puede llegar a su servidor de prueba por alguna razón, pero lo vuelve a ejecutar y funciona bien.
• Las pruebas unitarias son más fáciles de depurar. Suponiendo que la prueba unitaria haya detectado un error, es más fácil y más rápido identificar exactamente dónde está el problema.

Por otra parte, suponiendo que decida simplemente mantener sus pruebas funcionales y no agregar cualquier unidad de pruebas

• Si alguna vez tiene que volver a diseñar todo el sistema, puede que no tenga para reescribir cualquier prueba. Si realizó pruebas unitarias, muchas de ellas probablemente serán eliminadas o reescritas.
• Si alguna vez necesita volver a diseñar todo el sistema, no tendrá que preocuparse por las regresiones. Si se había basado en pruebas unitarias para cubrir casos de esquina, pero se le obligó a eliminar o volver a escribir esas pruebas unitarias, es más probable que sus nuevas pruebas unitarias tengan errores en ellas que las pruebas de la unidad anterior.
• Una vez que ya ha configurado el entorno de prueba funcional y ha superado la curva de aprendizaje, escribir pruebas funcionales adicionales suele ser más fácil de escribir y más fácil de escribir que una combinación de pruebas unitarias, pruebas de integración y pruebas funcionales .