Patterns de tests de unidad 1: ¿Como deberían ser nuestros tests de unidad?

¿Cuales son las características deseables en los tests de unidad de un proyecto? Esta es una pregunta difícil de responder porque el conjunto de tests de unidad de un proyecto es muchas cosas a la vez.

Por un lado, funcionan como una herramienta de desarrollo: la ejecutamos y nos informa de errores en nuestro código. En cierta forma son una extensión del compilador y así como este nos informa errores de sintaxis los tests nos informan errores de lógica.
Cuando vemos los tests como una herramienta de desarrollo es fácil ver que ciertas características son deseables: los tests deben ejecutarse rápido, deben cubrir la mayor parte posible del sistema y deben ser confiables (es decir, no deben producir falsos positivos).

Pero, por otro lado, a diferencia del compilador los tests no son una herramienta desarrollada por terceros. Nosotros mismos somos los encargados de desarrollarla y sobre todo de mantenerla. Si, la segunda caracteristica deseable es la mantenibilidad! Por lo tanto todas las buenas prácticas que utilizamos en el desarrollo de software de producción aplican en el desarrollo de tests de unidad. Hay que evitar la duplicación, asegurarnos de que nuestro código sea fácil de leer, de testear y tratar de minimizar la cantidad de lugares en que hacemos llamadas al código que estamos testeando.
Si no nos preocupamos por la calidad del código de nuestros tests es muy fácil que terminemos en la situación de que la mayor parte del costo de hacer un cambio en nuestro sistema sean las modificaciones a los test de unidad.

Finalmente, los tests de unidad tienen una tercera característica deseable que es la de servir como documentación. Muchas veces la forma más fácil y segura (porque está garantizado que los tests están sincronizados con el código) de ver que hace una clase es leer los tests de unidad correspondientes. Sin embargo, para que esto sea posible los tests de unidad tienen que estar escritos de una manera que haga que sea sencillo entender lo que dichos tests esperan de la clase que están verificando.

En proximos posts vamos a contar las buenas prácticas y patterns que permiten lograr estas características deseables de los tests de unidad.