Es habitual en la vida de un programador que nos asignen proyectos en los que tengamos que tocar código que no hemos realizado nosotros, sobre proyectos que no hemos creado des del principio. Cuando finalizamos estos desarrollos, una parte crucial es probar que nuestro código no ha “roto” las funcionalidades que ya ofrecía el proyecto en cuestión. Para ellos solemos utilizar los Unit Test que ofrece el proyecto.
¿Qué nos encontramos habitualmente?
Es común encontrar clases de Unit Test que no describen correctamente el sistema que se está probando (System Under Test). Este problema ocurre al nombrar las clases y los métodos de prueba. Una vez abrimos el proyecto de Unit Test de la aplicación, nos podemos encontrar algo como este ejemplo:
Viendo el ejemplo anterior no es fácil identificar que funcionalidad se encarga de probar cada clase. Este problema también está presente en el nombre de los test, tal como vemos a continuación:
¿Qué nombre le pongo a una clase Unit Test?
Para cada clase que quiero realizar test creo una carpeta con el siguiente patrón:
Given_[NombreClase]
Dentro de la carpeta crearé tantas clases como métodos o funcionalidades quiera probar. El patrón seria el siguiente:
_ When_ [NombreDelMetodo/Funcionalidad]_ Is_ Called
Podemos ver esta estructura en la imagen siguiente:
Podemos comprobar que en este proyecto de test estamos probando dos servicios: MyExampleService y MyAnotherExpampleService. Para el servicio MyAnotherExampleService vamos a probar cuando los métodos ExampleMethod y ExampleMethodTwo son invocados.
¿Qué nombre le pongo a los Unit Tests?
Para cada Unit Test seguimos el siguiente patrón:
_ With_ [SomeScenary]_[SomeResult], donde
[SomeScenary] -> escenario propuesto para la prueba. La respuesta a la pregunta ¿Qué voy a probar?. Recordad que cada prueba unitária debe atacar solo un escenario.
[SomeResult] -> respuesta esperada del escenario. La respuesta a la pregunta ¿Qué espero obtener?
Vemos un ejemplo en la imagen siguiente:
Conclusión
Es muy importante realizar pruebas unitarias dentro de un proyecto. Pero también es muy importante hacerlas legibles pensando en nombres claros y concisos para ayudar a otros desarrolladores a entender que es lo que se está probando.
Se debe tener en cuenta que un Unit Test solo debe probar una funcionalidad. Si la prueba se complica debido a los distintos flujos que puede llegar tener quiere decir que el método bajo prueba no cumple el principio de responsabilidad única.
Siguiendo el patrón marcado anteriormente, podemos leer de esta manera los test:
- Given_MyAnotherExampleService_When_ExampleMethod_Is_Called_With_NullParameter_Throw_NullArgumentException
Si realizamos una ejecución de los test y nos fallara este, sabríamos perfectamente que es lo que está probando, dado que la explicación está en el nombre.
Esta es una manera de nombrar los test, pero no la única. Cada uno puede realizar su metodología siempre y cuando quede claro lo que se está probando.
