Hispanopedia WikiUn simulador de pruebas es un software utilizado en la automatización de pruebas de software que satisface una dependencia , de modo que la prueba no dependa del código de producción. Un simulador de pruebas proporciona funcionalidad a través de una interfaz que el software bajo prueba no puede distinguir del código de producción.
Un programador generalmente utiliza un doble de prueba para aislar el comportamiento del código que lo consume del resto del código base .
Un código de prueba simulado suele ser una versión simplificada del código de producción y puede incluir funcionalidades específicas para las pruebas.
Los dobles de prueba se utilizan para construir arneses de prueba .
Usos
Se puede utilizar un doble de prueba para simplificar las pruebas, aumentar la velocidad de ejecución o permitir resultados deterministas de una acción.
Por ejemplo, un programa que utiliza un servidor de base de datos es relativamente lento y consume muchos recursos del sistema , lo que dificulta la productividad de las pruebas. Una prueba podría requerir datos de la base de datos que, durante la actividad normal del sistema, cambian con frecuencia, por lo que proporciona resultados no deterministas para cualquier consulta. Un objeto de prueba simulado puede proporcionar un valor estático en lugar de acceder a una base de datos real, evitando así llamadas a la red o al sistema y modificando los datos.
También se puede utilizar un objeto de prueba simulado para probar una parte del sistema que esté lista para ser probada, incluso si sus dependencias no lo están.
Por ejemplo, en un sistema con los módulos Login, Home y User, supongamos que Login está listo para la prueba, pero los otros dos no. Las funciones utilizadas de Home y User se pueden implementar como objetos de prueba para que Login pueda ser probado.
Advertencias
Si bien los objetos de prueba simulados se utilizan a menudo para facilitar las pruebas unitarias , su uso presenta limitaciones, principalmente porque no demuestran que la conectividad real con la base de datos u otros accesos externos funcionen correctamente. Para evitar errores que podrían pasar desapercibidos, se necesitan otras pruebas que instancien el código con las implementaciones "reales" de las interfaces mencionadas anteriormente. Estos riesgos de integración suelen estar cubiertos por pruebas de integración , pruebas de sistema o pruebas de integración de sistemas .
Enfoques de implementación
Al implementar dobles de prueba, el enfoque típico implica dos pasos clave:
- Siempre que se necesite acceso externo en producción, se debe definir una interfaz que describa el acceso disponible. Consulte el principio de inversión de dependencias para obtener más información sobre las ventajas de hacerlo, independientemente del desarrollo guiado por pruebas (TDD).
- La interfaz debe implementarse de dos maneras: una que acceda realmente al proceso externo para su uso en producción, y otra que sea un doble de prueba, normalmente un mock o un fake.
Este enfoque impone una separación comprobable mediante pruebas unitarias y fomenta un diseño de código más modular, comprobable y reutilizable. [ 1 ]
Tipos
Los dobles de prueba se clasifican de muchas maneras.
General
Aunque no es universalmente aceptado, Gerard Meszaros [ 2 ] clasifica a los dobles de prueba como:
- Stub : proporciona entrada estática
- Simulación : verifica la salida mediante expectativas definidas antes de que se ejecuten las pruebas.
- Spy permite configurar la salida de una llamada antes de que se ejecute una prueba y verificar los parámetros de entrada después de que se ejecute la prueba.
- Fake: una implementación relativamente completa que se adapta mejor a las pruebas que la versión de producción (por ejemplo, una base de datos en memoria en lugar de un servidor de base de datos ).
- Valor ficticio: un valor que se requiere para la interfaz probada pero del cual no depende el caso de prueba.
Aunque no existe un estándar abierto para las categorías, Martin Fowler utilizó estos términos en su artículo « Mocks Aren't Stubs » [ 3 ], haciendo referencia al libro de Meszaros. Microsoft también utilizó los mismos términos y definiciones en un artículo titulado « Exploring The Continuum Of Test Doubles » [ 4 ] .
Servicio
Para sistemas de arquitectura orientada a servicios (SOA) y microservicios , los evaluadores utilizan simuladores de prueba que se comunican con el sistema bajo prueba a través de un protocolo de red. [ 5 ] [ 6 ] Estos simuladores de prueba reciben diferentes nombres según los proveedores de herramientas. Un término comúnmente utilizado es virtualización de servicios . Otros nombres utilizados incluyen simulación de API, simulacro de API, [ 7 ] stub HTTP, simulacro HTTP, simulador de prueba por cable. [ 8 ] [ 9 ]
Falso verificado
Un objeto falso verificado es un objeto falso cuyo comportamiento se ha comprobado que coincide con el del objeto real mediante un conjunto de pruebas que se ejecutan tanto en el objeto falso verificado como en la implementación real. [ 10 ]
Véase también
Referencias
- ↑ Fowler, Martin (1999). Refactoring - Improving the design of existing code . Boston: Addison Wesley Longman, Inc. ISBN 0-201-48567-2.
- ↑ Meszaros, Gerard (2007). Patrones de pruebas unitarias: Refactorización de código de prueba . Addison-Wesley. ISBN 978-0-13-149505-0.
- ↑ Fowler, Martin (2007). " Los simulacros no son esbozos " . Recuperado el 29 de diciembre de 2010 .
- ↑ Seemann, Mark (2007). " Explorando el continuo de los dobles de prueba " . Recuperado el 29 de diciembre de 2010 .
- ↑ Clemson, Toby "Estrategias de prueba en una arquitectura de microservicios" , martinfowler.com , 18 de noviembre de 2014. Consultado el 7 de diciembre de 2017.
- ↑ Byars, Brandon. "Testing Microservices with Mountebank", Manning Publications , MEAP comenzó en marzo de 2017. ISBN 9781617294778Consultado el 7 de diciembre de 2017.
- ↑ Bryant, Daniel "Se lanza la herramienta de simulación de API WireMock v2 con coincidencia de solicitudes y gestión de stubs mejoradas" , InfoQ , 16 de agosto de 2016. Recuperado el 7 de diciembre de 2017.
- ↑ ThoughtWorks "Radar tecnológico, herramientas: Mountebank" , ThoughtWorks , noviembre de 2015. Consultado el 7 de diciembre de 2017.
- ↑ Bulaty, Wojciech "Stubbing, Mocking and Service Virtualization Differences for Test and Development Teams" , InfoQ , 19 de febrero de 2016. Consultado el 7 de diciembre de 2017.
- ↑ Turner-Trauring, Itamar (2019). " Pruebas rápidas para servicios lentos: por qué deberías usar falsificaciones verificadas " . Recuperado el 21 de enero de 2019 .
Enlaces externos
Gerard Meszaros:
- Doble de prueba
- Patrones de doble prueba
- Imitaciones, falsificaciones, esbozos y maniquíes
Martin Fowler:
- TestDouble , 17 de enero de 2006
Código abierto:
- ELF Spy - Falsificaciones y espías en C++
- FakeIt - Simulación, falsificación y espionaje en C++
- Google Mock - Simulación en C++
- jMock - Desarrollo guiado por pruebas con simulaciones
- Mockito - Framework de simulación para Java
- unittest.mock - Simulación con Python
- Pruebas de software
- patrones de diseño de software
- proceso de desarrollo de software
