"Escribe pruebas para la gente".

Consejos de programación para #programadores.

-----------------------------------------------------------------------

LIBRO: 97 COSAS QUE TODO PROGRAMADOR NECESITA SABER.

POR: KEVLIN HENNEY.

-----------------------------------------------------------------------

94° "ESCRIBE PRUEBAS PARA LA GENTE":

Estás escribiendo pruebas automatizadas para parte o toda tu producción de código. ¡Felicidades!. ¿Estás escribiendo tus pruebas antes de escribir el código?.¡¡Aun mejor!!. El sólo hecho de hacer ésto, lo convierte en uno de los primeros en adoptar la práctica de la ingeniería de software a la vanguardia. ¿Pero estás escribiendo buenos exámenes?, ¿Cómo puedes decir?. Una forma es preguntar: "¿Para quién escribo los exámenes?", si la respuesta es: "Para mí, para ahorrarme el esfuerzo de corregir errores" o "Para el compilador, para que se puede "ejecutar” entonces, lo más probable es que no estés escribiendo las mejores pruebas posibles. Entonces, ¿para quién deberías escribir las pruebas?. Para la persona que intenta entender tu codigo.

Las buenas pruebas actúan como documentación del código que están probando. Ellos describen cómo funciona el código. Para cada escenario de uso, las pruebas deben:

• Describir el contexto, el punto de partida o las condiciones previas que deben cumplirse

• Ilustrar cómo se invoca el software.

• Describir los resultados esperados o condiciones posteriores a ser verificadas.

Diferentes escenarios de uso tendrán versiones ligeramente diferentes de cada uno de estos. La persona que intenta entender tu código debería poder mirar algunas pruebas, y comparando éstas tres partes de las pruebas en cuestión, sea capaz de ver qué causa que el software se comporte de manera diferente. Cada prueba debe ilustrar claramente la relación causa-efecto entre éstas tres partes.

Ésto implica que lo que no es visible en la prueba es tan importante como lo que sí es visible. Demasiado código en la prueba distrae al lector con trivialidades sin importancia. Siempre que sea posible, oculte esas trivialidades detrás de llamadas a métodos significativas: el extracto.

La refactorización de métodos es tu mejor amiga. Y asegúrate de darle a cada prueba un nombre significativo que describe el escenario de uso particular para el lector de prueba.

No es necesario realizar ingeniería inversa en cada prueba para comprender cuáles son los distintos escenarios. Entre ellos, los nombres de la clase de prueba y el método de clase deben incluir al menos el punto de partida y cómo se invoca el software. Éste, permite verificar la cobertura de la prueba mediante un escaneo rápido de los nombres de los métodos. Él también puede ser útil incluir los resultados esperados en los nombres de los métodos de prueba siempre y cuando, ésto no haga que los nombres sean demasiado largos para verlos o leerlos.

También es una buena idea probar tus pruebas. Puedes comprobar que detectan los errores, crees que detectan insertando esos errores en el código de producción (tu propia copia privada que, por supuesto, tirarás a la basura). Asegúrate de que informen errores de una manera útil y significativa. También debe verificar que sus pruebas hablen claramente con una persona que intente comprender tu código. La única manera de hacer ésto es para que alguien que no esté familiarizado con tu código, lea sus pruebas y conteste lo que aprendió. Escuche atentamente lo que ella dice. Si ella no lo hizo entiende algo claramente, probablemente no sea porque no sea muy brillante. Es más probable que no hayas sido muy claro. (¡Continúa e invierte los roles leyendo tus exámenes!).

-Gerard Meszaros-