Escribiendo tests legibles
Si es difícil, aunque cada vez menos, encontrar desarrolladores que escriban test cómo parte del desarrollo, aun es más difícil encontrar desarrolladores que escriban los test con al menos el mismo cariño que escriben el resto.
Los test es código igualmente y tenemos el mismo deber de cuidarlo porque tendremos que mantenerlos a lo largo del tiempo.
Nombre del test
El naming en el desarrollo de software es de las cosas más difíciles porque que genera mucha controversia cuando estas dentro de un equipo. Para mí los punto clave son estos:
-
debe explicar lo que hace, parece sencillo pero no lo es. Generalmente los desarrolladores tenemos el foco en las tripas de lo que se debe probar y acabamos contaminando el nombre del test con palabras o conceptos que para nada tienen que ver con lo que queremos probar en el test y a alguien que no conozca las tripas no debe importarle.
-
nomenclatura, no dediques excesivo tiempo a establecer nomenclaturas, todo evoluciona y nuestro conocimiento también. En los proyectos suelen participar varias personas, es complicado que todos los test sigan una misma nomenclatura, ser exacto en la definición de cómo debe de ser el nombre de un test para mi es lo de menos.
No hay porque utilizar un patrón de naming concreto, existe Given When Then y otros. Hay gente que separa ciertas partes del nombre con underscore. Al final lo mejor es utilizar la estrategia con la que tú y tu equipo os sintáis más cómodos pero sin dedicarle excesivo tiempo y asumiendo que evolucionará. -
explicar precondiciones, es importante que el nombre del test explique las precondiciones al realizar en el test, el contexto es una parte fundamental del test y debe aparecer en el nombre de algún modo. Dos mismas pruebas con precondiciones diferentes aunque mismo resultado, son dos test distintos. Por lo tanto deben ser dos nombres distintos. Por ejemplo una precondición puede ser que la base de datos esta vacía.
-
seguir un orden, es más natural si el nombre describe lo que va a hacer y en el orden que lo hace. Para esto ayuda bastante el patrón Given When Then, por ejemplo se entiende bien nombres de tests como
GivenAEmptyDataSource_WhenLoadLastSales_ThenShowNoSalesMessage
Cuerpo del test
El cuerpo del test como a mi me parece que se entiende mejor es si es pequeño. Esto no quiere decir que solo podamos escribir test si son simples, sino que a medida que escribamos test más complejos o se vaya complicando uno que empezó siendo simple, mantengamos el método original pequeño y llamemos a otros métodos dándoles también nombres semánticos.
Por ejemplo suelo utilizar el patrón Given When Then en los test de aceptación y dividir el test principal en llamadas a unos métodos que componen cada una de las partes del patrón.
[Fact]
public void
GivenAEmptyDataSource_WhenLoadLastSales_ThenShowNoSalesMessage()
{
GivenAEmptyDataSource();
WhenLoadLastSales();
ThenShowNoSalesMessage();
}
private void GivenAEmptyDataSource()
{
}
private void WhenLoadLastSales()
{
}
private void ThenShowNoSalesMessage()
{
}
Beneficios de escribir test legibles
Existen multitud de beneficios que se producen al escribir test legibles, cito algunos:
- que tus compañeros lo entiendan, esto es lo más importante, ya lo he dicho en otros artículos. Lo más importante es escribir código para que lo entiendan tus compañeros no el compilador.
- documentación, unos tests bien escritos pueden servir de documentación para un compañero nuevo o para ti mismo en el futuro.
- poder hacer pruebas de acceso, no hay nada mejor que explicar algo que demostrándolo. Hay empresas donde las pruebas de acceso se basan en unos test que explican lo que una clase debe de hacer y tienes que realizar el código que validan esos tests. ¿como vas a realizar bien el ejercicio si no se entienden los tests?, en un escenario como este se ve claramente la importancia de escribir test legibles y limpios.
- Vas a tener más claro qué debes construir, si sigues TDD y escribes el test antes, al hacerlo lo más legible posible, tu vas a tener mucho más claro también como se debe comportar lo que vas a crear y por lo tanto lo vas a crear mejor.
Curso y artículos relacionados
Conclusiones
El código de los test es tan importante o más que el resto. Por lo tanto es necesario cuidarlo, hacerlo limpio y legible porque nos puede dar muchos beneficios.