7 Buenas prácticas para tus Unit Tests
Los unit tests son una parte importante del desarrollo de software, pero antes que nada, entendamos que son los Unit Test. Como su nombre lo indica, son tests o pruebas que se hacen especificamente sobre trozos de código para verificar su funcionalidad.
En cada plataforma o lenguaje existen herramientas que te ayudan a escribir estos tests.
Los test siguen una logica:
Given:
- Pre — condiciones para correr los test
- Como el sistema debería estar antes de los test
When
- ¿Qué vamos a probar?
Then
- Post — conditions
- ¿Qué cambios pasaron? ¿Son los esperados?
Ahora, en base a esto, veamos las mejores practicas para escribir tus tests:
1. Nombra bien tus test
Los test siempre tienen un nombre, ya sea el nombre de la función que encapsula el test o la descripción del test. Este nombre debe estar bien descrito y debe ser entendible, nombrar bien un test es tan importar como declarar una variable.
- El nombre debe indicar el proposito o el enfoque del test o el negocio.
- Deben estar escritos en lenguaje natural.
- Ser descriptivos, no preocuparse por la longitud del nombre.
- De preferencia, Empezar con el nombre de la función que se desea testear.
Nombrar variables o funciones es complicado, pero es mejor darse el tiempo para hacerlo correctamente, algunos malos ejemplos son:
- Poner el mismo nombre de la función que se testea (Ej. miFuncionTest)
- Nombre cortos y poco referenciales (Ej. test1, test2)
2. No necesitas mockear todo
Los Mocks son simulaciones o imitaciones de llamadas externas que hacen nuestro código para funcionar. Por ejemplo si utilizar una libreria, puedes Mockear esta libreria y sus funciones haciendo que el código no llame a las funciones de las librerias, sino al Mock que construiste, con esto tienes un entorno controlado. Pero no es necesario Mockear todas las funciones de una libreria, es un error comun que solemos cometer los devs, solo mockea las que necesites.
3. Los test deben ser simples
Los test como cualquier función en tu código, debe ir a atacar un problema en especifico, es decir debe probar un comportamiento en especifico. Algunas señales de que no estas escribiendo test simples pueden ser:
- Pruebas varias cosas o diferentes comportamientos en un solo test.
- Te es dificil nombrar el test por la complejidad del mismo.
4. El test debe ser rápido
Los test se ejecutan muchísimas veces durante el proceso de desarrollo, es por ello que no deben ser lentos. Ahora ¿que significa rápido? es muy subjetivo, pero algunas ideas para escribir tests rápidos son:
- Hacerlos lo mas simple posibles.
- Que no dependan de otros test (recuerda, son test UNITARIOS).
- Mockear o simular llamadas externas a dependencias, en vez de llamar a las originales.
5. Los Tests deberían ser legibles
Como todo código, debería ser facil de leer para su mantenimiento o revision. Algunas característicos de un test dificil de leer son:
- Mal nombramiento del tests o variables.
- Logica muy compleja en el test para poder recrear ciertos escenarios.
- Tests muy largos.
6. Test deben ser deterministicos
Un test debería siempre dar el mismo resultado si la funcion no se vio afectada de ninguna manera. Existen escenarios donde las funciones a testear utilizan dependencias externas y estas pueden variar en el tiempo, si el test no considera estos escenarios y falla en diferentes entornos, el test esta mal escritos. Para evitar esto evita que tu test dependa de:
- Otros tests.
- Valores del entorno, como la fecha o el tiempo, o el lenguaje.
- Dependencias externas.
7. Testea el comportamiento no la implementación
Al escribir un tests debemos enfocarnos en analizar como debería comportarse esa porción de código, es decir:
- Envio ciertos parametros o data.
- El código lo procesa.
- ¿Los valores devueltos o resultantes son los esperados?
