Pruebas de extremo a extremo versus pruebas unitarias, ¿deberían desacoplarse las pruebas?

23

En nuestra empresa, generalmente nos aseguramos de escribir una prueba de extremo a extremo para nuestros sitios web / aplicaciones web. Eso significa que accedemos a una URL, completamos un formulario, enviamos el formulario a otra URL y verificamos los resultados de la página. Hacemos esto para probar la validación del formulario, comprobar que las plantillas HTML tienen las variables de contexto correctas, etc.

También lo usamos para probar indirectamente la lógica subyacente.

Un compañero de trabajo me dijo que la razón de esto es que podemos extraer y cambiar la implementación subyacente en cualquier momento, siempre que pasen las pruebas de extremo a extremo.

Me pregunto si este tipo de desacoplamiento tiene sentido o si es solo una forma de evitar escribir pruebas para unidades de código más pequeñas.

Rudolf Olah
fuente
66
was told by a co-worker that the reason for this is that we can rip out and change the underlying implementation at any point as long as the end-to-end tests pass.- Eso también es cierto para las pruebas unitarias. Me parece que las pruebas de extremo a extremo se están utilizando como excusa para no escribir pruebas unitarias.
Robert Harvey
12
Eso no es cierto para las pruebas unitarias. Cambiar / eliminar / crear métodos o clases requiere actualizar todas las pruebas unitarias para esos métodos o clases. No es así en las pruebas de extremo a extremo a menos que la funcionalidad del usuario final esté cambiando. Mientras se trate de un refactor de nivel de sistema (sin modificación de la funcionalidad del usuario final), no se requieren cambios en las pruebas de extremo a extremo.
dietbuddha
2
@dietbuddha, creo que el concepto general es cierto para las pruebas unitarias, pero en un ámbito (unidad) más pequeño.
Sam

Respuestas:

38

Las pruebas de extremo a extremo también son necesarias. ¿De qué otra manera puede saber que conectó todas las unidades correctamente? En un código muy simple, es posible probar todas las rutas a través del código con solo pruebas de extremo a extremo, pero a medida que obtiene más capas, se vuelve prohibitivamente más costoso hacerlo.

Por ejemplo, supongamos que tiene tres capas, cada una con cinco rutas posibles. Probar todas las rutas a través de la aplicación completa requeriría 5 3 pruebas de extremo a extremo, pero puede probar todas las rutas a través de cada unidad con solo 5 · 3 pruebas de unidad. Si solo realiza pruebas de extremo a extremo, muchos caminos terminan siendo descuidados, principalmente en el manejo de errores y las condiciones de contorno.

Karl Bielefeldt
fuente
Esa es una buena respuesta. Veo el valor de ambos, pero ver la cantidad de posibilidades para probar completamente todas las rutas con pruebas de extremo a extremo es útil para explicar por qué las pruebas unitarias deben hacerse más de lo que es
Rudolf Olah
14
Veo que las pruebas unitarias son valiosas principalmente porque localizan los problemas rápidamente. De principio a fin son valiosos porque le dan la confianza de que todo funciona en conjunto.
Jason Swett
20

Sí, las pruebas de extremo a extremo (o pruebas de integración) tienen mucho sentido, pero también lo hacen las pruebas unitarias. Idealmente, tiene ambos, ya que ambos suelen detectar diferentes tipos de errores. Por lo tanto, tener pruebas de extremo a extremo nunca debería ser una excusa para no tener pruebas unitarias.

Doc Brown
fuente
2
Una nota rápida sobre la redacción; Aunque no es una ciencia exacta, muchas personas dirán que las pruebas de punta a punta y las pruebas de integración son cosas diferentes. Ver stackoverflow.com/questions/4904096/…
sbrattla
6

Después de unos años más de codificación y trabajo en proyectos, responderé a mi propia pregunta.

Sí, deberías escribir pruebas unitarias. Las pruebas de extremo a extremo son más difíciles de escribir y frágiles, especialmente si se basan en componentes de la interfaz de usuario.

Si está utilizando un marco como Django o Rails (o sus propias clases personalizadas), debe tener una clase de formulario que se encargará de la validación del formulario. También tendrá clases de visualización que muestran plantillas renderizadas y el formulario y manejan solicitudes GET y POST.

En una prueba de extremo a extremo, usted:

  1. obtener la url
  2. rellena el formulario con datos válidos
  3. publicar el formulario en la url
  4. verifique que la base de datos se haya actualizado o que se haya ejecutado alguna acción como resultado del formulario válido

Está probando mucho código y su cobertura será bastante buena, pero solo está probando el camino feliz cuando todo sale bien. ¿Cómo se asegura de que el formulario tenga la validación correcta? ¿Qué pasa si ese formulario se usa en varias páginas? ¿Escribes otra prueba de punta a punta?

Intentemos esto nuevamente con pruebas unitarias:

  1. probar el método GET de vista
  2. prueba el método POST de vista con un formulario falso / simulado
  3. prueba el formulario con datos válidos
  4. prueba el formulario con datos no válidos
  5. probar los efectos secundarios del formulario

Al usar pruebas unitarias, está probando piezas de código más pequeñas y las pruebas son específicas y más fáciles de escribir. Cuando combina esto con TDD (Test Driven Development) obtiene un código de mayor calidad.

La facilidad de escribir pruebas unitarias no debe descartarse porque cuando está en un proyecto que no tiene pruebas automatizadas, debe comenzar en alguna parte. Comenzar con las pruebas unitarias es más fácil y rápido y le permite comenzar inmediatamente a probar errores en lugar de solo buscar el camino feliz.

Rudolf Olah
fuente
Otro punto de datos, Google Testing Blog dice que no a más pruebas de end2end
Rudolf Olah
5

En realidad, las pruebas de extremo a extremo o las pruebas de integración son más importantes que las pruebas unitarias, ya que aseguran que tiene un sistema completamente funcional. Las pruebas unitarias no cubren la parte de integración de un sistema, que es una tarea complicada, especialmente en proyectos grandes.

Sin embargo, como se ha dicho, también debe realizar pruebas unitarias, ya que es más complicado captar los casos extremos en las pruebas de integración.

m3th0dman
fuente
1

Verifica el comportamiento del sistema, mientras que las pruebas unitarias verifican el comportamiento de la unidad. Los beneficios y costos para cada uno son diferentes. Podrías hacer uno o el otro o ambos.

En mi trabajo, realizamos el desarrollo impulsado por pruebas de aceptación sin pruebas unitarias que suena similar a lo que usted ha descrito. Comenzamos haciendo ambas cosas y, con el tiempo, eventualmente eliminamos las pruebas unitarias al costo que excede los beneficios para nosotros.

Dicho esto, creo que el costo / beneficio para su dominio y entorno problemático debería impulsar las decisiones de participar en cualquier práctica de desarrollo, incluidas las diferentes prácticas de prueba automatizadas. En lugar de la fe, prefiero que todas las prácticas tengan evidencia empírica en el contexto de su uso para respaldarlas.

dietbuddha
fuente
Lo que me preocupa es que codificaremos las pruebas de aceptación que conducen a clases o métodos grandes en lugar de unidades más pequeñas.
Rudolf Olah
@omouse: el hecho de que no esté escribiendo pruebas unitarias no es motivo para no escribir un buen código. Sin embargo, si tiene programadores inexpertos o que simplemente tienen malos hábitos, los beneficios pueden ser mayores que los costos. En cualquier caso, debe hacer el análisis y reducirlo a una ecuación simple. For Any Practice: Practice iff Benefit > Cost
dietbuddha