it('should be easy');
Paqui Calabria @zurribulle
Encuesta
Edad
¿Qué opinamos de los test automatizados?
"La mejor forma de tener un código mantenible"
"Aportan calidad. Es más sencillo refactorizar y añadir o quitar features"
"Muy útiles, y ahorran tiempo en el medio-largo plazo"
"Molan. Prefiero los tests automatizados para no tener que hablar con QA"
"Necesarios para asegurar un diseño suficientemente bueno"
"Son necesarios, pero no hay que tenerlos porque sí"
¿Testeamos lo suficiente?
¿Por qué?
¿En serio?
Las buenas herramientas no se dejan de usar por falta de tiempo
| Proceso | Sin tests | Con tests |
|---|---|---|
| Implementación | 7 días | 14 días |
| Integración | 7 días | 2 días |
| Testing y debug | 12 días | 9 días |
| Total | 26 días | 24 días |
| Bugs en prod | 71 | 11 |
The art of unit testing, Roy Osherove
Parecen poco productivos porque no los aprovechamos al 100% de su potencial
Falta de conocimientos teóricos y buenas prácticas
"Los estandards de testing son difíciles de encontrar"
"Los tests automatizados pueden ser muy pesados. Creo que buena parte viene de usar mal las herramientas"
"Es difícil decidir cómo, dónde y cuánto testear"
10 + 1 consejos para mejorar tus tests
Cada test debe ser independiente
Si necesitas que un test tenga éxito para poder lanzar otro, crearás falsos negativos.
Cuando hay mucho setup usa beforeEach, helpers, page objects...
Ordena los tests de lo general a lo particular
Cuando varios tests fallen, sabrás que tienes que empezar debugando por el primero.
Comprueba una cosa por test
Está bien poner varios expects pero si en el título pone "y" probablemente acabe siendo inmantenible
No te olvides de limpiar
Cualquier modificación al entorno que haya hecho un test, tiene que deshacerse luego para evitar efectos colaterales.
Borra el local storage, resetea la base de datos, restaura el comportamiento de los spies/stubs...
Crea una librería de mocks
Mockear es aburrido, lento y repetitivo. Crea una librería de objetos, servicios, componentes, etc mockeados que puedas acceder desde cualquier test.
Los asincronismos te van a joder la vida
Aprende a dominarlos lo antes posible, estudia, practica.
https://blog.cloudboost.io/javascript-asynchronous-testing-gotchas-ac7e5c39257
No dejes que "caduquen"
Haz los tests lo antes posible, lánzalos con frecuencia y arréglalos en cuanto fallen.
Usa herramientas de CI como jenkins o travis, hooks de git... que no haya merge sin tests.
No te obsesiones con la cobertura
El reporte completo es útil para saber qué nos estamos dejando, pero al final es sólo un número
https://github.com/FCalabria/coverage_is_a_lie
No testees trivialidades
Es tiempo mal invertido, y aumenta el coste de mantenimiento.
No solo existen los UT
Estudia los puntos débiles del proyecto antes de implantar ciegamente tests unitarios. Puede compensar más otro tipo.
Fija un tiempo límite
Situaciones desesperadas requiren medidas desesperadas. Además es un buen argumento para convencer a managers.
Testing automatizado para no developers
A.k.a cómo explicárselo a tu jefe y no acabar echando CVs
Nadie nace sabiendo
¿Por qué?
Refactors más sencillos
Mejora la comprensión de los requerimientos
Componentes más robustos
Disminuye el tiempo de resolución de bugs
Documentación para otros desarrolladores
CD con menos bugs
Ya tenemos QA
El testing automatizado y el manual no son excluyentes.
Añadiendo testing automatizado, los testers pueden invertir más tiempo en nuevas features, accesibilidad, que se cumplan los requisitos del cliente, etc.
¿Se tarda más?
El tiempo de desarrollo parece mayor, pero a la larga se reduce porque habrá menos bugs y será más mantenible.
Quiero números
Realizing quality improvement through test driven development: Entre el 60 y 90 % mejor código (cantidad de defectos), del 15 al 30% más tiempo de desarrollo.
Estudia la herramienta de tickets del proyecto, y marca qué bugs podrían haberse evitado con testing automatizado.
Es mucho riesgo
Propón hacerlo solo durante un plazo de tiempo y después analizar los resultados.
O bien, aplicarlo solo en cierta parte del proyecto que pueda ser problemática y darán más beneficio.
Si nada funciona, hazlos sin preguntar
Calcula el tiempo extra para escribir tests en las estimaciones.
Guarda estadísticas para luego:
- Potenciales bugs cazados por los tests
- Bugs reportados con/sin tests
- Tiempo de resolución de bugs
- Tiempo invertido en modificar features