prácticas técnicas, tdd, atdd, bdd, pruebas automáticas, integración continua, análisis estático de código

1. PRÁCTICAS TÉCNICAS
JOAN SEBASTIÁN RAMÍREZ PÉREZ
2017

2. AGENDA
1. ¿Por qué introducir estos elementos?
2. Integración Continua
3. Pruebas Automáticas
4. Análisis estático de código
5. ¿Qué sigue?
6. Bibliografía

3. AGENDA
1. ¿Por qué introducir estos elementos?
2. Integración Continua
3. Pruebas Automáticas
4. Análisis estático de código
5. ¿Qué sigue?
6. Bibliografía

4. ¿QUÉ QUEREMOS EVITAR CON LAS
PRÁCTICAS TÉCNICAS Y LA CALIDAD DE
NUESTRO CÓDIGO?
TOMADO DE CLEAN CODE, DE ROBERT
MARTIN

8. ¿POR QUÉ LAS PRÁCTICAS
TÉCNICAS?
• Estamos descubriendo formas mejores de desarrollar software tanto por
nuestra propia experiencia como ayudando a terceros.
• Nuestra mayor prioridad es satisfacer al cliente mediante la entrega
temprana y continua de software con valor.
• El software funcionando es la medida principal de progreso.
• Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.
• La atención continua a la excelencia técnica y al buen diseño mejora la
Agilidad.

9. ¿CUÁNTAS VECES DEBERÍAMOS
DESPLEGAR EN UN DÍA?

10. DESPLIEGUES QUE AMAZON
PUEDE HACER EN UN DÍA
• Tiempo entre despliegues 11,6 segundos
• Máximo número de despliegues en una hora 1.079
• Simultáneamente pueden estar recibiendo un despliegue
10.000 hosts
• Número máximo de hosts recibiendo despliegues 30.000
• Tomado de:
http://assets.en.oreilly.com/1/event/60/Velocity%20Culture%
20Presentation.pdf

11. AGENDA
1. ¿Por qué introducir estos elementos?
2. Integración Continua
3. Pruebas Automáticas
4. Análisis estático de código
5. ¿Qué sigue?
6. Bibliografía

13. TOMADA DE:
HTTPS://WWW.IBM.COM/DEVELOPERWORKS/COMMUNITY/BLOGS/A9BA1EFE-B731-
4317-9724-
A181D6155E3A/ENTRY/ACCELERATING_MAXIMO_DEVELOPMENT_WITH_CONTINUOU
S_DELIVERY?LANG=EN

14. TOMADO DE
HTTP://FOCUSOFTHOUGHT.COM/PROFESSIONAL
/BODY-OF-WORK/BODY-OF-WORK-CONTINUOUS/

15. TOMADA DE
HTTPS://CO.PINTEREST.COM/FRISOSCHUTT
E/ABOUT-CONTINUOUS-DELIVERY/

17. AGENDA
1. ¿Por qué introducir estos elementos?
2. Integración Continua
3. Pruebas Automáticas
4. Análisis estático de código
5. ¿Qué sigue?
6. Bibliografía

18. ¿POR QUÉ HACER PRUEBAS DE
SOFTWARE?
• Mitigar errores en la aplicación.
• Eficiencia de la aplicación.
• Aseguramiento de la calidad (proceso del desarrollo
del software).
• Flexibilidad del software.
• Adaptación del sistema a cambios futuros.

19. MOCKING
• Los mocks son objetos falsos que simulan el comportamiento de
un objeto real.
• Se llaman Mock a los objetos que imitan el comportamiento de
objetos reales de una forma controlada. Se usan para probar a
otros objetos en test unitarios que esperan mensajes de una
clase en particular para sus métodos, al igual que los
diseñadores de autos usan un crash dummy cuando simulan un
accidente.
• Algunos frameworks para hacer mocks: Mockito, EasyMock,
PowerMock, Jmock, Jmockit, ngMock, JustMock, Nmock,
RhinoMock.

20. EJEMPLO
FRAMEWORK: MOCKITO

21. PRUEBAS UNITARIAS
• Testean la funcionalidad de una unidad de código
emulando las llamas a otras unidades (tanto internas
como externas).
• La emulación se hace a través de mocking.
• las pruebas unitarias por lo general son simples y
rápidas de codificar, el desarrollo de una prueba
unitaria no debería tomar más de cinco minutos.
• Algunos frameworks: Junit, Karma, Nunit, RSpec.

22. ¿QUÉ DEBERÍA CUMPLIR UNA
PRUEBA UNITARIA?
• Unitaria: prueba solamente pequeñas cantidades de código.
• Independiente: no debe depender ni afectar a otras pruebas
unitarias.
• Automatizable: la prueba no debería requerir intervención
manual.
• Repetible y predecible: no debe incidir el orden y las veces
que se repita la prueba, el resultado siempre debe ser el
mismo.

23. PATRÓN AAA
Hace referencia a la forma en la cual se debe organizar el
código para automatizar una prueba.
• Arrange: preparar objetos, variables, dependencias y
mock necesarios para hacer el llamado a la prueba.
• Act: se invoca la funcionalidad que se quiere probar con
lo que se genero en el arrange.
• Assert: verificar que el resultado del act coincide con el
esperado a través de un assert. Un único assert por
prueba.

24. SET UP Y TEAR DOWN
• Set up nos permite
inicializar valores
comunes a todos los test.
• Tear Down nos permite
limpiar valores comunes a
todos los test.

26. MiskoHevery
“No hay ningún secreto en cómo escribir los tests, solo hay secretos en cómo escribir código
testeable.”

27. PRUEBAS DE INTEGRACIÓN
• Testean unidades de código.
• Se hacen similar a las unitarias solo que no es
necesaria la emulación de las unidades.
• Es importante probar excepciones y timeout en este
tipo de pruebas.
• Se hacen con los mismos framework que las
pruebas unitarias.

28. ¿CUÁNDO ES UNA PRUEBA DE
INTEGRACIÓN?
• Cuando involucra una o más clases en simultaneo.
• Cuando el código se comunica fuera de las
fronteras de su propio proceso (base de datos, la
red, sistemas de archivos)

29. PRUEBAS FUNCIONALES
• Testean la aplicación incluso interactuando con las
diferentes capas de ella.
• Estas pruebas simulan la interacción del usuario
con la aplicación.
• Jbehave, Cucumber, Protractor, Selenium, Code Ui,
Spec Flow, etc.

30. TIPOS DE PRUEBAS
FUNCIONALES
• Visuales o de apariencia: garantizan que la interfaz
de usuario se despliega de la manera esperada con
todas sus secciones, comportamientos y elementos
• Transversales: son las pruebas en las cuales se
hace un robot que ingresa los datos a la pantalla y
hace la petición como lo haría un usuario.

31. PRUEBAS DEL SISTEMA
• Testean la aplicación como un todo.
• Usualmente son usadas para realizar pruebas de
stress o para verificar atributos de calidad definidos
para la aplicación.
• Pruebas requisitos no funcionales.

32. TIPOS DE PRUEBAS DE
SISTEMA
• Rendimiento: mide la aplicación respecto a los requisitos no
funcionales asociados a tiempo de respuesta. Pueden medir
también consumo de recursos, memoria, disco, procesador,
ancho de banda, etc.
• Escalabilidad: mide que el rendimiento de la aplicación no
desmejore abruptamente en la medida que incrementa el
número de usuarios.
• Profiling: análisis de rendimiento en un determinado momento.
Usado habitualmente para identificar problemas de rendimiento
en ambientes de producción.

33. Tomado de:
http://blogs.agilefaqs.com/tag/unit-
testing/

34. AGENDA
1. ¿Por qué introducir estos elementos?
2. Integración Continua
3. Pruebas Automáticas
4. Análisis estático de código
5. ¿Qué sigue?
6. Bibliografía

36. CUADRANTE DEUDA TÉCNICA DE
FOWLER
Tomado de: http://www.slideshare.net/JavierGarzas/deuda-
tecnica-slideshare?qid=2eba2bc2-2828-4c70-990d-
206fe0affe33&v=qf1&b=&from_search=1

37. CUADRANTE DEUDA TÉCNICA DE
FOWLER
Tomado de: http://www.slideshare.net/JavierGarzas/deuda-
tecnica-slideshare?qid=2eba2bc2-2828-4c70-990d-
206fe0affe33&v=qf1&b=&from_search=1

38. AGENDA
1. ¿Por qué introducir estos elementos?
2. Integración Continua
3. Pruebas Automáticas
4. Análisis estático de código
5. ¿Qué sigue?
6. Bibliografía

39. OTRAS BUENAS PRACTICAS
• Pair Programming
• TDD
• ATDD
• BDD

43. • ¿Cómo aprendemos?
Según William Glasser.
Tomado de:
http://www.infografiasyre
medios.com/como-
aprendemos-teoria-de-
william-glasser/

44. AGENDA
1. ¿Por qué introducir estos elementos?
2. Integración Continua
3. Pruebas Automáticas
4. Análisis estático de código
5. ¿Qué sigue?
6. Bibliografía

45. BIBLIOGRAFÍA
• P. Kruchten, R. Nord, and I. Ozkaya, “Technical debt: from metaphor to theory and
practice” IEEE Software, vol. 29(6), pp. 18-21, 2012.
• http://www.slideshare.net/JavierGarzas/deuda-tecnica-slideshare?qid=2eba2bc2-2828-
4c70-990d-206fe0affe33&v=qf1&b=&from_search=1
• MARTIN, Robert. Código Limpio. Manual de estilo para el desarrollo ágil de software.
Anaya Multimedia, 2012.
• Laurie Williams & Robert Kessler. (2002). Pair Programming Illuminated. (1st
ed.). : Addison-Wesley Professional.
• Dan North. (2006). Behavior Modification. Better Software magazine, 2006-03(03).
• http://blogs.agilefaqs.com/tag/unit-testing/
• http://assets.en.oreilly.com/1/event/60/Velocity%20Culture%20Presentation.pdf