java - unitarias - Prueba de unidad vs Prueba de integración en desarrollo web
que es una prueba unitaria java (3)
Esta es una muy buena pregunta, y una que más desarrolladores deberían preguntarse .
No creo que esto solo se aplique al desarrollo web, pero creo que es un buen ejemplo para basar la discusión.
Al decidir sobre sus estrategias de prueba, los puntos que planteó son muy válidos. En un mundo comercial, el costo (en términos de tiempo) es probablemente el factor más importante. Siempre sigo algunas reglas simples para mantener realistas mis estrategias de prueba.
- Prueba de unidad importante, "libs" comprobables de unidad (autenticación, facturación, abstracciones de servicio, etc.)
- Modelos de prueba unitaria, suponiendo que tenga alguno, cuando sea posible (¡y realmente debería ser posible!)
- Prueba de integración puntos finales importantes de su aplicación (depende totalmente de la aplicación)
Una vez que haya definido estos tres puntos, dadas sus limitaciones de costos, podría continuar probando cualquier otra cosa que tenga sentido, de la manera que tiene sentido.
Las pruebas de unidad y las pruebas de integración no se excluyen mutuamente, y a menos que esté construyendo una biblioteca comprobable por unidad, debe hacer ambas cosas.
Me gustaría preguntar sobre el uso de la prueba unitaria en el desarrollo web. La idea de la prueba unitaria es excelente, pero ¿realmente aporta valor en el contexto de la aplicación web? La segunda parte de mi pregunta es sobre TDD. Si se crea una prueba de integración antes del código real, ¿este enfoque puede denominarse "Desarrollo guiado por pruebas"?
1. Suposiciones
Según la definición, la prueba de unidad debe probar el código en una sola capa de servicio. Si una prueba prueba código a través de múltiples capas tenemos una prueba de integración.
2. Argumento
2.1 No hay algoritmos
No hay muchos algoritmos en una aplicación web. No es como construir un motor de Física 3D donde cada método hace algo desafiante y difícil de depurar. La aplicación web es principalmente sobre integración y generación de HTML.
Los mayores desafíos para una aplicación web son: - código limpio (problema universal para cualquier software pero no comprobable) - consistencia de los datos - integración (lenguaje de programación, sistema de archivos, archivos de configuración, servidor web, sistemas de almacenamiento en caché, base de datos, motor de búsqueda, API externas) - Todos esos sistemas tienen que trabajar juntos a petición.
Si desea crear una prueba de unidad para cada clase en una aplicación web, estará probando (en la mayoría de los casos): relleno de matrices, concatenaciones de cadenas y funciones nativas de idiomas.
Costo 2.2
Solo porque una aplicación web tiene que ver con la integración, siempre hay múltiples dependencias. Tienes que burlarte de muchas clases diferentes y escribir incluso una pequeña prueba podría ser realmente un gran trabajo. Lo que es peor, no es solo acerca de la prueba. El software necesita ser comprobable. Significa que uno tiene que poder inyectar dependencias en casi todas las clases. No siempre es posible inyectar dependencias sin crear una capa adicional entre dos clases (o sistemas). Complica el código y hace que sea más costoso trabajar con él.
3. Prueba de integración
Si el desarrollo web tiene que ver con la integración, ¿por qué no probarlo? Hay pocos argumentos en contra.
3.1 La prueba de integración dice "algo está roto" pero no dice dónde
Esto realmente se reduce a: ¿Cuánto tiempo se tarda en encontrar un error cuando falla una prueba de integración en comparación con el tiempo requerido para hacer el código "UnitTestable" y más complicado (supongo que esto es subjetivo)? En mi experiencia, nunca tomó mucho tiempo encontrar la fuente de un problema.
3.2 Puede ejecutar la prueba de unidad en cualquier entorno, es difícil hacerlo con una prueba de integración
Sí, si desea ejecutar la prueba de integración sin una base de datos. Por lo general hay una base de datos. Siempre que opere con datos fijos y limpie después de cada prueba, entonces debería estar bien. Las bases de datos transaccionales son perfectas para esta tarea. Abrir transacción, insertar datos, probar, deshacer.
3.3 Las pruebas de integración son difíciles de mantener
No puedo comentar sobre eso porque todas mis pruebas funcionan bien y nunca tuve problemas con eso.
4. ¡Crea buenas pruebas unitarias!
Todo el argumento puede ser atacado con "Si creas tu Prueba de Unidad correctamente, entonces no tienes ningún problema". ¿No puede ser lo mismo con las pruebas de integración? Si es más fácil crear una prueba de integración, ¿por qué no seguirla y hacerlo bien?
No me malinterpretes, no estoy en contra de Unit Test. Es una idea perfecta y la recomiendo a todo el mundo. Estoy tratando de entender: ¿realmente encaja con el desarrollo web? Me gustaría escuchar tus opiniones y experiencias.
La prueba de integración tarda más tiempo en ejecutarse en comparación con la prueba unitaria.
"... todo sobre la integración siempre hay múltiples dependencias" -> si está codificando en una unidad dependiente sin completar las otras, entonces no puede hacer la prueba de integración todavía. Si desea asegurarse de que su código esté funcionando en este punto, puede hacer pruebas de unidad.
Si cada miembro de su equipo está desarrollando su propia unidad dependiente, aún no pueden realizar la prueba de integración porque las unidades requeridas aún están siendo desarrolladas por otros. Pero al menos pueden asegurarse de que su código esté funcionando si realizan pruebas de unidad antes de comprometerse con el repositorio.
La respuesta corta es sí. Las pruebas unitarias son valiosas como las pruebas de integración. Personalmente, no soy tan bueno para hacer TDD, pero lo que he notado es que mejora mucho el diseño porque tengo que pensar primero y luego codificar. Eso es invaluable, al menos, para mí, pero también requiere mucho acostumbrarse. Creo que esta es la razón principal por la que es tan mal entendida.
Vamos a repasar tus puntos:
No Algoritmos (pero lo que quieres decir es pocos):
Bueno, como se indica en los comentarios, eso depende de la aplicación. Esto en realidad no tiene nada que ver con TDD. Tener pocos algoritmos no es un argumento para no probarlos. Puede tener varios casos diferentes con muchos estados diferentes. ¿No sería bueno saber que funcionan según lo previsto?
Costo
Seguro que costará, y si se trata de un proyecto pequeño, es posible que no obtenga ningún valor de TDD si usted o sus desarrolladores son nuevos en esto. Entonces, de nuevo, un proyecto pequeño podría ser justo lo que necesita para comenzar con él, por lo que está preparado para el próximo proyecto más grande. Este es un cálculo que debes hacer tú mismo. Somos programadores, no economistas.
Examen de integración
Prueba eso también!
La prueba de integración dice "algo está roto" pero no dice dónde
Lo siento pero no entiendo este.
Difícil de mantener
Si es difícil mantenerlo, lo estás haciendo mal. Escriba la prueba primero, cambie la prueba antes de la implementación, cuando cambie el código. Las pruebas fallidas durante el desarrollo son una necesidad para TDD. En realidad no me cites en eso, es solo mi comprensión limitada de TDD.
Me parece que this es una muy buena cita sobre pruebas unitarias
Las pruebas unitarias deben ser prescriptivas, no descriptivas. En otras palabras, las pruebas unitarias deben definir qué se supone que debe hacer su código, no ilustrar después de lo que hace su código.
Todo se reduce a que las pruebas de integración y las pruebas unitarias son dos cosas diferentes. TDD es una metodología para el desarrollo, las pruebas de integración es más una validación de la aplicación que funciona como se espera desde un punto de vista de los usuarios.
Editar La wiki de la comunidad dice esto acerca de las pruebas de integración:
En una prueba de integración, todos los módulos de entrada son módulos que ya han sido probados por unidades. Estos módulos se agrupan en agregados más grandes y las pruebas de integración (definidas en un plan de prueba de integración) se aplican a esos agregados. Después de una prueba de integración exitosa, el sistema integrado está listo para la prueba del sistema.
Así que, en realidad, mi comprensión de qué son las integration testing fue errónea desde el principio, pero no creo que mi respuesta esté demasiado alejada, excepto en el último párrafo.