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

¡Gracias!

It should be easy

By Paqui Calabria

It should be easy

  • 380
Loading comments...

More from Paqui Calabria