Hace un par de semana realizamos un artículo con definiciones referentes al mucho del testing, hoy vamos a extender ese post con nuevas definiciones. Hemos hablado de TDD, de PHPUnit y creo que la mejor forma de afianzar conceptos es definirlos de una manera simple y práctica.
Así que allá vamos:
Test de aceptación: son una serie de pruebas para verificar que el software cumple los requisitos del cliente. Normalmente se ejecutan en un entorno lo más cercano a producción como sea posible.
Assert: Son declaraciones para chequear el funcionamiento del software. En las librerías de pruebas existen muchas variantes como assertTrue, assertEqual,…
Pruebas de comportamiento (Beharviour test) : Es una técnica que sirve para incorporar a los tests doubles dentro de su contexto.
<<La idea central es reemplazar la terminología centrada en el desarrollador (suite test case, assert, etc.) con un lenguaje cercano, en el que personal no técnico pueda entender.>>
Veamos un ejemplo (Wikipedia):
Story: Las devoluciones van al stock
Con el fin de hacer un seguimiento del stock
Como propietario de una tienda
Quiero añadir artículos de nuevo a stock
Cuando sean devueltos.
Escenario1: Los artículos devueltos deber volver a stock
Teniendo en cuenta que un cliente me compró previamente un jersey negro
y actualmente tengo en stock 3 jerseys negros
Cuando un cliente pide el reembolso de un jersey negro
Entonces debería tener cuatro jerseys negros en stock
Test caja negra: Test en los cuales no se conoce o se evita conocer el funcionamiento interno del software, normalmente probando la interfaz software.
Test Caja blanca: Es un técnica de pruebas en la que la persona que esta probando conoce el código o tiene acceso a este.
Test valores frontera (boundary-value testing): Son pruebas que nos ayudan a cazar GAPs (huecos en el software) Se comprueban las entradas alrededor de ciertos limites. En caso de enteros serían 0, -1, -0, MAX_INT, MIN_INT.
Dummy: Es un tipo de test double que se utiliza para rellenar los parámetros requeridos.
Fake: Son un tipo de test double que implementan una funcionalidad requerida para las pruebas, pero que esta funcionalidad no sirva para producción real. Por ejemplo utilizar una base de datos en memoria (Hypersoncic por ejemplo) para que poder probar más rápido.
Fixture: Son los requisitos (ambiente) que deben establecerse antes de ejecutar la prueba. Por lo general consiste en la creación de los tests doubles, o de datos falsos en la base de datos, o incluso una cierta estructura de directorios.
Pruebas funcionales: Son pruebas de alto nivel para verificar los requisitos de negocio. Se basan o están relacionadas con las historias de usuario.
Pruebas de integración: Son pruebas para verificar que un conjunto de módulos funcionan juntos correctamente
Mock: Es un tipo de test double. Lo que se hace es crear una maqueta, un objeto falso que al llamarlo devuelve una respuesta predefinida. Por ejemplo, creamos un Mock para usuario que responda a todas las llamadas de la interfaz usuario, pero sin implementar dicha interfaz, así podríamos utilizar un objeto tipo usuario para probar otra parte de nuestra aplicación.
Pruebas de regresión: Normalmente después de un cambio software, por ejemplo una nueva funcionalidad o la reparación de un bug, se realizan una serie de test para comprobar que el resto de funcionalidades de la aplicación no se ha visto afectada por este cambio.
Cobertura de la prueba (Test coverage): Cualquier tipo de métrica que intenta estimar la probabilidad de un comportamiento aun no cubierto por las pruebas. Normalmente son técnicas que aseguran que se han cubierto todas las ramas de un if durante una batería de test.
Jesús L.C. - Apuntes de un aprendiz 