unit testing - react - ¿Cuándo usar scripts de prueba sobre pruebas unitarias?
pruebas unitarias react (6)
Actualmente estoy trabajando en un proyecto que ha estado en producción durante más de dos años. El proyecto hace un uso extensivo de pruebas unitarias y pruebas de interfaz de usuario con guiones. Las pruebas unitarias de inicio cubrieron el marco del sistema, las reglas comerciales y las transiciones de estado (o flujo de trabajo). Los scripts de prueba se usan para las pruebas de caja negra. Sin embargo, con el tiempo, el costo de mantener nuestro conjunto completo de pruebas unitarias se ha vuelto cada vez más costoso, especialmente los relacionados con el estado.
Después de un poco de investigación, descubrimos que los scripts de prueba son más efectivos (es decir, brindan una mejor cobertura) y son más económicos de mantener que las pruebas unitarias relacionadas con el flujo de trabajo. Esto no quiere decir que el valor de las pruebas unitarias haya sido completamente negado, pero plantea la pregunta de si algunas clases de pruebas unitarias pueden descartarse en favor de los scripts de prueba.
Nuestro proyecto se ejecuta en un modelo incremental iterativo.
Dos cosas diferentes
- Pruebas Unitarias - Desarrollador - verifica si el código es correcto
- Pruebas de aceptación: cliente / QA / BA: verifique que se haya desarrollado el código correcto.
Las dos categorías deben ser distintas y ambas juegan un papel igualmente importante ... Dejar caer una no es un buen augurio. Los scripts de prueba como ha mencionado caen en la segunda categoría. Recomendaría algo como FIT / Fitnesse para este propósito. Si eso no es factible, pruebe las herramientas de estilo de escritura / reproducción de registros. Pero no deseche las buenas pruebas unitarias. ¿Qué quiere decir con "el costo de mantener las pruebas se ha vuelto caro"?
En más de un sentido he experimentado el mismo tipo de dolor que tiene con respecto a las pruebas unitarias, especialmente en proyectos en los que los miembros no están entusiasmados con las pruebas unitarias y muchos de ellos simplemente ignoran o comentan las pruebas para ser capaz de engañar el control de fuente, ahorrar tiempo, etc. Un ex colega incluso acuñó el término "Desarrollo impulsado por fecha límite" para esto.
En mi opinión, cuando se enfrenta a este tipo de desafío, las siguientes son algunas pautas con respecto a las pruebas unitarias:
- Descartar pruebas obsoletas : a veces no tiene sentido intentar actualizar cientos o miles de líneas de pruebas si, en esencia, son inexactas o irrelevantes. Deseche las pruebas inmediatamente. No los "ignore", no los comente. Eliminarlos por completo.
- Escribir pruebas para una nueva funcionalidad : toda nueva funcionalidad aún necesita ser probada por unidades y escrita de una manera que pueda ser comprobada por la unidad.
- Escribir pruebas de corrección de errores : cuando la prueba de regresión de la aplicación, podría ser relevante asegurar que las correcciones de errores tengan pruebas de unidad que aseguren que la falla se haya solucionado.
- Al diablo con la cobertura del código : estoy seguro de que esto podría generar algunos votos a favor, pero hay una delgada línea entre asegurar la funcionalidad y usar las pruebas como una excusa para retrasar el trabajo . El objetivo debe ser garantizar la funcionalidad central que seguir cualquier porcentaje de cobertura de código arbitrario.
Dicho esto, sigo pensando que las pruebas unitarias no deberían descartarse por completo. Los scripts de prueba y las pruebas unitarias tienen sus propios fines. Pero debe lograrse un equilibrio entre un intento demasiado entusiasta de mantener TDD y enfrentar las realidades del desarrollo de aplicaciones empresariales.
En realidad, hay cuatro niveles de pruebas, 3 de ellos pueden incluir guiones, el primero no.
- Prueba unitaria: prueba una clase o método en completo aislamiento del resto del sistema
- prueba de ensamblaje: prueba un escenario dentro del sistema en completo aislamiento de otros componentes externos al sistema (es decir, de un dominio funcional diferente)
- Prueba de integración: pruebe el sistema, incluidas las entradas provenientes de una parte externa, y las salidas que van a otro sistema externo (es decir, desde otros dominios funcionales).
- Prueba de aceptación: las validaciones finales, como dice Gishu, para verificar el código correcto (es decir, las características correctas) están ahí.
Ejemplo de dominio funcional: Service Layer Bus, es decir, todos los proyectos (generalmente encapsulando algunas bases de datos referenciales principales) que pueden exponer sus servicios en un bus.
Usted puede hacer:
- pruebas unitarias para su clase editorial
- prueba de ensamblaje para su mecanismo editor en colaboración con otro componente de su SLB
- prueba de integración para su servicio SLB y otros componentes desarrollados fuera de SLB y cliente de sus servicios
- pruebas de aceptación para todo el sistema
Como se dijo, los últimos 3 tipos de pruebas pueden incluir secuencias de comandos pesadas y pueden cubrir rápidamente más de su código. Dependiendo del gran número de clases / métodos para la prueba unitaria, una buena prueba de ensamblaje puede ser un mejor enfoque.
Normalmente usa pruebas unitarias para hacer exactamente esto: unidades de prueba. Más exactamente, para probar si una unidad cumple con su especificación / contrato de interfaz. Si falla una prueba unitaria, usted sabe exactamente dónde está el problema: está dentro de la unidad probada. Esto facilita la depuración, especialmente porque el resultado de una prueba unitaria puede procesarse automáticamente. Las pruebas de regresión automática vienen a la mente aquí.
Empieza a utilizar pruebas de interfaz de usuario con guión si desea abandonar el alcance de las pruebas unitarias o desea probar cosas que no se pueden probar bien con las pruebas unitarias. Por ejemplo, cuando prueba código que interactúa con muchas API externas que no puede simular. Ahora puede provocar ciertos errores, pero rastrear dónde exactamente está enterrado el fallo en el código es mucho más difícil.
Una de las respuestas sobre SO a la pregunta de ''las limitaciones de la Prueba Unitaria'' fue que una prueba unitaria se complica cuando se usa para probar cualquier cosa que tenga que ver con la INTEGRACIÓN más que con la función. La conexión y el uso de servicios externos (base de datos, SSH''ing a otro servidor, etc.) e interfaces de usuario fueron dos de los ejemplos utilizados.
No es que NO PUEDE usar Pruebas unitarias para estas cosas, es solo que la dificultad de cubrir todas las bases hace que no valga la pena usar este método de prueba, excepto en casos donde la confiabilidad es primordial.
Utilizo "pruebas de guiones" para todos mis códigos personalizados de interfaz de usuario de JavaScript (motor de plantilla, efectos y animaciones, etc.) y me parece rápido y confiable si se hace bien.
Mi suposición es que el esfuerzo de mantenimiento para las pruebas de su unidad aumenta porque se permitió que la arquitectura de su aplicación se viniera abajo. Dado que nadie más que usted realmente sabe lo que hay en su código, es posible que desee aplicar el método de los cinco poros para decidir cuál es su problema de raíz real y esencial. Las pruebas de la unidad IME nunca deberían ser costosas de mantener, siempre que emplee una arquitectura altamente desacoplada, basada en interfaces.