Guía de terminología Testing

Como no morir abrumado por palabras o frases que suenan a chino relacionadas con el testing.

Unit Test

Es cuando testeas un trozo de funcionalidad. No tiene por que ser ni siquiera un método. Obviamente no implica en ningún caso interacción con bbdd o api de terceros u otras clases. Simplemente una funcionalidad que tiene una entrada, o no, y devuelve una salida.

De hecho uno puede llegar a pensar que tiene que haber un test para cada método. Pero el unit test es aún a más bajo nivel. Puede que testear el método de una clase implique crear 5 tests. Es importante que el test pruebe una sola cosa y sea lo más conciso posible.

Mock

Mock es un objeto ficticio. Esto se usa en los tests para probar una funcionalidad sin ejecutarla. Por ejemplo se podría “mockear” un método que crea un registro en base de datos. Realmente no inserta nada, simplemente nos aseguramos que se llama ese método.

La idea detrás de esto es la de evitar al máximo las dependencias. Si para testear según que cosas complejas hay que inicializar una api, una bbdd o lo que sea, mejor tirar de objetos ficticios.

Con el mock digamos que tenemos una expectación a que algo haya pasado.

Stub

Este es complejo de entender. En principio parece ser que es un sustituto de cierta funcionalidad que devuelve el mismo resultado. La diferencia con los mocks puede parecer bastante sutil pero realmente es clara. El mock no hace nada, el stub devuelve un valor.

Dummy

Normalmente hace referencia a algún tipo de estructura, normalmente una clase, que sigue un contrato (extiende de una interfaz) que se crea solamente para poder pasar el test.

Por ejemplo. Si tenemos una clase que gestiona el login de los usuarios. Cuando testeamos, en lugar de usar esa clase, utilizamos una clase “dummy”, que sigue el mismo contrato (mismos métodos, nombres, entradas, salidas) sin preocuparnos demasiado por lo que hace. El único objetivo es pasar el test.

Factories

Estructura para crear rápidamente objetos o datos con los que interactúan los tests. No tiene que ver exactamente con el patrón Factory pero está relacionado

Tests de integración

En ellos testeamos a un nivel superior que en los unitarios. Aquí se testean las relaciones entre distintos componentes, los mensajes que se comunican entre ellos y los resultados que nos dan. Digamos que aquí probamos varias funcionalidades conectadas entre ellas.

Behaviour Driven Development

Es una metodología de testing pero más orientada a testear distintas funcionalidades. No se limita a testear una funcionalidad concreta, o su estado. Además la definición de los tests, llamadas features, se basa a partir de la “conversación” con los distintos participantes del proceso de software. Estas features describen el comportamiento que debe tener y ahonda en posibles escenarios que deben testearse para que sea correcta.

Tests de aceptación

Estos tests son los que definen los propios usuarios o peticionarios de una feature de un proyecto. Es lo que según ellos debe hacer esa nueva feature.  Los tests de aceptación serian la capa más alta de todos los posibles tests. La que realmente si ven los usuarios.

Tests de regresión

Son aquellos tests que creamos para reproducir un bug encontrado en producción.