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.
fuente
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.Respuestas:
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.
fuente
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.
fuente
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:
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:
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.
fuente
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.
fuente
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.
fuente
For Any Practice: Practice iff Benefit > Cost