Desarrollo con Java y metodologías agiles

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 QA
● Integración Continua

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 televisiones no 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.

Historias de Guerra
● No por tener más testers tu software va a estar
mejor testeado.
● 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 Antiguos Valores

Individuos e integracción Procesos y herramientas
Software que funciona Documentación exhaustiva
Colaboración con el cliente Negociación contractual
Respuesta al cambio 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 a herramientas

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ía pero 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 detectar fá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: Errores Imprevisibles
● 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 * from account_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 datos no
Thread-safe en código multihilo
● ¿Inocente? Esto es un gráfico de un servidor
real. 4 CPUs 8Gb RAM.

Análisis estático: Concurrencia

● Parece grave, ¿no? ¿Cuál fue la
causa?

● Dos llamadas a HashMap.put() y
mala suerte

Testing
● Todos somos humanos. El software
inevitablemente tiene muchos herrores.
● Bienvenidos sean los fallos.
● Por eso mismo debemos hacer pruebas.
● Unitarias
● Integración
● Funcionales
● Stress

Tests Unitarios
● Los hacen los desarrolladores
● Prueban la funcionalidad de tu código
● Introducidos ya en todos los lenguajes
● Junit, Nunit, PhpUnit,Test::Unit,...
● Prueban partes de código que no interactuen
con recursos externos
● No acceden a bases de datos, no acceden a la red,
etc.

Tests Unitarios
public class LanguageDetectorTests extends TestCase {

@Test
public void testLanguageDetection() throws Exception {

LanguageIdentifier identifier = new LanguageIdentifier();
assertEquals(identifier.identify("This is a test"),"en");
assertEquals(identifier.identify("Esto es un test"),"es");
}

Tests Unitarios
public void testExtractExperience() {

List<ExperienceEntry> entries =
extractor.extractExperience("Julio 2006 - Septiembre 2006 Vuelvo a
Sertec Soluciones informáticas Trabajando como Operador de
Sistemas dentro del Proyecto CRONOS de la Editorial
Planeta.nSeptiembre 2007 - Julio 2008 Becario en el departamento
de Matemàtica Aplicada I de la Universitat Politècnica de
Catalunya dentro de los servicios informáticos dando soporte a los
profesores del departamento.","es");
assertEquals(entries.size(),2);
assertEquals(entries.get(0).getExperience(),2);
assertEquals(entries.get(1).getExperience(),10);
}

Tests Unitarios
● Típico: Tengo prisa. No tengo tiempo para
hacer tests unitarios
● Los tests unitarios se hacen para ahorrar
tiempo
● Software más sólido y probado.
● Menos cosas que probar manualmente.
● Menos bugs. Los bugs se encuentran antes.
● Menos presión.
● No hacer tests unitarios es no ser un buen
programador

Cobertura de Código
● Es importante saber cuanto código estamos
realmente probando.
● Ideal 70%-80%
● 100% es perder el tiempo. Demasiado caro.
● Muy útil para contrastar que nuestros tests
están realmente haciendo lo que queremos.
● Muchísimas herramientas
● Lo bueno es que no hay que configurar nada.
● Se pueden integrar en el proceso de build.
● Cobertura,EclEmma,Sonar, etc.

Tests de Integración
● Los hacen los desarrolladores
● Prueban la funcionalidad de tu código que
depende de recursos externos
● Pruebas de bases de datos, recursos en red,
servicios web, EJBs, disco,etc.
● Requieren un setup. Inicialización de recursos,
ficheros de configuración diferentes a
producción, etc.
● Herramientas como Spring te lo hacen más
sencillo

● Existen frameworks para todos los gustos
● XMLUnit: Xmls, XSLTs, XSDs, ...
● DBUnit: Acceso a bases de datos
● HtmlUnit: Páginas web
● SoapUI: Servicios web
● Cactus: JSPs, Servlets, EJBs,...

HTMLUnit

DBUnit

XMLUnit

● Hacer tests de integración requieres más
esfuerzo que el hacer tests unitarios.
● Sin embargo, es muy necesario.
● Este esfuerzo es sólo de configuración.
● ¿Cómo inicializo mi base de datos?
● ¿Cómo inicializo mi servidor web?
● Muchos servidores pueden ser embebidos:
Jetty, Tomcat, HSQLDB, …

● Proceso típico:
1) Inicializar base de datos, servidor web, …
2) Inicializar nuestros servicios.
3) Ejecutar el test
● Si nos encontramos haciendo nuestro propio
framework de integración: Mal camino.
● Spring hace todo más fácil
● En Grails por ejemplo es ridículamente simple.
● Una vez está todo configurado. Vale la pena.
Los tests son mucho más significativos.

void testFindAllByUsername() {{
void testFindAllByUsername()
CV cv1 == buildCV()
CV cv1 buildCV()
cvService.save(cv1)
cvService.save(cv1)
CV cv2 == buildCV()
CV cv2 buildCV()
cvService.save(cv2)
cvService.save(cv2)
def cvs == cvService.findAllByUsername("test")
def cvs cvService.findAllByUsername("test")
assertEquals cvs.size(),2
assertEquals cvs.size(),2
}}

void testDeleteInvoice() {{
void testDeleteInvoice()
def invoiceData == new InvoiceData()
def invoiceData new InvoiceData()
invoiceData.user == recruiter
invoiceData.user recruiter
def invoice == billingService.generateInvoice(invoiceData)
def invoice billingService.generateInvoice(invoiceData)
assertEquals billingService.findAllInvoicesByUser(recruiter).size,1

billingService.deleteInvoice(recruiter,invoice)
billingService.deleteInvoice(recruiter,invoice)
}}

● Ojo con el solapamiento entre tests de
integración y tests funcionales
● Si:
● No usamos un framework que nos haga las cosas
más fáciles
● Nos está costando bastante el configurar el sistema
(base de datos embebida, gestión de
transacciones, limpieza entre tests, etc.)
● Entones quizás sea mejor saltar directamente a
hacer tests funcionales

Tests Funcionales
● No los deberían hacer los desarrolladores.
● Se comportan como si fueran usuarios reales.
● No conocen el sistema.
● Simplemente acceden a las páginas web,
aplicación.
● Son con diferencia el mejor tipo de pruebas
● ¡¡ El software funciona de verdad !!

QA
● Rara avis en España. Muy común en Europa.
● No informáticos que se dedican a probar las
aplicaciones.
● Son personas muy útiles, pero es necesario
guiarles. Es importante que se dejen guiar. Es
gente que no tiene experiencia en desarrollo
de software.
● ¿Deberían hacer tests funcionales los
programadores?
● Idealmente, no. QA mira el software de un modo
completamente diferente.

Tests Funcionales
● Hoy por hoy hay muchas herramientas
● Selenium
● Canoo WebTest
● HTMLUnit
● ¿Y si mi aplicación es Swing?
● Abbot, Frankenstein,...
● Muchas herramientas comerciales
● En una empresa usabamos HP QuickTest
– QA grababa los tests desde un applet y se generaban
scripts en Excel. ¡Les encantaba!

Tests Funcionales
● Selenium es enormemente sencillo
● Tiene un IDE para grabar
tests.
● Los tests se pueden
reproducir.
● Incluso genera código en
diferentes lenguajes.
● Cualquiera puede grabar
estos tests. Ideal para no
desarrolladores.

Tests Funcionales
● Pero, lanza una instancia del navegador con
cada tests, es decir, consume bastantes
recursos.
● Los tests pueden ser complicados de mantener.
● Canoo WebTest

Tests Funcionales
● Ojo, a veces lo simple puede ser lo más potente
● HtmlUnit es realmente sencillo, pero no es nada
amigable para no desarrolladores.

Tests Funcionales
● Ojo, a veces lo simple puede ser lo más potente
● HtmlUnit es realmente sencillo y no requiere
navegadores abiertos.
● Pero sólo lo entendemos los programadores.

Tests Funcionales
● Pero con un buen DSL cualquiera puede hacer
tests.
● En uno de mis trabajos lo probé en una de mis
empresas y se comenzaron a hacer tests como
churros. 36 Qas por fin productivos.
Module: signin
Module: signin
Goto '/home'
Goto '/home' run signin
ClickByText 'Sign In' run signin
ClickByText 'Sign In'
Type 'Login','martin'
Type 'Login','martin' Goto '/invoices'
Type 'Password','test' Goto '/invoices'
Type 'Password','test' ClickButton 'New Invoice'
ClickButton 'New Invoice'
ClickButton 'Sign In'
ClickButton 'Sign In' VeryfyText 'Create...
VerifyText 'Welcome Martin' VeryfyText 'Create...
VerifyText 'Welcome Martin'

Test Driven Development
● Crear primero el test y después el código.
● Difícil de comenzar, cambio completo de
mentalidad.
● Tras acostumbrarse, muy productivo. Ya que:
● Te obliga a enfrentarte al problema desde un punto
de vista diferente.
● Tras acabar la funcionalidad, ya tienes los tests.
● Fácil acostumbrarse al empezar con bugs
● ¿Te pasan un bug? Test que lo reproduzca.

Lo que ningún libro te contará sobre los tests

¡Sálvame!
● Iteraciones cada dos semanas.
● Demos a final de cada iteración.
● Despliegue en producción cada mes.
● Un departamento de QA que necesita software
que funcione.
● Un departamento Comercial que quiere hacer
demos a clientes.

¿Imposible?

Integración Continua
1. Compilar
2. Ejecutar tests
3. Analizar código
4. Métricas
Commits
7. Release

SVN,
CVS,.. CI
5. Desplegar

6. Tests Funcionales

Servidor

● Cruise Control, Hudson, Apache Continuum,
Bamboo, Team Foundation Server,...
● Para mi, el mejor es Hudson
● Instalación trivial
● Enormemente sencillo de utilizar
● Multitud de plug-ins

● Algunas buenas prácticas:
● La build debe ser muy rápida. Intentar siempre
acortar el tiempo de build.
● No tener una única build. Separarlas para hacer el
proceso más rápido.
● Si la build se rompe, hay que parar y arreglarla.
● Si hay QAs creando tests quizás convenga que
tengan otra máquina.
● Los tests funcionales suelen tomar bastante
tiempo. Build propia o idealmente otra máquina.

Referencias
● http://www.agile-spain.com
● http://groups.google.es/group/agile-spain/files?pli=1
● http://sites.google.com/site/axilmente/Home/recursos
● http://pragprog.com
● http://blog.objectmentor.com
● http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
● http://www.infoq.com
● http://www.presionblogosferica.com
● http://www.javahispano.org

Desarrollo con Java y metodologías agiles

Más contenido relacionado

Destacado (19)

Similar a Desarrollo con Java y metodologías agiles (20)

Último (20)

Desarrollo con Java y metodologías agiles