Como generar "fake data" en nuestros tests de aceptación

En la gran mayoría de nuestros tests necesitamos de forma habitual información de relleno para setear todos los valores demandados en cada paso. Suele ser información obligatoria para poder invocar a los métodos que testeamos, pero tiene una importancia más bien relativa para el resultado final. En cualquier caso, estar siempre pasando valores a piño fijo como prueba o lorem ipsum, no nos beneficia en nada al no poder ver en detalle el efecto producido ante datos de valor variable y más o menos reales (sobretodo cuando estamos actuando desde el interfaz de usuario).

Para este tipo de escenarios, y de forma más concreta para nuestros tests de aceptación que ejercitan el interfaz de usuario de una forma “automatizada”, soluciones como faker pueden hacernos la vida mucho más sencilla.

faker no es más que una API que genera valores “fake” o “dummy” o falsos para nuestra aplicación y que realiza esta generación en base a una serie de entidades de datos que soporta (direcciones, fechas, empresas, teléfonos, …) o simplemente de forma aleatoria (números, letras, palabras, UUIDs, …).

En JavaScript disponemos de un paquete NPM con el que realizar las llamadas y obtener los valores “fake”. Para ello sólo debemos instalarlo ejecutando el siguiente comando:

1
npm install --save-dev faker

Una vez instalado, podemos importar faker en uno de nuestros proyectos y comenzar a recuperar valores de prueba:

1
2
3
4
import faker from 'faker';

let name = faker.name.findName();
let email = faker.internet.email();

Para la lista completa de todas las entidades disponibles y los valores expuestos para cada una, deberemos consultar la documentación del proyecto. En cualquier caso, es sorprendentemente completa.

[TIP]: Nunca utilices librerias de terceros de forma directa en tu código. Crea siempre un “wrapper” que te proteja!!

Como nota final y ya que esta es una librería “no controlada” por nosotros que se va a integrar en nuestro código de test, seguiremos siempre la máxima de hacer un “wrapper” de la libreria y exponer sólo la parte que vamos a utilizar, permitiendo así su sustitución por otra que nos guste más en el futuro o por un doble de test en el caso de ser necesario.

Un ejemplo de este tipo de “wrapper” podría ser el siguiente, en el que podemos ver cómo de una forma semántica exponemos únicamente los métodos de faker que son necesarios:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import faker from 'faker';

faker.locale = 'es';

export default {
getCompanyName: () => faker.company.companyName(),
getCompanyCif: () => faker.random.number(),
getUserMail: () => faker.internet.email(),
getUserPassword: () => faker.internet.password(),
getRoleName: () => faker.name.jobType(),
getWorkCenterName: () => faker.address.streetName(),
getWorkCenterStreetAddress: () => faker.address.streetAddress(),
getWorkCenterZipCode: () => faker.address.zipCode(),
getWorkCenterPhone: () => faker.phone.phoneNumber()
}

Posteriormente, a la hora de usar este “wrapper” en nuestro código de test, sólo tendríamos que importar el módulo creado y llamar los métodos expuestos. A continuación os dejo un ejemplo de cómo hacerlo utilizando nightwatch como herramienta para la creación de tests de aceptación (de ahí la sintaxis especial de los tests definidos):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
import SupportApp from '../src/support';
import fakeData from '../src/fake';

export default {
beforeEach: () => {
name = fakeData.getWorkCenterName();
streetAddress = fakeData.getWorkCenterStreetAddress();
zipCode = fakeData.getWorkCenterZipCode();
phone = fakeData.getWorkCenterPhone();
},

'should be able to create a work center': (client) => {
new SupportApp(client)
.navigateToWorkCentersAdmin()
.addWorkCenter(name, streetAddress, zipCode, phone)
.run();
}
}

Como podéis ver, enfocar nuestros tests de aceptación aprovechando la potencia del patrón Page Object puede ser también muy interesante y semántico … Aunque esa es otra historia :)