unit testing - tipos - ¿Por qué las pruebas funcionales no son suficientes? ¿Qué ofrecen las pruebas unitarias?
pruebas unitarias php (8)
Acabo de tener una conversación con mi desarrollador principal que no estaba de acuerdo con que las pruebas unitarias sean todas las necesarias o importantes. En su opinión, 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. ;-) Asi que...
¿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?
Editar # 1 Gracias por todas las excelentes 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 ladrillo contra casa. Supongo que lo que mi desarrollador líder está diciendo es que probar las paredes de la casa es suficiente, no es necesario probar los ladrillos individuales ... :-)
las pruebas unitarias son para los desarrolladores para ver dónde falló el código
pruebas funcionales son para que la empresa vea si el código hace lo que pidieron
las pruebas unitarias están comprobando que ha fabricado sus ladrillos correctamente
las pruebas funcionales comprueban que la casa cumpla con las necesidades del cliente.
Son cosas diferentes, pero la última será mucho más fácil si la primera se ha llevado a cabo.
La parte superior de mi cabeza
- Las pruebas unitarias son repetibles sin esfuerzo. Escriba una vez, ejecute miles de veces, no requiere esfuerzo humano, y una retroalimentación mucho más rápida que la que obtiene de una prueba funcional
- Las pruebas unitarias prueban unidades pequeñas, de modo que señale de inmediato el "sector" correcto en el que se produce 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.
Los errores deben detectarse lo antes posible en el ciclo de desarrollo: si los errores pasan del diseño al código, o si el código se prueba o (con suerte) la prueba a la producción aumenta el costo y el tiempo necesarios para solucionarlo.
Nuestra tienda exige pruebas unitarias solo por esa razón (estoy seguro de que hay otras razones, pero eso es suficiente para nosotros).
Puede ser mucho más difícil encontrar la fuente de problemas si falla una prueba funcional, ya que 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 unidad tienen éxito, pero esta , usted tiene la seguridad de que el problema está en el código que está probando y no en otra parte.
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 / Agile puro uno hace todos los requisitos basados en las pruebas que se van a realizar a la aplicación
- Pruebas funcionales: genere requisitos funcionales.
- Pruebas unitarias: genere funciones o requisitos de objetos.
Aparte de eso, las pruebas unitarias se pueden usar para mantener un seguimiento constante de los requisitos de la función.
es decir, si necesita cambiar la forma de trabajo de una función, pero los campos de entrada y 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.
las pruebas unitarias son para los desarrolladores para ver dónde falló el código
pruebas funcionales son para que la empresa vea si el código hace lo que pidieron
En TDD / BDD , las pruebas unitarias son necesarias para escribir el programa. El proceso va
prueba de falla -> código -> pasar la prueba -> refactorizar -> repetir
El artículo vinculado también menciona los beneficios de TDD / BDD. En resumen:
- Está muy cerca de eliminar el uso de un depurador (solo lo uso en pruebas ahora y muy raramente para eso)
- El código no puede permanecer desordenado por más de unos pocos minutos
- Ejemplos de documentación para una API incorporada
- Fuerza el acoplamiento flojo
El enlace también tiene un ejemplo (tonto) de TDD / BDD, pero está en PowerPoint (ew), así que aquí hay una versión html.
Supongamos por un segundo 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 unitarias 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 otro lado, suponiendo que decidas simplemente mantener tus pruebas funcionales y no agregar ninguna prueba unitaria
- Si alguna vez necesita volver a diseñar todo el sistema, es posible que no tenga que volver a escribir ninguna 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 a menudo es más fácil de escribir y, a menudo, más fácil de escribir correctamente que una combinación de pruebas unitarias, pruebas de integración y pruebas funcionales.