Restrospectiva-testimonio sobre la experiencia vivida durante la incursión en la calidad del software basada en el testing, concretamente en dos proyectos software muy diferentes: un nuevo desarrollo, y un mantenimiento de grupo de aplicaciónes y rutinas legacy. Este video recoge gran parte de la charla que compartid con el grupo GDG Toledo en esta convocatoria. https://www.meetup.com/gdgtoledo_es/events/254795881/

1. 21 días haciendo Tests
en un proyecto entregado y en otro de mantenimiento

2. “Estos y muchos otros fenómenos observados
comúnmente tienden a mostrar que se requiere
de un mínimo de 21 días para que una imagen
mental establecida desaparezca y cuaje una
nueva”
Maxwell Maltz (1889 -1975)
Psycho-Cybernetics

3. El reloj de oro

4. > mvn clean package -DskipTests

5. El proyecto Entregado

6. El proyecto Entregado
El Escenario
- Aplicación web monolito modular
- Producción posterior a 2015
- Documentación, presente!
- Estable: Incidencias tipo error < 3 / mes
- Test: definidos por los desarrolladores
- CI / Sonar
- > 50.000 LOC
- Cobertura es <<<< 80 %
- Technical Debt < 1 mes
- Complexities < 3000
- Código duplicado > 4 %

7. El proyecto Entregado
El compromiso
- Evolutivo clave a nivel de negocio
- Cumplir 888 casos de prueba
- Más cobertura, ...
- … bajar la deuda técnica,
- … y tiene que estar para ya !!!

8. El proyecto Entregado
Enfoque 1
- Cobertura rápida ??? Sí claro por
supuesto !!!
Técnica 1
- Con Jacoco de copiloto, hasta el
infinito y más allá !!!!

9. El proyecto Entregado
Conclusiones 1
- El Enfoque 1 no tiene ningún sentido, o
sí, pero no es funcional
- Tope cobertura y crackdown en el
mismo día, el #defectoWallstreet
- Sensibles a los cambios en la capa de
presentación
- Solo para testeo de funcionalidades
completas

10. El proyecto Entregado
Conclusiones 1
- Dependencia total del entorno y
recursos
- Mucho tiempo invertido en capacitar los
tests
- Tiempo de ejecución >= 3 horas
- Planificación para pasarlos mientras
desarrollo

11. El proyecto Entregado
Enfoque 2
- Keep calm y veamos lo que tenemos:
- Código mayormente sin cobertura
- Aparentemente fácil de testear
- Estrategia Test poco definida
- Herramientas de test
Técnica 2
- Uso herramientas test disponibles en el
proyecto

12. El proyecto Entregado
Conclusiones 2
- Métodos private y static no son
testeables
- Necesito del contexto: Servicios y
Repositorios
- Falsos negativos causa ajena
- Dependencia de datos y entorno
- Mucho tiempo para construir los tests
- Tiempo de ejecución << 1 hora
- Ejecución ‘más accesible’ mientras
desarrollo

13. El proyecto Entregado
Enfoque 3
- Que nos falta
- Eliminar la dependencia del entorno
- Llamadas a servicios y repositorios
- Private, Static y otros no testeables
- Reducir drásticamente el tiempo de ejecución
Técnica 3:
- Selección de las ‘mejores’ herramientas

14. El proyecto Entregado
Conclusiones 3
- Herramientas:
- TestMe
- Mockito
- PowerMockito
- Beanmother
- Fixture-Factory
- Refactorizar (privados, statics y otros)
- Definición de estrategia test
- Disminuye el tiempo de creación por test
- La cobertura aumenta de ‘modo natural’

15. El proyecto Entregado
Finalmente
- Se han automatizado los 888 casos de
prueba
- La cobertura aumenta de forma natural
y con sentido
- Aplicación se completa
- Promoción y formación del equipo de
mantenimiento en la cultura test

16. El proyecto Entregado
Finalmente
- Los test de la estrategia 1 son los
actuales test funcionales
- Los test de la estrategia 2 son los
actuales test de integración
- Los test de la estrategia 3 son los
actuales test unitarios
- Los test se lanzan a demanda
- CI tiene opciones para testar la
aplicación a conveniencia

17. El proyecto de Mantenimiento

18. El proyecto de Mantenimiento
El Escenario A
- Aplicación web monolito pseudo modular
- Documentación por recopilación
- En producción posterior a 2010
- Estable, incidencias tipo error < 2 / semana
- Test de integración
- CI / Sonar
- 50.000 LOC
- Cobertura > 70 %
- Technical Debt < 15 días
- Complexities < 5000
- Código duplicado < 15 %

19. El proyecto de Mantenimiento
El Escenario Z
- Aplicación web monolito pseudo modular
- Documentación por reflexión
- En producción anterior a 2010
- Estable, incidencias tipo error < 5 / semana
- Test sin mantenimiento
- CI / Sonar
- LOC >>>> 50.000
- Cobertura es <<<< 80 %
- Technical Debt >>> 1000 días
- 60.000 < Complexities < 120.000
- Código duplicado < 30 %

20. El proyecto de Mantenimiento
El compromiso
- Resolver incidencias: errores y soportes
- Evolutivos alcance diverso
- Respetar la convención de arquitectura
- CI / Sonar
- Reducir la deuda técnica
- Iguala o mejora de las métricas principales
- Capacitación para la automatización

21. El proyecto de Mantenimiento
Enfoque 1
- Incidencias: Errores y Soportes
- Conocimiento limitado sobre procesos
- Descripción en ‘negolenguaje’
- Priorizadas por el usuario
- Evolutivos
- Documentación funcional
- Desarrollo y pruebas
Técnica 1
- Solicitar info y datos para reproducir el
proceso y depurar #likeAPro !!!

22. El proyecto de Mantenimiento
Conclusiones 1
- El enfoque 1 no tiene ningún sentido, es
una completa pérdida de tiempo!!!
- Pruebas de dudosa repetibilidad
- Falsos negativos (datos muy concretos)
- Dependendencia de terceras personas
- Mucho tiempo invertido en capacitar las
pruebas
- Tiempo de ejecución indeterminado
- Imposible (o casi) ejecutar mientras se
desarrolla

23. El proyecto de Mantenimiento
Enfoque 2
- Incidencias: Errores y Soportes
- Absoluta dependencia de datos
- Private, Static y otros no testeables
- Evolutivos:
- Dependencia de datos
Técnica 2
- Crear tests de integración

24. El proyecto de Mantenimiento
Conclusiones 2
- Los métodos private y static no son
testables directamente
- Llamadas a servicios y repositorios
requieren levantar la aplicación
- Falsos negativos: problemas en la
instancia, servicios, base de datos
- Se requieren datos y entorno para soportar
los tests
- Mucho tiempo para construir los tests
- Ejecución parcial durante el desarrollo

25. El proyecto de Mantenimiento
Enfoque 3
- Incidencias: Errores y Soportes
- Identificación unitaria de procesos
- Análisis entrada - salida #depurando
- Evolutivos:
- Documento funcional como fuente de datos
- Código fuente como planos de datos
Técnica 3
- Crear tests unitarios y mocks

26. El proyecto de Mantenimiento
Conclusiones 3
- Testeamos con herramientas adecuadas:
- TestMe
- Mockito
- PowerMockito
- Ahora con más de Mocks!!!
- Independencia de contexto, entorno, o
datos
- Reducción de tiempo creación de tests
- Ejecución disponible durante el desarrollo

27. El proyecto de Mantenimiento
Finalmente
- Resolvemos incidencias más rápido
- Aplicación se va completando
- Soporte Test de procesos aplicación
- Creación de cultura del test
- Formación de equipo mantenimiento
- Aumento de confianza del grupo
- Destierro de las tradiciones manuales
- Mayor independencia
Enfoque Test + Código legacy = PERFECTO!!!

28. … lo que he aprendido
- Hacer test es amor <3
- Conocimiento técnico aplicación
- Lanzar cualquier parte de la aplicación
- Reducción dependencias: datos, entorno...
- Detectar más errores
- El precio de la Cobertura
- Los test también son diseño

29. … lo que he cambiado
- Planteamiento de tareas desde el test
- Mejor de diseño, #testenabled
- Lanzar ‘esa’ parte de la aplicación
- Pruebo mejor el código que escribo
- Independencia de preparados de datos
- Análisis estático de mi código
- Solicito testear en el desarrollo
- Depurar alterando los valores no es test
- Repulsión por las tareas no automatizadas
prueba != test
- Hablo de tests

30. > mvn clean package

31. El reloj de oro

32. IDEA Y GUIÓN
DIRECCIÓN
FIXES & BUGS
AMBIENTACIÓN
CRÉDITOS IMÁGENES
POSTPRODUCCIÓN
EXTRAS Y DOBLES
PRESENTADO EN
GRUPO INFO
EVENTO
manu garcia
Dev & QA
manu garcia
Jose Juan
Pulp Fiction
https://www.imdb.com/title/tt0110912/
A Band a Part
manu garcia as himself
GDG TOLEDO
meetup.com/gdgtoledo_es
meetup.com/gdgtoledo_es/events/254795881

33. CONTACTO
TWITTER
GITHUB
LINKEDIN
manu@developia.info
@manudevelopia
github.com/ManuDevelopia
linkedin.com/in/manugarciarodriguez
manu garcia
desarrollador software
#analysis #CI #codeclean #test #bestpractices
#java #javascript #groovy #golang