Tema 2.1 - Principios FIRST

Los principios FIRST fueron definidos por Robert Cecil Martin y habla de ellos en su libro “Clean Code” y el cual es reconocido por ser uno de los escritores del manifiesto ágil.

FIRST es al acrónimo de las cinco características que deben tener nuestras pruebas unitarias para poder ser consideradas pruebas de calidad. Aunque FIRST fue concebido para pruebas unitarias, esto no quiere decir que no puedan ser llevados al mundo de las pruebas funcionales automatizadas. Ahora veamos en detalle cada uno de los principios:

• Fast (rápido): Una de las ventajas que ofrecen las pruebas unitarias es la posibilidad de ejecutar un gran número de ellas en cuestión de segundos. Todas las pruebas de nuestro proyecto, o al menos las relacionadas con el código, deberían poder ejecutarse en cuestión de segundos, lo que facilita la ejecución frecuente de las pruebas y la detección temprana de bugs. Debido a la rapidez con la que este tipo de pruebas se ejecuta, es posible ejecutar todas las pruebas unitarias cada vez que se haga un push a una rama. En cuanto a pruebas unitarias se refiere, una alta cobertura es muy importante, lo que hace que un proyecto tenga un gran número de pruebas unitarias; es por ello que esta propiedad es muy importante.

• Independent (Independiente): Sin importar la cantidad de pruebas unitarias que se tengan, todas ellas deben ser independientes de las otras. No pueden existir dependencias entre ellas. Un ejemplo de esto puede ser cuando una prueba falla porque una anteriormente ejecutada falló o por el orden en el que se han ejecutado. El resultado de una prueba no debe verse alterado por la ejecución de otras pruebas o por el orden en el que son ejecutadas.

• Repeatable (Repetible): En mi máquina si corre! el resultado de las pruebas debe ser independiente del servidor que se ejecute, de la configuración de usuario, hora de ejecución, etc.

• Self-Validating (Auto evaluable): Uno de los puntos a favor de pruebas automatizadas es que pueden ser 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 puede pasar mientras se están realizando otras tareas, 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. ( Las pruebas deben tener un booleano con resultado. De tal manera, el resultado siempre debe ser “true” o “false”, lo cual hace que la prueba se evalúe a sí misma y el resultado sea fácilmente legible).

• Timely (oportuno): Las pruebas deberían ejecutarse antes de empezar a desarrollar el código, ya que no podemos realizar pruebas de regresión en fase de desarrollo, además que más adelante surgen otras tareas que son excusa para darles prioridad. Esta propiedad va muy de la mano con la metodología de desarrollo TDD.