practicas técnicas

44
PRÁCTICAS TÉCNICAS JOAN SEBASTIÁN RAMÍREZ PÉREZ 2016

Upload: joan-sebastian-ramirez-perez

Post on 16-Jan-2017

206 views

Category:

Software


0 download

TRANSCRIPT

Page 1: Practicas técnicas

PRÁCTICAS TÉCNICASJOAN SEBASTIÁN RAMÍREZ PÉREZ 2016

Page 2: Practicas técnicas

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

Page 3: Practicas técnicas

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

Page 4: Practicas técnicas

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

Page 5: Practicas técnicas
Page 6: Practicas técnicas
Page 7: Practicas técnicas
Page 8: Practicas técnicas

¿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.

Page 9: Practicas técnicas

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

Page 10: Practicas técnicas

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

Page 11: Practicas técnicas

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

Page 12: Practicas técnicas
Page 13: Practicas técnicas
Page 14: Practicas técnicas

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

Page 15: Practicas técnicas

¿POR QUÉ HACER PRUEBAS DE SOFTWARE?

• Software funcionando sobre documentación extensiva

• 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.

Page 16: Practicas técnicas

PRUEBAS DE SOFTWARE

• Pruebas de Software es un proceso de evaluar un sistema ya sea manual o automático y verificar que este satisface los requisitos o identifica diferencias entre lo esperados y los resultados actuales.

• Subconjunto de las llamadas “prácticas técnicas” en la cual se automatizan las pruebas del software.

• Alrededor del 30 40% del tiempo de la implementación se invierte en la automatización de pruebas de software.

• Las pruebas de software apuntan a mejorar la calidad del producto.

Page 17: Practicas técnicas

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.

Page 18: Practicas técnicas

TIPOS DE PRUEBAS AUTOMATIZADAS

• Unitarias

• Integración

• Funcionales

• Sistema

Page 19: Practicas técnicas

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, RPGUnit.

Page 20: Practicas técnicas

¿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.

Page 21: Practicas técnicas

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.

Page 22: Practicas técnicas
Page 23: Practicas técnicas

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.

Page 24: Practicas técnicas
Page 25: Practicas técnicas

“NO HAY NINGÚN SECRETO EN CÓMO ESCRIBIR LOS TESTS, SOLO HAY SECRETOS EN CÓMO ESCRIBIR CÓDIGO TESTEABLE.”MISKOHEVERY

Page 26: Practicas técnicas

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.

Page 27: Practicas técnicas

¿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)

Page 28: Practicas técnicas

PRUEBAS FUNCIONALES, DE ACEPTACIÓN O E2E

• 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.

Page 29: Practicas técnicas

TIPOS DE PRUEBAS FUNCIONALES, DE ACEPTACIÓN O E2E

• 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.

Page 30: Practicas técnicas

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.

Page 31: Practicas técnicas

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.

Page 32: Practicas técnicas

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

Page 33: Practicas técnicas

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

Page 34: Practicas técnicas
Page 35: Practicas técnicas

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

Page 36: Practicas técnicas

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

Page 37: Practicas técnicas

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

Page 38: Practicas técnicas

OTRAS BUENAS PRACTICAS

• Pair Programming

• TDD

• ATDD

• BDD

Page 39: Practicas técnicas
Page 40: Practicas técnicas
Page 41: Practicas técnicas
Page 42: Practicas técnicas

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

Page 43: Practicas técnicas

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

Page 44: Practicas técnicas

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