unit testing - tipos - Pruebas Unitarias vs. Pruebas de Aceptación
pruebas unitarias funcionales (5)
Sin embargo, para minimizar el trabajo redundante, ¿es una buena idea intentar incorporar pruebas unitarias en las pruebas de aceptación?
No.
En otras palabras, haga que la última [aceptación] llame a la [unidad] anterior. ¿Tiene sentido ir en la dirección opuesta?
No te molestes
Las pruebas de aceptación a menudo son políticas. Se los muestras a personas que, en función de su instinto, deciden aceptar o rechazar.
Entonces usted discute sobre la validez de las pruebas de aceptación.
Luego discuten sobre el alcance del trabajo y la próxima versión.
Las pruebas de aceptación no son, generalmente, técnicas. Si lo fueran, entonces tendrías pruebas unitarias formales y eso sería todo.
No trates de refinar la política. Abrázalo. Déjalo ser.
Puede esperar que el desarrollo impulsado por la prueba de aceptación (ATDD, por sus siglas en inglés) conduzca a "las pruebas de aceptación sean escritas y acordadas por todo el equipo antes de que comience el desarrollo". Pero debes reflejar la realidad de que cualquier cosa escrita con anticipación es engañosa en el mejor de los casos y negociable en el peor.
La premisa detrás de todos los métodos ágiles es que solo puedes aceptar acceder a algo liberable. Todo después de eso es negociable.
La premisa detrás de todas las pruebas primero (TDD, ATDD, o cualquier otra cosa) es que una prueba es un acuerdo férreo. Excepto que no lo es. Con cualquier método TDD (o ATDD) puede estar de acuerdo, en principio, con los resultados de la prueba, pero realmente no ha aceptado la prueba en sí .
Puede surgir que la prueba no se pueda escribir fácilmente. O peor, no se puede escribir en absoluto. Puede aceptar resultados que parezcan verificables, pero que estén mal definidos. ¿Ahora que? Estas son cosas que no puede saber hasta que comience el desarrollo y llegue a los detalles.
Todas las pruebas son importantes. Y ningún tipo particular de prueba puede ser un superconjunto o subconjunto de cualquier otra prueba de tipo. Siempre se superponen parcialmente conjuntos. Intentar combinar para, de alguna manera, ahorrar algo de trabajo es probable que sea una pérdida de tiempo.
Más pruebas son mejores que cualquier otra cosa. La unión de todas las pruebas tiene más valor que intentar forzar una relación subconjunto-superconjunto entre las pruebas.
¿Eres para uno o para el otro? ¿O ambos?
Mi comprensión es pruebas unitarias:
- validar el sistema desde el punto de vista del desarrollador
- ayudar a los desarrolladores a practicar TDD
- mantener el código modular
- ayudar a detectar errores a bajos niveles de granularidad
Prueba de aceptacion:
- validar el sistema desde el punto de vista empresarial y QC / QA
- tienden a ser de alto nivel, ya que a menudo las escriben personas que no están familiarizadas con el funcionamiento interno del código
Siento que ambos son necesarios. Sin embargo, para minimizar el trabajo redundante, ¿es una buena idea intentar incorporar pruebas unitarias en las pruebas de aceptación? En otras palabras, haz que el último llame al primero. ¿Tiene sentido ir en la dirección opuesta?
¿Cuáles son sus pensamientos en general en las pruebas unitarias frente a las pruebas de aceptación, y cómo gestionarlos en relación el uno con el otro?
Como resumen todo lo anterior,
- Las pruebas de aceptación aseguran que estás construyendo lo correcto
- Las pruebas unitarias se aseguran de que estás construyendo bien las cosas
Estas son solo mi opinión personal sobre el tema de algunos tipos de pruebas:
Sin embargo, para minimizar el trabajo redundante, ¿es una buena idea intentar incorporar pruebas unitarias en las pruebas de aceptación?
Me gustaría secundar a S. Lott en este punto y agregar que aquí existe el peligro de que las pruebas de la unidad se manipulen hasta cierto punto y que algunos errores pasen. Por ejemplo, en un menú desplegable, alguien puede probar algunos estados, pero probablemente no todos, donde un verificador puede usar datos diferentes para descubrir un error potencial.
En otras palabras, haz que el último llame al primero. ¿Tiene sentido ir en la dirección opuesta?
Tendría cuidado de alguna vez unirlos. Las pruebas unitarias representan pruebas de los bits más pequeños de funcionalidad, a menudo tan pequeños que un usuario final no entendería que puede haber cientos de pruebas solo para obtener un formulario web para ingresar datos en un sistema CRM. Las pruebas de aceptación son más acerca de lo que el usuario de la aplicación quiere, que puede ser más subjetivo, por ejemplo, "¿Esto se ve bonito?" versus "¿Esto se ve bien?" No puede haber esa marca de "lo suficientemente bueno" con las pruebas de aceptación que no estoy seguro de que funcione con las pruebas unitarias. En general, si una prueba de unidad falla, entonces alguien tiene que decidir si corregir el código o eliminar la prueba ya que cada una puede ser una buena opción dependiendo de las circunstancias.
¿Cuáles son sus pensamientos en general en las pruebas unitarias frente a las pruebas de aceptación, y cómo gestionarlos en relación el uno con el otro?
Las pruebas unitarias consisten en verificar las piezas de código más simples. Puede haber pruebas de integración pero este es un nivel más alto ya que una vez que se revisan todas las piezas pequeñas, la combinación de las piezas funciona juntas, por ejemplo, hubo dibujos animados de los sábados por la mañana que crecí con juguetes que se podían armar como "Voltron" o varios Transformers como los Constructicons que formaron Devastator. Las pruebas de aceptación generalmente son desde la perspectiva del usuario final de "¿Puedo hacer X con la aplicación ahora?" teniendo una respuesta de "Sí" antes de que algo salga por la puerta. Mientras que algunos casos de error pueden ser verificados en una prueba de aceptación, no es común hacer una prueba exhaustiva de cada combinación posible que uno podría ingresar en una aplicación. Sin embargo, las pruebas unitarias pueden cubrir las condiciones de contorno y algunos otros casos similares al azar.
Las pruebas de aceptación e integración le indican si su código está funcionando y completo; las pruebas unitarias te dicen dónde está fallando.
Si has hecho un buen trabajo con las pruebas de aceptación e integración, y están aprobando, tu código implementará toda la funcionalidad que se supone que debe funcionar, y está funcionando. Es genial saberlo (también es bueno saber que no es así). Pero si no funciona, una prueba de aceptación no le dará mucha información sobre lo que salió mal; dado que prueba muchas unidades de funcionalidad, puede ser una especie de vista panorámica de la falla. Aquí es donde brillan las pruebas unitarias. Las buenas pruebas de unidad te dicen exactamente qué salió mal, con exactamente qué parte de tu código. Es más difícil saber si ha escrito suficientes pruebas unitarias que las pruebas de aceptación, pero cuando tiene una prueba de aceptación fallida sin la correspondiente prueba unitaria defectuosa, es hora de escribir esa prueba unitaria.
Eso es todo desde la perspectiva de la prueba. Y, por supuesto, TDD no es (y ATDD no lo es) sobre las pruebas. Con respecto a la conducción de su diseño, las pruebas de aceptación le brindan una hoja de ruta amplia ("aquí es donde desea ir") mientras que las pruebas de unidad lo llevan a la siguiente intersección ("gire a la izquierda"). Ambos son valiosos en este sentido y, de nuevo, su valor se complementan entre sí.
No confundirlos; no los descefine Las pruebas unitarias, en particular, no deben depender de ninguna otra cosa, y sería un error restringir las pruebas unitarias haciendo que la prueba de aceptación dependa de ellas. Por supuesto, pueden compartir algún código de marco, pero deben ser independientes.
Pruebas unitarias: mi función específica hace lo que se supone que debe hacer, nada más y nada menos.
Prueba de aceptación: mi aplicación hace lo que se supone que debe hacer.
Ejemplo: aplicación para calcular raíces de funciones cuadráticas. Toma entradas de a, b y c, devuelve las raíces x1 y x2. Esta aplicación está construida por funciones que escribo para agregar dos números, restar dos números, multiplicar dos números, dividir dos números y tomar la raíz cuadrada de dos números.
Pruebas unitarias: compruebe que las funciones de dividir y multiplicar funcionen correctamente, mi raíz cuadrada funciona correctamente, agregar y restar trabajo correctamente.
Pruebas de aceptación: compruebe que mi aplicación calcula las raíces de las funciones cuadráticas.
Como toda mi aplicación es calcular raíces, no debería tener una prueba unitaria que también calcule las raíces porque no hay una función individual que lo haga.