7.1 Data pools
(Free photo by Mika Baumeister on unsplash)
Dado que el espacio de posibles entradas y posibles estados en una aplicación de pruebas es amplio, es necesario probar el mayor número de entradas posible con el fin de explorar el mayor conjunto de estados que se pueda. Manualmente esto es un dolor de cabeza, sin embargo, al hacer uso de pruebas automatizadas se puede sacar provecho de la disponibilidad de horas máquina para ejecutar las pruebas con la mayor cantidad posible de combinaciones de datos. Una forma de hacer esto en el caso de pruebas codificadas con APIs es hacer uso de data pools.
Un data pool es un conjunto de datos usado como repositorio de las entradas a ser utilizadas en pruebas. Desde el punto de vista del propósito, los data pools pueden ser generícos o específicos para una funcionalidad en particular. Por ejemplo, un data pool genérico tiene datos organizados por categorías de datos(e.g., correos, nombres, teléfonos, cuentas bancarias, transacciones monetarias, países, etc.) que pueden ser usadas en múltiples pruebas y aplicaciones; en un data pool específico se tienen tuplas de datos que coinciden con un escenario particular de una aplicación (e.g., tuplas de datos para registro de usuario en facebook).
Desde el punto de vista de la generación, los data pools pueden ser definidos a-priori (de forma manual o asistida), aumentados con base en la exploración del sistema bajo pruebas, o generados en tiempo de ejecución con base en funciones. El uso de data pools predefinidos, obedece al hecho que estos ya existan dentro de las organizaciones, o en el dominio público (e.g., correos válidos, países) o dentro del equipo de pruebas, o a que se definieron previamente como parte de criterios de aceptación durante el proceso de desarrollo.
Data pools a-priori. En el caso de pruebas E2E implementadas con Gherkin, se pueden definir data pools para cada scenario usando "Data Tables" y "Scenario outlines". En el caso de pruebas con APIs de automatización se tiene más libertad de uso de las estructuras existentes en la API o el lenguaje de programación para cargar el datapool de un archivo, una base de datos, una estructura, etc. Por ejemplo, JUnit tiene una funcionalidad para definición de datapools y ejecución de pruebas; esta funcionalidad se conoce como "Parametrized tests". Otras herramientas como mockaroo permiten generan archivos de datos a-priori.
Revisa los siguientes artículos para entender el uso de "data tables" y "outlines" en Gherkin: Working with Cucumber Data table, Cucumber and Scenario Outline
Generación dinámica de data pools. Para efectos de definición de data pools, podemos hacer uso de los rippers y random monkeys para ir identificando (durante la exploración) tipos de datos y las combinaciones que activan estados en la app bajo pruebas. Dado un estado A y una tupla de datos que al ser ingresada lleva la aplicación al estado B, esta tupla se puede almacenar para ir construyendo un data pool. El data pool construido durante la exploración sistemática (o aleatoria), puede servir para identificar patrones entre las tuplas (y datos de las tupla),para de forma posterior, aumentar el data pool con más tuplas que se generan utilizando los patrones, relaciones, distribuciones encontrados (estos se implementan en funciones generadoras).
Otra estrategia para generación dinámica es el uso de funciones generadoras o frameworks de soporte en tiempo de ejecución. Un ejemplo de estos frameworks es PODAM, que permite auto-llenar objetos planos de Java con datos. Mockaroo también se puede usar en tiempo de ejecución haciendo uso de una API rest.