Tests, tests y más tests. Esa es la filosofía que se suele tomar a la hora de desarrollar los tests unitarios para un producto.

No siempre cantidad es calidad. Muchas veces nos ofuscamos en buscar una cobertura alta, sin tener en cuenta la calidad de nuestros tests. Claramente la cobertura de tests es muy importante, pero también lo es la calidad de estos.

Por ello, en este post vamos a hablar del Principio FIRST y de cómo mejorar la calidad de nuestros tests.

Su autor

El principio FIRST fue definido por Robert Cecil Martin en su libro Clean Code. Este autor, entre otras muchas cosas, es conocido por ser uno de los escritores del Agile Manifesto, escrito hace más de 15 años y que a día de hoy se sigue teniendo muy en cuenta a la hora de desarrollar software.

El principio FIRST

FIRST es el acrónimo de las cinco características que deben tener nuestros tests unitarios para ser considerados tests con calidad:

• Fast (rápido)
• Independent (independiente)
• Repeatable (repetible)
• Self-validating (auto evaluable)
• Timely (oportuno)

FAST (rápido)

Una de las ventajas que nos ofrecen los test unitarios es la posibilidad de ejecutar un gran número de tests en cuestión de segundos. Todas las pruebas de nuestro proyecto, o al menos las relacionadas con el código, que estemos desarrollando deberían poder ejecutarse en un abrir y cerrar de ojos.

Esto nos posibilita ejecutar los tests muy frecuentemente y con ello detectar bugs de forma muy rápida y sencilla.

Por ejemplo, podríamos ejecutar todos los tests cada vez que hagamos un push a una rama sin preocuparnos del tiempo de ejecución de este proceso.

Normalmente trabajamos para conseguir una cobertura alta de tests, lo cual provoca que un proyecto llegue a tener un gran número de ellos. Por eso esta propiedad es muy importante.

En caso de aumentar considerablemente el número de tests de un proyecto, el tiempo de ejecución total no debería verse muy afectado.

INDEPENDENT (independiente)

Por muchas pruebas unitarias que tengamos, todas deben de ser independientes de las otras.

En el momento que un test falla por el orden en el que se ha ejecutado, tenemos claro que ese test está mal desarrollado. El resultado no debe verse alterado ejecutando los tests en un orden y otro o incluso de forma independiente.

Esta propiedad no solo debe seguirse por el hecho de que un test deba ser independiente, sino porque también nos ayuda a ganar tiempo en regresiones.

Se puede dar el caso de que un test falle al ejecutar los cientos o miles que tiene el proyecto. En esta situación podríamos debugear de forma más rápida y sencilla si sólo podemos ejecutar el test fallado obteniendo el mismo resultado de ejecutarlo en conjunto.

REPEATABLE (repetible)

¡En mi local no falla. Eso tiene que ser cosa de Jenkins! Es una frase muy escuchada y que se adapta bien a esta característica del principio First.

El resultado de las pruebas debe ser el mismo independientemente del servidor en el que se ejecute. Las pruebas no deben tener dependencias de servidor, configuración de usuario, hora de ejecución…

SELF-VALIDATING (auto evaluable)

Uno de los puntos a favor de pruebas automatizadas es que podemos ejecutarlas simplemente al pulsar un botón o incluso hacer que se ejecuten de forma automática tras otro proceso, como podría ser un push a una rama.

Todo esto podría pasar mientras nosotros estamos realizando otra tarea, sin preocuparos de dicha ejecución.

De nada nos serviría si una vez ejecutadas tuviéramos que estar trasteando ficheros, comprobando valores o realizando otras tareas engorrosas para comprobar el resultado de los tests ejecutados.

En su libro, Robert Cecil Martin nos indica que las pruebas deben tener un booleano con resultado. De tal manera, el resultado siempre debe ser ok o ko, lo cual hace que el test se evalúe a sí mismo y el resultado sea fácilmente legible.

TIMELY (oportuno)

Hacer TDD, hacer BDD, desarrollar las pruebas posteriormente al desarrollo del producto, no desarrollas…

Esta última característica se basa en cuándo deberíamos tener desarrolladas las pruebas, que deben estar desarrolladas lo antes posible y siempre antes de subir código a producción.

A ser posible, las pruebas deben desarrollarse antes de empezar a desarrollar el código de la aplicación (TDD).

Debemos evitar dejarlas para el final por dos simples motivos:

• No podremos realizar pruebas de regresión durante la fase de desarrollo.
• Una vez tenemos el código funcionando se suelen buscar excusas para dedicar el tiempo a otras tareas y no a escribir tests.

Teniendo en cuenta esta propiedad (Timely), podemos decir que un flujo perfecto de trabajo sería:

• Escribir las pruebas.
• Ejecutar las pruebas. Deben fallar, ya que el código a testear no está todavía desarrollado.
• Escribir el código de nuestro producto.
• Ejecutar de nuevo las pruebas. En este caso las pruebas debería de funcionar y darnos un resultado positivo.

¿Cumplen los tests de tu proyecto las características del principio FIRST?

Una vez analizadas las cinco características que lo forman, te invito a analizar si tus pruebas tienen la calidad suficiente basándose en dicho principio.

En caso contrario, te animo a mejorarlas, ya que unas pruebas bien hechas dan un plus de calidad a tu proyecto y, entre otras cosas, ayudan a evitar bugs en producción.

"Preocúpate por la calidad de tus productos, mucha gente no está preparada para la excelencia y sorprenderás” - Steve Jobs