Prueba stub
 | Este artículo necesita citas adicionales para su verificación . ( febrero de 2021 ) |
En la informática de polimorfismo avanzado, los stubs de prueba son programas que simulan los comportamientos de los componentes (o módulos) de software de los que depende un módulo sometido a pruebas. Los talones de prueba proporcionan respuestas almacenadas a las llamadas realizadas durante la prueba, por lo general, no responden en absoluto a nada fuera de lo que está programado para la prueba. [1] Se utilizan principalmente en el enfoque de arriba hacia abajo de las pruebas incrementales . Los talones son programas de computadora que actúan como reemplazo temporal de un módulo de lavabo llamado y dan el mismo resultado que el producto o software real.
Ejemplo
Considere un programa de computadora que consulta una base de datos para obtener la suma del precio total de todos los productos almacenados en la base de datos. En este ejemplo, la consulta es lenta y consume una gran cantidad de recursos del sistema. Esto reduce el número de ejecuciones de prueba por día. En segundo lugar, las pruebas pueden incluir valores fuera de los que se encuentran actualmente en la base de datos. El método (o llamada) utilizado para realizar esto es get_total () . Para propósitos de prueba, el código fuente en get_total () se puede reemplazar temporalmente con una declaración simple que devuelve un valor específico. Este sería un talón de prueba.
Hay varios marcos de prueba disponibles, al igual que software que genera stubs de prueba basados en el código fuente existente y los requisitos de prueba. Los talones y los controladores son dos tipos de arnés de prueba. Los arneses de prueba son la recopilación de software y datos de prueba que se configuran para que uno pueda probar una unidad de programa simulando un conjunto diferente de condiciones, mientras se monitorea el comportamiento y las salidas.
Los stubs y los controladores son módulos ficticios y solo se crean con fines de prueba.
Los stubs se utilizan en el enfoque de prueba de arriba hacia abajo, cuando uno tiene el módulo principal listo para probar, pero los submódulos aún no están listos. Entonces, en un lenguaje simple, los códigos auxiliares son "llamados" programas, que son llamados para probar la funcionalidad del módulo principal.
Por ejemplo, en una situación en la que uno tiene tres módulos diferentes: Inicio de sesión, Inicio, Usuario. Suponga que el módulo de inicio de sesión está listo para la prueba, pero los dos módulos menores Inicio y Usuario, a los que llama el módulo de inicio de sesión, aún no están listos para la prueba. En este momento, se escribe un fragmento de código ficticio, que simula los métodos llamados de Inicio y Usuario. Estas piezas de código ficticias son los stubs.
Por otro lado, los controladores son los que son los programas de "llamada". Los controladores se utilizan en el enfoque de prueba de abajo hacia arriba. Los controladores son un código ficticio, que se utiliza cuando los submódulos están listos pero el módulo principal aún no está listo.
Tomando el mismo ejemplo que el anterior. Suponga que esta vez, los módulos de Usuario y Inicio están listos, pero el módulo de Inicio de sesión no está listo para probar. Ahora, dado que Inicio y Usuario devuelven valores del módulo de inicio de sesión, se escribe una pieza de código ficticia, que simula el módulo de inicio de sesión. Este código ficticio se denomina Driver.
Ver también
Referencias
- ^ Fowler, Martin (2007), Los simulacros no son talones (en línea)
enlaces externos
 | Este artículo relacionado con la programación de computadoras es un fragmento . Puedes ayudar a Wikipedia expandiéndolo . |
