Testing

Desarrollo y Pruebas de Proyectos Java en un Entorno Ágil

Acerca de Mi
● ● ● ● ● ●

Amante del Software Expatriado y Retornado 10 años peleando con líneas de código Blogger aficionado: http://brigomp.blogspot.com Co-fundador de Jobsket http://www.jobsket.es/cv/martin

El índice
● ● ● ● ●

Historietas de Guerra Nociones básicas sobre Desarrollo Ágil Buenas Prácticas Testing y QAIntegración Continua

Historias de Guerra

Historietas de Guerra
●

Iteraciones frecuentes Desplegar software rápidamente Hacer que el cliente participe en el diseño No hace falta rodearse de los mejores. Rodearse de gente trabajadora suele ser suficiente.

●

●

●

●

TVODD: TV Oriented Based Development ESTAS RETRASANDO EL PROYECTO

Historias de Guerra
●

Las televisionesno motivan (a no ser que te gusten apostar a las carreras de caballos) Determinadas acciones son golpes a la moral Los proyectos retrasados no van a remontar el vuelo por poner más presión a los empleados. Demuestran que son necesarios cambios en la forma de trabajar de la empresa.

● ●

●

¡¡¡ A TESTEAR !!!

Historias de Guerra
●

No por tener más testers tu software va a estar mejortesteado. Es necesaria una estrategia de automatización. El equipo de desarrollo debe ayudar al equipo de testers. Pero El equipo de testers debe dejarse ayudar. Tener testers no informáticos es bueno.

● ●

● ●

Nociones básicas (y muy breves) sobre Desarrollo Ágil

Manifiesto Ágil
Nuevos Valores Individuos e integracción Software que funciona Colaboración con el cliente Respuesta alcambio Antiguos Valores

Procesos y herramientas Documentación exhaustiva Negociación contractual Seguimiento de un plan

Desarrollo ágil
● ● ● ● ● ● ● ● ●

Pragmatismo Iteraciones cortas Software funcional disponible frecuentemente Reuniones frecuentes Reparto de conocimiento y responsabilidades Documentación ágil Demostración continua Retrospectivas Personas y relaciones frente aherramientas

Buenas Prácticas

Programación en Parejas
●

Juntar dos desarrolladores frente a una pantalla. A la larga, mayor productividad. Incrementa la propiedad colectiva del código. Combinación perfecta: desarrollardor experto + desarrollador normal/junior. Juntar a 2 juniors, 2 expertos no aporta demasiado El programador inexperto aprende mucho más. Quizás no una práctica para el día a díapero sí para hacer de cuando en cuando.

●

●

●

●

●

●

Revisiones de Código
● ●

Muy útil para detectar errores. Muy importante con nuevas incorporaciones en los equipos. Es necesario alternar la responsabilidad. Si no, “el revisor” será un cuello de botella. Aumenta la responsabilidad colectiva del código. Centrarse en errores de alto nivel. El resto se puede detectarfácilmente con análisis estático.

●

●

●

Análisis estático
●

Las herramientas de análisis estático detectan errores sin tener que ejecutar código. Se integran fácilmente en el proceso de build
●

●

Si se detectan X errores críticos la build falla.

● ● ●

Algunas veces hay que mitigar el ruido Findbugs, PMD, Sonar. Alternativas comerciales

Análisis estático: ErroresImprevisibles
●

Visto en Eclipse 3.5RC2
if (adapters == null && adapters.length == 0) return;

●

Error desde Eclipse 3.2
● ●

Probablemente nunca se cumplió la condición Si se cumpliese habría saltado una NPE

Análisis estático: Seguridad
●

Ejemplo típico. SQL Injection
HttpServletRequest request = … String usuario = request.getParameter(“user”) String query = “select * fromaccount_numbers where nombre=' ” + usuario + “ ' ”; con.execute(query)

●

¿Y si user es “ ' OR 1==1-- ” ?

Análisis estático: Escalabilidad
●

Resource leaking
try { Connection c = … String query = ...; c.execute(query); c.close() } catch (Exception e) { e.printStackTrace() }

●

¿ Qué pasa si falla la consulta ?

Análisis estático: Concurrencia
●

Ejemplo, uso de estructuras de...